I've gotten U-boot installed into the SPI by using the u-boot-flash-spi-rock64.img.xz from https://github.com/ayufan-rock64/linux-u-boot/releases
So in theory I can boot from not just eMMC or SD but also USB, TFTP, etc. Also, in theory, can boot things that don't have to proper U-boot bits for the Rock64 This works for things like Armbian and such that have Rock64 compatible images that already booted without u-boot in SPI, but does not appear to work for Fedora. Booting AArch64 image I get : Found EFI removable media binary efi/boot/bootaa64.efi reading efi/boot/bootaa64.efi 868376 bytes read in 71 ms (11.7 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 02000000 ... Card did not respond to voltage select! mmc_init: -95, time 9 Scanning disk [email protected]... Card did not respond to voltage select! mmc_init: -95, time 9 Scanning disk [email protected]... Scanning disk usb_mass_storage.lun0... Found 3 disks Something has gone seriously wrong: Device Error Shim was unable to measure state into the TPM When booting armhfp image I get : Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 510 bytes read in 106 ms (3.9 KiB/s) Ignoring unknown command: ui Ignoring malformed menu command: autoboot Ignoring malformed menu command: hidden Ignoring unknown command: totaltimeout Fedora-Server-armhfp-28-1.1 Boot Options. 1: Fedora-Server-armhfp-28-1.1 (4.16.3-301.fc28.armv7hl) Enter choice: 1: Fedora-Server-armhfp-28-1.1 (4.16.3-301.fc28.armv7hl) Retrieving file: /initramfs-4.16.3-301.fc28.armv7hl.img 56591459 bytes read in 2684 ms (20.1 MiB/s) Retrieving file: /vmlinuz-4.16.3-301.fc28.armv7hl 6672896 bytes read in 396 ms (16.1 MiB/s) append: ro root=UUID=7ea4a72f-1f7f-42c0-a0d6-f75138f2419b Retrieving file: /dtb-4.16.3-301.fc28.armv7hl/rockchip/rk3328-rock64.dtb ** File not found /dtb-4.16.3-301.fc28.armv7hl/rockchip/rk3328-rock64.dtb ** Skipping Fedora-Server-armhfp-28-1.1 (4.16.3-301.fc28.armv7hl) for failure retrieving fdt Any ideas what I can try? The armhfp I'm guessing fails because of a lack of support for the device, the dtb file doesn't exist. But the AArch64 image has a more vague "FDT_ERR_BADMAGIC" ... On Tue, Aug 14, 2018 at 8:58 AM, Peter Robinson <[email protected]> wrote: > On Fri, Aug 10, 2018 at 2:23 AM, Jonathan Vaughn <[email protected]> > 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 protected]> > wrote: > >> > >> On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <[email protected] > > > >> 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 -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
