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

[Heinrich Schuchardt]

On 7/2/19 6:55 PM, Leif Lindholm wrote:
> 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
> ?

That debug output is ever so strange. Why would loader/arm64/linux.c be
invoked on a 32bit system?

This is the output on my Wandboard that fails to boot (I do not see much
of a difference to the output for the OrangePi PC below):

Loading Linux 4.19.55-armmp ...
loader/arm64/linux.c:60: UEFI stub kernel:
loader/arm64/linux.c:61: PE/COFF header @ 00004550
loader/arm64/linux.c:313: kernel file size: 4231680
loader/arm64/linux.c:316: kernel numpages: 1034
loader/arm64/linux.c:332: kernel @ 0x6e202000
Loading initial ramdisk ...
loader/arm64/linux.c:257: Loading initrd
loader/arm64/linux.c:274: [addr=0x2e1f0000, size=0x1e0e89b]
kern/efi/fdt.c:38: found registered FDT @ 0x17f00000
loader/efi/fdt.c:62: allocating 37888 bytes for fdt
loader/arm64/linux.c:89: Initrd @ 0x2e1f0000-0x2fffe89b
loader/arm64/linux.c:143: linux command line:
'BOOT_IMAGE=/vmlinuz-4.19.55-armmp
root=UUID=14868a8b-ade1-432a-896f-eb16f9a36bfd ro earlyprintk'
loader/arm64/linux.c:158: starting image 0x8edb9d80
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

This is the output on an OrangePi PC also with Debian Buster which boots
successfully:

Loading Linux 4.19.0-5-armmp-lpae ...
loader/arm64/linux.c:60: UEFI stub kernel:
loader/arm64/linux.c:61: PE/COFF header @ 00004550
loader/arm64/linux.c:313: kernel file size: 4370944
loader/arm64/linux.c:316: kernel numpages: 1068
loader/arm64/linux.c:332: kernel @ 0x6a72b000
Loading initial ramdisk ...
loader/arm64/linux.c:257: Loading initrd
loader/arm64/linux.c:274: [addr=0x5ec96000, size=0x1368074]
kern/efi/fdt.c:38: found registered FDT @ 0x47f00000
loader/efi/fdt.c:62: allocating 21504 bytes for fdt
loader/arm64/linux.c:89: Initrd @ 0x5ec96000-0x5fffe074
loader/arm64/linux.c:143: linux command line:
'BOOT_IMAGE=/vmlinuz-4.19.0-5-armmp-lpae
root=UUID=61ca5c77-c7f1-4d01-9260-983fa9a7477a ro'
loader/arm64/linux.c:158: starting image 0x79fbf840
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
EHCI failed to shut down host controller.

Best regards

Heinrich

>
> Also, what is the uncompressed size of your kernel image?
>
> Best Regards,
>
> Leif
>