vhaudiquet da4aaca1c2 stub: accept LBIO physical_address == 0 — it is the real record here ...

Round 5: the Round-4 diagnostic blinks decoded as parse_fail. Root cause
confirmed in coreboot 4.14 source (kukui mainboard.c + edid_fill_fb.c):
the LBIO framebuffer record genuinely has physical_address = 0 — the
menu renders through DRAM address 0, which the never-stopped OVL scans
out (display_init_required() is false, so depthcharge registers no
display ops and its handoff cleanup's backlight/stop calls are no-ops).

Round-2's 'menu proves pa != 0' reasoning was wrong; the original
open-item note was right. The stub's !fb->pa rejection caused every
parse failure. find_framebuffer now accepts pa == 0 and the stub paints
at address 0, the same region depthcharge's own cleanup black-fills.

host_test gained a pa==0 regression test; qemu_test unchanged. Payload
b25d9132... flashed and verified (cmp + vbutil).

2026-08-29 23:09:37 +02:00

18 KiB

Executable File

Raw History

View Raw