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 rksdmmc@ff520000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 9
Scanning disk rksdmmc@ff500000.blk...
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 <pbrobinson@gmail.com> wrote:
On Fri, Aug 10, 2018 at 2:23 AM, Jonathan Vaughn <jonathan@creatuity.com> 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@gmail.com> wrote:
>>
>> On Thu, Aug 9, 2018 at 2:40 AM, Jonathan Vaughn <jonathan@creatuity.com>
>> 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
>
>
No comments:
Post a Comment