Re: [REGRESSION] boot fails for EFI boot stub loaded by u-boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/18/23 10:34, Ard Biesheuvel wrote:
(cc Heinrich)

Hello Ben,

Thanks for the report.

On Wed, 18 Oct 2023 at 03:19, Ben Schneider <ben@xxxxxxxxx> wrote:

Hi Ard,

I have an ESPRESSObin Ultra (aarch64) that uses U-Boot as its bootloader. It shipped from the manufacturer with with v5.10, and I've been trying to upgrade. U-Boot supports booting Image directly via EFI (https://u-boot.readthedocs.io/en/latest/usage/cmd/bootefi.html), and I have been using it that way to successfully boot the system up to and including v6.0.19. However, v6.1 and v6.5 kernels fail to boot.

When booting successfully, the following messages are displayed:

EFI stub: Booting Linux Kernel...EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
EFI stub: Using DTB from configuration table
EFI stub: ERROR: Failed to install memreserve config table!
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

I suspect many of the above error messages are simply attributable to using U-Boot to load an EFI stub and can be safely ignored given that the system boots and runs fine.

These messages are not typical for launching a kernel via the EFI stub from U-Boot. It should look like this:

=> load mmc 0:1 $fdt_addr_r boot/dtb
28846 bytes read in 6 ms (4.6 MiB/s)
=> load mmc 0:1 $kernel_addr_r boot/vmlinuz
53686664 bytes read in 2223 ms (23 MiB/s)
=> setenv bootargs root=/dev/mmcblk0p1 efi=debug earlyprintk initrd=boot/initrd.img
=> bootefi $kernel_addr_r $fdt_addr_r
Card did not respond to voltage select! : -110
Failed to load EFI variables
Booting /boot\vmlinuz
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Loaded initrd from command line option
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]



I suspect that these are not as harmless as you think. How old is the
u-boot build on this platform?

When boot fails (v6.5), the following messages are displayed:

EFI stub: Booting Linux Kernel...
EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary
EFI stub: ERROR: Failed to install memreserve config table!
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
EFI stub: ERROR: Unable to construct new device tree.
EFI stub: ERROR: Failed to update FDT and exit boot services

In case it's relevant, the device tree for this device is arch/arm64/boot/marvell/armada-3720-espressobin-ultra.dts


This is a uboot path, right? Not a linux path? Are you sure this DTS
is compatible with the v6.5 kernel?

There is no arch/arm64/ in U-Boot. Maybe arch/arm64/boot/dts/marvell/armada-3720-espressobin-ultra.dts?

Best regards

Heinrich


Hopefully I've reported this in the correct place or that the information provided is sufficient to get it where it needs to be. Let me know if there is additional information I can provide. I am also able to use the device to test.


Please add some efi_warn() message inside the update_fdt() routine in
drivers/firmware/efi/libstub/fdt.c to narrow down which call is
causing it to return an error. Nothing in that code jumps out to me,
but we regularly update libfdt in the kernel as well, so it might be a
change in there that triggers this.




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux