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:
- Grub/U-Boot loads the zImage *somewhere*
- 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/driver...
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