[U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

[Leif Lindholm]

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