One thing I recently noticed about the Zeus boot process is that it prints an EFI stub error, but still proceeds to boot successfully (and has been reliable for 4+ years on hundreds of devices).
Zeus boot log (doing u-boot → grub → uefi stub → kernel, as per the Zeus board integration thread here ):
U-Boot SPL 2018.03-imx_v2018.03_4.14.78_1.0.0_ga_var02+g717f29898a (Jun 04 2021 - 01:59:18 +0000)
Part number: VSM-VS6UL-211
Assembly: AS205183446
Date of production: 2022 Jun 26
SOM configuration: eMMC
Trying to boot from MMC1
MMC Boot Device: mmc1 (eMMC)
U-Boot 2018.03-imx_v2018.03_4.14.78_1.0.0_ga_var02+g717f29898a (Jun 04 2021 - 01:59:18 +0000)
CPU: Freescale i.MX6ULL rev1.1 900 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 44C
Reset cause: POR
Board: Variscite VAR-SOM-6UL
I2C: ready
DRAM: 512 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
Display: VAR-WVGA-LCD (800x480)
Video: 800x480x24
** Unrecognized filesystem type **
Error: could not access storage.
In: serial
Out: serial
Err: serial
eMMC: 7.3 GiB
Net: got MAC0 address from fuse: f8:dc:7a:85:65:2c
FEC0 [PRIME], usb_ether
Error: usb_ether address not set.
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
31198 bytes read in 18 ms (1.7 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Disk usb0 not ready
Disk usb1 not ready
Disk usb2 not ready
Disk usb3 not ready
Scanning disks on mmc...
MMC Device 2 not found
MMC Device 3 not found
Found 10 disks
385024 bytes read in 26 ms (14.1 MiB/s)
## Starting EFI application at 82000000 ...
Welcome to GRUB!
lock: OK
lock: OK
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: ERROR: Failed to install memreserve config table!
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.3-imx6ul+g9447bf00ed07 (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Wed Jun 2 08:00:42 UTC 2021
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: T VAR-SOM-6UL with i.MX6ULL, eMMC & SD card support
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.70 by Das U-Boot
[ 0.000000] efi: SMBIOS=0x9df3e000
[ 0.000000] cma: Reserved 32 MiB at 0x9a000000
[ 0.000000] percpu: Embedded 15 pages/cpu s32332 r8192 d20916 u61440
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 129919
[ 0.000000] Kernel command line: BOOT_IMAGE=(hd1,2)/boot/zImage root=/dev/mmcblk1p2 console=ttymxc0,115200n8 rootwait
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
... continues to boot successfully
As you can see, just prior to the kernel booting it prints EFI stub: ERROR: Failed to install memreserve config table!
Not sure whether it’s a red-herring - kernel/uefi/efistub is way outside my realm of knowledge - but if you compare the Zeus kernel efi-stub code with Scarthgap’s efi code (which is substantially different) in these two files:
efi-stub.c and arm32-stub.c
There are two things I noticed:
In Zeus, the memreserve error message actually results from a failed efi call to install_configuration_table, but it doesn’t care - the function’s return type is void and it continues booting.
In Scarthgap, the failure results from a call to install_configuration_table (ableit with very different args & intent), and the function returns the error (rather than void or EFI_SUCCESS), and it’s a lot earlier in the efi_stub_common method.
Where to go from here - not sure yet - the EFI stub seems to be a lot more complex compared to the Zeus one, with a large number of changes. Perhaps crudely attempting to port in the Zeus’ libstub folder to Scarthgap (and hoping there aren’t wider tendrils that need fixing) would be worthwhile? No idea… kernel changes are not something I’ve attempted before 