On Fri, Aug 10, 2018 at 2:23 AM, Jonathan Vaughn <jonathan@xxxxxxxxxxxxx> 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 <pbrobinson@xxxxxxxxx> wrote: >> >> On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <jonathan@xxxxxxxxxxxxx> >> wrote: >> > 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-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" 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 >> storage. >> >> > 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: >> >> http://opensource.rock-chips.com/wiki_Boot_option >> >> 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 >> >> Peter > > _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx/message/4ZK5HZEVIZS3NPQAKIAWFFNRBWR4D5P6/
