On Fri, Aug 10, 2018 at 2:23 AM, Jonathan Vaughn <firstname.lastname@example.org> wrote:
> So it seems one of the major hurdles to official Fedora support is getting
> 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 Android-ness,
> 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 pine64
> 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 perhaps it
> 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 <email@example.com> wrote:
>> On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <firstname.lastname@example.org>
>> > 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 to
>> > 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 :
>> > https://github.com/ayufan-
rock64/linux-build/releases/ download/0.7.8/stretch- minimal-rock64-0.7.8-1061- arm64.img.xz
>> > U-boot used in the above build :
>> > https://github.com/ayufan-
>> > OpenSUSE info : https://en.opensuse.org/HCL:
>> > 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-
>> > 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" image.
>> 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 that
>> > 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