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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot