(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. > 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? > 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.
