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).
Round 4: still black with no backlight at all. Stage-0 enables the
backlight as its first act and the menu proved the backlight works via
GPIO 43/176, so the writes had to be missing. Re-derived GpioRegs from
the device-era mt8183.h: dir[6]@0x000 + rsv00[160] puts dout[6] at
0x100, not the 0x140 claimed in the Round-1 notes. Old addresses set
pin 172 (I2S1_MCK) instead of 43 and hit a reserved region instead of
176.
Also fix the blink: writing 0 to a set register is a no-op; use the
rst register with the bit.
This reframes rounds 2-4: OVL revival and fills may have been working
all along — an LCD shows nothing without backlight. Both round-1
register misreads (OVL_EN 0x0F00, dout 0x140) are now [REVERSED].
Payload 55ccc1bd... flashed and verified (cmp + vbutil). host_test and
qemu_test pass.
Round 3: still black with the corrected OVL_EN offset. All device-era
display_cleanup steps are now provably undone, and init_screen()
sequencing proves the menu was drawn into the LBIO physical_address
(OVL_L0_ADDR == pa), so revival + fills are correct on paper. The
unexcluded branch: the payload may never execute — internal boot of a
custom p1 image was never baseline-proven on this device.
Diagnostic payload (9d7859dc...):
- first instructions: OVL_EN=1, OVL0_2L_EN=1, backlight on (no parse)
- parse failure: 5 slow backlight blinks, spin
- parse success: red -> yellow -> green -> blue, blue held
Decision tree: colors = pipeline validated; blinks on black = parse
failed at runtime; nothing = payload never handed off.
An earlier design read OVL_L0_ADDR pre-parse; abandoned: unassigned
MMIO reads data-abort on qemu -M virt (killed the test) and would do
the same on hardware with a gated display clock. The stub now has no
MMIO reads.
host_test and qemu_test pass; flashed and verified on device.
Round-1 revival wrote the overlay-enable register at 0x14008000+0x0F00;
depthcharge's mtk_ddp.c (2021 revision 497450b4, current tree, merge
commit 74376061, and Linux mtk_disp_ovl.c) defines DISP_REG_OVL_EN at
0x000C. The wrong-register write left the OVL engine disabled, so all
checkpoint fills were invisible (Round 2: black screen with payload
verified intact on mmcblk0p1).
Also: resolve the open physical_address question in RESEARCH.md (LBIO
fb addr is provably non-zero at runtime — mtk_display_init programs
OVL_L0_ADDR from the LBIO record and the dev menu rendered through it),
and log the /dev/mem live-read result (STRICT_DEVMEM + reserved RAM,
'Bad address' rather than EPERM).
Rebuilt payload sha256 9e7cf29d... verified on device (cmp + vbutil
body verification). host_test and qemu_test pass.
Root cause of the black screen, verified against the DEVICE's
depthcharge (v0.0.22-10476, ChromeOS R93-era): display_cleanup() runs
at CleanupOnHandoff before jumping to the payload and
1. clears the LBIO framebuffer to black,
2. drives DISP_PWM (GPIO 43) and EN_LCD_BL (GPIO 176) low,
3. disables the OVL engines (OVL_EN=0, OVL0_2L_EN=0).
DSI/panel/MTCMOS remain up (panel poweroff only exists in 2025+ code),
so the stub just undoes those three steps: re-enable both OVLs, set
both backlight GPIOs, then paint. The OVL_L0_ADDR register still points
at the menu framebuffer, which is the LBIO record address our parser
already extracts.
Minimal freestanding arm64 binary that depthcharge boots as a kernel:
parses depthcharge's /firmware/coreboot DTB node, walks the coreboot
table, finds LB_TAG_FRAMEBUFFER, and paints red/yellow/green/blue
checkpoints (~2s each) into the live boot-splash framebuffer.
Verified against coreboot tables header, Linux arm64 booting.rst, and
depthcharge's fit.c/boot64.c. Host parser tests pass against the live
/sys/firmware/fdt; full red->yellow->green->blue sequence verified
end-to-end under qemu-system-aarch64; packed image verifies with the
ChromeOS devkeys.
vhaudiquet