Hello Heinrich, On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote: > Hello Leif, > > the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. > GRUB loads the initial ramdisk into an area which the the mainline > 4.19.55 kernel simply does not accept because it thinks the minimum > address is 0x68000000 and not 0x10000000. Booting via bootz works > without problem. > > Did you see a similar problems before?
Rereading your original report, I realise that the OF error messages comletely distracted me from what you say in the text above: The kernel thinks the minimum address is 0x68000000 (suggesting that is the address the zImage decompresses the runtime kernel to?). Presumably when booting with 'bootz', the minimum address is correctly determined to be 0x10000000? Where the 32-bit ARM kernel locates itself is unfortunately a bit of a Rube Goldberg machine: 1) Grub/U-Boot loads the zImage *somewhere* 2) zImage decompresses itself to *somewhere*else* and jumps to the decompressed copy. When booting with UEFI, *upstream* arm/arm64 GRUB loads the kernel image with grub_efi_allocate_any_pages() and then calls LoadImage/StartImage. (This step goes in between 1 and 2 above.) Some of the distros carry addional patches for "shim" support that modify this behaviour. After LoadImage is called, the EFI stub of the kernel image determines where the runtime kernel is going to be decompressed to (and I think relocates zImage if necessary), and reserves this area, before actually jumping to the zImage: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/firmware/efi/libstub/arm32-stub.c?h=v4.19.55#n194 This always felt somewhat precarious to me. Could you possibly: - add 'set debug=linux' in your grub.cfg and paste the logs - add some printouts to arm32-stub.c ? Also, what is the uncompressed size of your kernel image? Best Regards, Leif _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
