vhaudiquet 0688a7549b stub: fall back to fixed coreboot table address; DTB buffer reads zeros ...

Round 9, hex dump decoded:
  x0          = 0x5F800000 (= _fit_fdt_start, depthcharge's own FDT
                buffer; the kernel reserves 5f800000-5f815fff for it)
  dt[0..3]    = all zeros — no FDT magic at payload entry
  OVL_L0_ADDR = 0xFD536000 (real scanout, top-of-DRAM reserved region)

The device-era boot path flattens the fixed-up tree into
_fit_fdt_start and hands off that pointer. Why the kernel sees a valid
FDT there while the payload sees zeros is open (leading suspicion:
cache flush behavior differing with the ~30 MB pmOS kernel vs the
18 KB stub).

For the stub this is moot: the coreboot table address is a memlayout
constant on this board (0xffed9000, confirmed by the kernel's coreboot
driver, sysfs tags and /sys/firmware/fdt). find_coreboot_reg failure
now falls back to it instead of halting; the stub no longer depends on
the DTB. find_framebuffer failure still dumps the raw LBIO bytes.

Payload adbea06f... flashed and verified. host_test and qemu_test pass.

2026-08-30 00:32:36 +02:00

18 KiB

Executable File

Raw History

View Raw