Hi,
Sorry for late answear, RL and work hit me.
Interesting that this works for you.
I have tested this on two devices and they do not boot from power off
with a freashly made installation:
Rock 64 rk3328 4GB V2.0
Raspberry PI 3B v1.2 (different revision of the board?)
For both u-boot tries to load the DTB, but fails sine it cannot read
the files off of XFS.
(you get from uboot a couple of "** Unrecognized filesystem type **"
while it probes filesystems for the dtbs)
After that they start grub2 which start the kernel, which ends at:
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
And after that nothing, and I have let it stand like that for hours so
it is not that I am impatient.
The setup for the raspberry is as follows:
A SD card written out with:
$ sudo fedora-arm-image-installer
--image=Fedora-Server-31-1.9.aarch64.raw.xz --media=/dev/sdc -y
--target=rpi3
After that I have enabled the UART in /boot/config.txt to be able to
see the printout from uboot and from the kernel. After that, plugged
it ind tried to boot it.
The setup for the Rock64 is as follows:
A USB-drive written with:
$ sudo fedora-arm-image-installer
--image=Fedora-Server-31-1.9.aarch64.raw.xz --media=/dev/sdc -y
--target=rpi3
A SD-card written with:
$ sudo dd if=/usr/share/uboot/rock64-rk3328/idbloader.img of=/dev/sdd seek=64
$ sudo dd if=/usr/share/uboot/rock64-rk3328/u-boot.itb of=/dev/sdd seek=16384
Putting the sdcard into the Rock64, and the USB-drive inte one of the
USB2-sockets, and powering it on, the rock64 locks up in the same
place as the rpi3.
By putting the /boot/dtb directory into the efi vfat-filesystem
instead, I can see u-boot find and load the dtb before starting grub2
("Found DTB usb 0:1 /dtb/rockchip/rk3328-rock64.dtb" in uboot), and
when doing this, the system boots without problem.
@Peter Robinson , the following comment, I think the final part is
maybe misleading:
"On aarch64 we use uefi which loads grub2 off a vfat partition, which
in turn has a XFS driver so this isn't an issue."
The uefi-part on these SBCs, does that not come from u-boot, which
either uses its own DTB, or loads a DTB from disk if it can? This DTB
is then in turn inherited by grub2 and the linux kernel.
By adding "devicetree ($root)/dtb/rockchip/rk3328-rock64.dtb" to
grub.cfg I was also able to work around the problem (as grub2 as you
pointed out can read XFS), so it really looks like that the DTB loaded
by/embedded in u-boot is the one being used.
Grapsing at straws, cannot really explain in any other way why to
boards always boot fine if the DTBs are located so that if u-boot
loads the, the kernel boot without problems, however else it does not.
And find it really strange that my rpi3 does not bott, but yours do.
BR,
Peter Hjalmarsson
Den mån 2 dec. 2019 kl 18:00 skrev Paul Whalen <pwhalen@xxxxxxxxxx>:
>
>
> Hi Peter,
>
> ----- Original Message -----
> > Hi,
> >
> > That is true unless your board need a FDT.
> > Then the following patch breaks that assumption that /boot is not
> > needed before grub2 starts:
> > https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/uefi-distro-load-FDT-from-any-partition-on-boot-device.patch
> >
> > The ways to reproduce for me is:
> > Writing the image mentioned above to a SD-Card and trying to boot it
> > in a Raspberry PI 3B.
>
> The aarch64 server image was tested and boots on the rpi3(B/B+) and
> pine64_plus using the provided uboot.
>
> > I can also reproduce the behavior by writing the image to a USB-stick,
> > and using a self built version of U-Boot (which is mainline upstream
> > incorporates the mentioned patch and "use Fedora specific EFI
> > path/name" as well as using the binary blob for memory init from
> > rockchip since the one you can build from mainline is not stable on my
> > card).
> > Both setup fails with Fedora31 server images. Both boots fine with
> > Fedora30 server images.
> > Will see if I can produce logs, needs to re-write some SD-card for that
> > first.
>
> Thanks! Attached is a boot of the server image on the rpi3b+.
>
> Paul
>
> >
> > Best Regards.
> >
> > Den sön 1 dec. 2019 kl 19:02 skrev Peter Robinson <pbrobinson@xxxxxxxxx>:
> > >
> > >
> > >
> > > On Sun, 1 Dec 2019, 08:01 Peter Hjalmarsson, <kanelxake@xxxxxxxxx> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Just wanted to point out that due to U-Boot not supporting XFS, and Fedora
> > >> Server has moved to a XFS /boot, the current images as
> > >> https://dl.fedoraproject.org/pub/fedora/linux/releases/31/Server/aarch64/images/Fedora-Server-31-1.9.aarch64.raw.xz
> > >> does not boot on any system using U-Boot, like for example the raspberry
> > >> pi.
> > >
> > >
> > > On aarch64 we use uefi which loads grub2 off a vfat partition, which in
> > > turn has a XFS driver so this isn't an issue.
> > >
> > > You'll need to go into more explicit details of what you're doing and which
> > > devices.
> > >
> > >> Best Regards,
> > >> Peter Hjalmarsson
> > >> _______________________________________________
> > >> arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
> > >> To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > >> Fedora Code of Conduct:
> > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >> List Archives:
> > >> https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
> > _______________________________________________
> > arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
> >
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
