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/ima... does not boot on any system using U-Boot, like for example the raspberry pi.
Best Regards, Peter Hjalmarsson
On Sun, 1 Dec 2019, 08:01 Peter Hjalmarsson, kanelxake@gmail.com 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/ima... 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@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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-loa...
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. 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.
Best Regards.
Den sön 1 dec. 2019 kl 19:02 skrev Peter Robinson pbrobinson@gmail.com:
On Sun, 1 Dec 2019, 08:01 Peter Hjalmarsson, kanelxake@gmail.com 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/ima... 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@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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-loa...
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@gmail.com:
On Sun, 1 Dec 2019, 08:01 Peter Hjalmarsson, kanelxake@gmail.com 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/ima... 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@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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@redhat.com:
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-loa...
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@gmail.com:
On Sun, 1 Dec 2019, 08:01 Peter Hjalmarsson, kanelxake@gmail.com 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/ima... 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@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Hi,
I have until now just used the workaround of copying the "dtb" directory to the efi directory so uboot can find it during boot, but had the last days a reason to revisit this, when I had to re-setup one of the raspberries. I found out I was mistaken in that it did not boot, and the real problem lies in a "regression" for the Server image in the handling of auto configured serial console output.
I am using the SBCs headless and configure them over serial console during first boot. It turns out that this console works differently if uboot finds and uses the kernel provided device-tree or if it uses its own built-in device tree (or maybe firmware provided for the rpi?). And uboot + grub only seems to auto-configure output on serial console if it finds the kernel provided device tree and loads it. So with older versions of Fedora Server using ext4 on the boot partition uboot find the kernel provided device tree, loads it, and serial console output "just works". On newer images where boot is XFS uboot uses its builtin (or firmware-provided on raspberry?) and uboot+grub fails to auto-configure serial console output.
The two workarounds on raspberry pi are to: 1. "cp -rL /boot/dtb /boot/efi/" or 2. add "console=tty0 console=ttyS0,115200" to the kernel command line in grub
The difference in configuration between the two device trees can also be spotted in dmesg after successfully bootup.
How to reproduce: 1. Write the Fedora 32 aarch64 "server" image to an sd-card. 2. edit /boot/efi/config.txt and set "enable_uart=1" 3. pop the sd-card into a rpi3, connect a serial console, and connect a monitor 4. boot You will during uboot notice that it fails to find any dtb (as uboot cannot load a file from xfs), and proceeds to boot and show grub. After grub you vill notice that the serial console outputs the following and then nothing more: ``` 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... ```
The output on the monitor will pause with the same for a second, then continue with printk, and the output from dracut and systemd during the rest of the bootup. On the monitor will start initial-setup during bootup, and after that present login prompt. No login prompt will present itself on the serial console. Run the following after you have logged into the system: ``` # dmesg | grep tty [ 0.001030] printk: console [tty0] enabled [ 4.725695] 3f215040.serial: ttyS0 at MMIO 0x3f215040 (irq = 61, base_baud = 31250000) is a 16550 [ 5.254904] 3f201000.serial: ttyAMA1 at MMIO 0x3f201000 (irq = 66, base_baud = 0) is a PL011 rev2 [ 28.776063] systemd[1]: Created slice system-getty.slice. # copy -rL /boot/dtb /boot/efi/ # systemctl reboot ``` You will now notice that uboot tells you it found a dtb on the vfat-formatted efi partition and loaded it, and you will also see grub and the kernel outputs everything from bootup on both the serial console and on the monitor, and end it with a login prompt on both.
``` # dmesg | grep tty [ 0.000897] printk: console [tty0] enabled [ 4.495976] 3f215040.serial: ttyS1 at MMIO 0x3f215040 (irq = 61, base_baud = 31250000) is a 16550 [ 5.492585] printk: console [ttyS1] enabled [ 6.204865] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 66, base_baud = 0) is a PL011 rev2 [ 6.224175] serial serial0: tty port ttyAMA0 registered [ 31.499803] systemd[1]: Created slice system-getty.slice. [ 31.668768] systemd[1]: Created slice system-serial\x2dgetty.slice. ```
So there is a kind of "regression" in that the serial console output are not any longer auto configured on the Server-image. It is also hard to document as the correct tty to use for serial console is different between images depending on the FS for /boot
Best Regards, Peter Hjalmarsson
-
Paul Whalen -
Peter Hjalmarsson -
Peter Robinson