On Fri, Aug 10, 2018 at 2:23 AM, Jonathan Vaughn <jonathan(a)creatuity.com> wrote:
So it seems one of the major hurdles to official Fedora support is
support in upstream U-Boot for the RK3328, and after that baking the right
kind of ARM Trusted Firmware image (though perhaps it's possible to do this
once and just handle it as a blob versus rebuilding it) ?
If it's a self built ATF you can do as you like as long as it's got
the bits of u-boot needed to boot UEFI. For us to ship it in Fedora we
need to build it due to policies.
All the weird partitioning as you pointed out is likely due to
I'm sure whatever original materials Rockchip has for Linux is built around
Android assumptions, and it's likely that the community built Debian Stretch
image just followed that example.
It sounds from what you're saying as far as partitions and SPL/U-Boot/Trust
image, that we could in theory just write those to the correct locations
regardless of whether they're all in separate partitions (a la Android) or
one big partition (such as Fedora assumes), so long as there's space in the
partition layout for them all to fit in the first partition?
That's my understanding, we can tweak the locations too, it's just the
SPL that needs to be in a specific spot.
It looks like the default image has a FAT16 first partition, but the
target then writes various things at fixed positions (and it sounds like
this would be similar for Rock64, just different things perhaps different
places) - seems like this would corrupt the FAT16 partition, but leave the
necessary boot code in the right places?
The Pine64 works fine if it's a MBR partition, we've supported that
device for a couple of releases.
Also, reviewing the link you gave for the RK wiki, it looks like
will want GPT partitioning :
"Write GPT partition table to SD card in U-Boot, and then U-Boot can find
the boot partition and run into kernel."
Shouldn't make any difference what so ever, upstream u-boot will boot
either as per the UEFI standard.
Though it's hard to know if that's a suggestion (being
Android centric) or
requirement, without some experimentation.
I'm going to try just copying the boot related partitions from the working
Stretch image on top of a normal Fedora ARM image and see what happens
(other than probably "corrupting" the FAT16 partition). First to see if it
starts booting at all, secondly if it actually boots completely or goes
splat somewhere along the way.
The FAT16 partition is where all the EFI bits reside, they are core
for booting an aarch64 Fedora system.
> As for the bit about 'System Volume Information' I now realize from looking
> at the time stamp that it was because I had written the image with Etcher on
> my Windows desktop and before I then attached the device to a Linux VM
> Windows auto mounted it and had it's way with it...
> On Thu, Aug 9, 2018 at 4:23 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>> On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <jonathan(a)creatuity.com>
>> > I see a few months ago in the mailing list that support was brought up
>> > (in
>> > the context of F27) and it was mentioned that improving support for
>> > Rockchips devices in general was intended for F28.
>> Yes, I did intend on doing that, I ran into a number of problems and
>> also purely just ran out of time.
>> > It doesn't appear that fedora-arm-installer currently supports the
>> > Rock64
>> > board as far as I can tell.
>> That is correct and the Rock64 particularly is different to the
>> Rockchips support above. The Rock64 device is not supported in
>> upstream u-boot which is what we ship and for a device to be
>> classified as fully supported by Fedora so even when the improvement
>> in Rockchips support lands (which I'm hoping I will finish off in
>> F-29, assistance would help) it's currently unlikely the Rock64 will
>> be in that list.
>> > I'm trying to figure out how to add support by adding to
>> > /usr/share/arm-image-installer/boards.d and socs.d, as well as solving
>> > the
>> > lack of appropriate uboot in /usr/share/uboot for Rock64.
>> That's two different problems and there's a bunch of other stuff that
>> is actually in there.
>> > I flashed (and tested successfully) a community built Debian Stretch
>> > image
>> > and by comparing it's partition layout and some information from
>> > OpenSUSE I
>> > can guess at what some of it should be, but I'm not entirely sure how
>> > make the appropriate files in socs.d, boards.d, and what all is needed
>> > in
>> > uboot ...
>> Most of what you have below is interesting but most probably won't
>> going into a-i-i, we don't currently and personally I really not sure
>> i want to go the route of moving around partitions and changing
>> partitioning schemes on the fly there.
>> > Debian Stretch image that boots :
>> > U-boot used in the above build :
>> > https://github.com/ayufan-rock64/linux-u-boot
>> > OpenSUSE info : https://en.opensuse.org/HCL:Rock64
>> > working stretch partition layout :
>> > # gdisk -l /dev/sdc
>> > GPT fdisk (gdisk) version 1.0.4
>> > Partition table scan:
>> > MBR: protective
>> > BSD: not present
>> > APM: not present
>> > GPT: present
>> > Found valid GPT with protective MBR; using GPT.
>> > Disk /dev/sdc: 62333952 sectors, 29.7 GiB
>> > Model: Storage Device
>> > Sector size (logical/physical): 512/512 bytes
>> > Disk identifier (GUID): 9CFDF7D8-766C-43DE-9354-57097D428E8F
>> > Partition table holds up to 128 entries
>> > Main partition table begins at sector 2 and ends at sector 33
>> > First usable sector is 34, last usable sector is 62333918
>> > Partitions will be aligned on 64-sector boundaries
>> > Total free space is 30 sectors (15.0 KiB)
>> > Number Start (sector) End (sector) Size Code Name
>> > 1 64 8063 3.9 MiB 8300 loader1
>> > 2 8064 8191 64.0 KiB 8300 reserved1
>> > 3 8192 16383 4.0 MiB 8300 reserved2
>> > 4 16384 24575 4.0 MiB 8300 loader2
>> > 5 24576 32767 4.0 MiB 8300 atf
>> > 6 32768 262143 112.0 MiB 0700 boot
>> > 7 262144 62333918 29.6 GiB 8300 root
>> > loader1 (partition 1) is the SPL, loader2 (partition 4) is the U-Boot.
>> > atf
>> > (partition 5) per OpenSUSE is apparently some kind of "trust"
>> ATF is Arm Trusted Firmware, it's a requirement of ARMv8 / aarch64.
>> It's a core part of the ARM architecture and handles a number of
>> things including the PSCI which is what handles things such as
>> secondary CPU startup etc.
>> > The reserved partitions (partitions 2 and 3) seem to just be all nulls.
>> > The boot partition (partition 6) has extlinux/extlinux.conf apparently
>> > as
>> > well as 'System Volume Information' (guessing that the origin of
>> > partition was built on Windows), and partition 7 is of course regular
>> > old
>> > Linux filesystem.
>> Being Debian I very much doubt that TBH
>> > I'm not sure how fedora-arm-installer decides to partition things, it
>> > wasn't
>> It doesn't, only thing it does related to partitions is to optionally
>> grow the root partitions out to the full size of the destination
>> > obvious from socs.d/boards.d, so I'm not sure how to ensure that when
>> > creating the soc/board scripts that the correct layout is maintained.
>> > From
>> > glancing at the source code for fedora-arm-installer it seems like it
>> > just
>> > extracts the image onto the media and assumes the layout based on what
>> > was
>> > in the image, which might present a problem if the unified AArch64 image
>> > has
>> > only 3 partitions? Unless it would be expected that Fedora would have
>> > it's
>> > own build of uboot that would ensure things didn't need all those other
>> > partitions ?
>> > Anyways, I'm happy to either figure this out on my own if you can point
>> > me
>> > in the right direction or if you already have some WIP that needs a
>> > volunteer to test it, to do be your guinea pig.
>> So all the of the above is interesting but I'm not sure we actually
>> need to put all the bits into a series of partitions. Generally a lot
>> of the above appears to be based upon the way Android does this stuff.
>> Rockchips actually some really good docs on their boot process, a few
>> bits are a little out of date based on improvements in upstream U-Boot
>> but it's a very useful starting point:
>> From there we should be able to dd out the U-Boot/ATF stack to an
>> offset and it should just work. The bit that I've had issues with is
>> around the upstream ATF working on the SoCs