Files
uboot-rtwo/board
snlavaise 7e0a580700 rtwo: switch chainload boot from bootm+FIT to bootefi (EFI stub)
bootm's ramdisk initrd delivery (boot_ramdisk_high()/LMB high-address
placement plus the fixed start/loados/ramdisk/fdt/cmdline/bdt/prep/go
ordering in bootm_run_states()) kept producing a kernel that booted
cleanly but silently discarded its initramfs, ending in "VFS: Cannot
open root device". Confirmed on hardware, multiple attempts, none
panned out (in-place mode collided with the kernel relocation;
reordering bootm substates is rejected by U-Boot itself as "out of
order"; the reserved-memory collision theory was disproven against the
compiled dtb).

Switched to bootefi instead: same FIT (no repackaging), parsed with
imxtract (kernel/fdt/ramdisk each extracted to a separate address),
then booted via the kernel's own EFI stub + LoadFile2 initrd protocol
-- a different code path in both U-Boot (efi_loader, not
boot_ramdisk_high()) and the kernel (efi_load_initrd(), never touches
reserve_initrd_mem()).

Two real bugs found and fixed along the way, both confirmed on
hardware:
- ramdisk destination must not be a hand-computed offset from
   (that address is our own scratch buffer holding the
  whole FIT, not the board's dedicated ramdisk block) -- use
  $kernel_comp_addr_r instead, a separate 64 MiB LMB block the board
  reserves for kernel decompression, unused since our Image is
  uncompressed.
- bootefi's first argument (the kernel) needs an explicit ":size"
  suffix. Without it, cmd/bootefi.c assumes the address was set by a
  prior load/tftp command tracked via efi_set_image_parameters() --
  imxtract never touches that tracking, so the address never matches
  and bootefi fails with "No UEFI binary known" even though the
  bytes there are a perfectly valid kernel image.

CONFIRMED ON HARDWARE 2026-09-18: reaches a live debug shell console.
2026-09-18 00:09:27 -03:00
..