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).

RESEARCH.md

@@ -284,6 +284,43 @@ Payload `55ccc1bd…` flashed (cmp + vbutil OK). host/qemu tests pass.
 | colors appear but sequence stops early | fill/mask problem — stuck color identifies stage |
 | red → yellow → green → blue, blue held | pipeline fully validated |
 
+## Round 5 — blinks decoded: LBIO physical_address really IS 0
+
+The Round-4 payload's diagnostic worked: 3–5 backlight blinks then steady
+backlit black = `parse_fail()`. The stub runs, stage-0 works, the GPIO fix
+works — the parse rejected the LBIO framebuffer record. Root cause found
+in the actual coreboot **4.14** source (fetched from the 4.14 tag):
+
+- `src/mainboard/google/kukui/mainboard.c` (4.14) is identical to
+  mainline: `fb_new_framebuffer_info_from_edid(edid, 0)` — and 4.14's
+  `edid_fill_fb.c` passes `fb_addr` through verbatim, no carveout, no
+  allocation. **The LBIO record on this device genuinely has
+  physical_address = 0.**
+
+How the menu still renders: libpayload cbgfx draws into
+`phys_to_virt(pa)` = DRAM address 0, and coreboot's display pipeline scans
+out address 0. With `pa = 0`, depthcharge's `display_init_required()` is
+false, so board.c never registers display ops — meaning at handoff
+`display_cleanup` runs but `backlight_update` and `stop` are no-ops:
+**the OVL was never stopped and the backlight never disabled by
+depthcharge.** The "menu vanishing" was just the 9.2 MB black fill at
+address 0 (safe for the payload: depthcharge itself does it after the
+kernel slot is chosen, and the stub demonstrably survived every round).
+
+**Round-2's "open item resolved" reasoning was wrong** — menu rendering
+does NOT prove pa != 0, because address 0 works as a framebuffer region.
+The original Phase-1 note ("mainline coreboot passes fb_addr=0 for kukui")
+was correct all along. All five black screens so far trace to the stub's
+`!fb->pa` rejection of a legitimate record (plus the two Round-1 register
+offset misreads, which additionally kept the backlight dark).
+
+Fix: `find_framebuffer` accepts `pa == 0` and the stub paints at address
+0 — the buffer the still-running OVL scans. OVL revival and backlight
+writes are kept but are now believed to be redundant on this firmware.
+
+Payload `b25d9132…` flashed (cmp + vbutil OK). host_test gained a pa==0
+regression test; qemu_test unchanged (its synthetic record uses pa!=0).
+
 Recovery: power-cycle, boot USB (unchanged), `dd if=mmcblk0p1-pmos-backup.img
 of=/dev/mmcblk0p1 bs=4M conv=fsync`.