From 26984768cf1472a946ee7e55b5468443411e2182 Mon Sep 17 00:00:00 2001 From: vhaudiquet Date: Sun, 30 Aug 2026 12:08:07 +0200 Subject: [PATCH] Round 17: body-size ruled out; total-size bisect flash (Test A) --- RESEARCH.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/RESEARCH.md b/RESEARCH.md index bb7ff26..64d64c3 100644 --- a/RESEARCH.md +++ b/RESEARCH.md @@ -687,3 +687,27 @@ but with R14's body size (0x81000, via the larger R15 U-Boot): |---|---| | green (persistent) | body size innocent; the 0x1000 offset somehow guilty — re-bisect | | black | FIT body > 0x80000 breaks this depthcharge — fix = keep FIT under 512 KiB (minimal FDT subimage) with U-Boot @0x1000 | + +## Round 17 — R16 green decodes body-size theory; total-size bisect + +R16 (R13 layout, body 0x81000): **green** — body size ruled out (R16 +and R14 share body 0x81000). Updated correlation: total wrapped-image +size / image_size field: ran ≤ 449772, dead ≥ 453432. Device-era +sources recovered far enough to rule out boot64/fit_decompress size +checks (kukui r93/12573-B code identical modulo cosmetics; bounds +0x5f800000/0x60000000/0x80000000 — kend≈0x4006xxxx passes; the loader +is DETERMINISTIC: first CB_MEM_RAM range, kstart=0x40000000 — the +"random 2 MiB slot" note from Phase 1 was mainline behavior, [REVERSED] +for the device). + +### Test A (payload a27f0354…, flashed, cmp+vbutil OK) + +R16's exact known-good content (wrapper v1 green, U-Boot @0xB4, +contiguous — wfi hang expected) + 8 KiB zero tail padding → total +457964, image_size=457964, body 0x83000. Isolates TOTAL SIZE from the +0x1000-offset/padding variable: + +| observation | conclusion | +|---|---| +| green | total size innocent → the 0x1000 alignment padding/placement is the killer (re-test padding content) | +| black | total size (image_size value) alone gates the handoff |