# Ch441 board validation — framebuffer reconciliation (zsrt139f52)

Scope: reconcile the one framebuffer-content discrepancy seen during the Ch441↔Ch437
A/B, and record the Codex-authorized zero-RTL re-dump triage that classifies it.

## The A/B FB discrepancy (as first observed)

During the Ch441-vs-Ch437 A/B, the Ch437 `--dump-fb` readback logged
`sum32=0xaf7b63f3 xor32=0x33178b8f`, differing from the accepted golden
`sum32=0xaad0b94d xor32=0x33138181`. Local word-level diff localized the entire
difference to **exactly 8 words — the first 256-bit LPDDR beat, row 0, x=0..7, y=0**
(307192/307200 = 99.997% byte-identical). In all 8 words the **alpha byte matched**;
only RGB differed (golden ≈ 0x0b dark, dump ≈ 0xb6 bright, a uniform ~+0xaa lift).
Those 8 words fully account for the logged sum32/xor32 deltas and nothing else.

Artifacts:
- `sh3_zsrt139f52_ch437_ab_fb.mem`  SHA-256 `8fd30cdb926ab7a73c39827a2e3352b72c92af78ebaa7b4d69fd9715bf693aec`
- golden / prior-Ch437 / Ch441 A/B all: SHA-256 `d0047677371a0f6e4e319458926f604a8599c92baaf34d09b8e1fd452e31662b`

Key architectural fact: `--dump-fb` reads LPDDR via `gs_lpddr_rd_probe` (**arid=1**),
a different AXI master from the scanout line-buffer (`gs_lpddr_scanout_lb`, **arid=3**).
So this discrepancy lives on the probe-readback / write path, NOT the scanout/HDMI path.

## Zero-RTL re-dump triage (Codex-authorized; no RTL / Quartus / builds)

Image under test: `retroDE_ps2.ch437.candidate.rbf` (the anomaly image), CORE_ID 0x50533200.
Two independent axes, on the same f52 replay (`sh3_zsrt139f52_epochs.txt`):

1. **Write-side determinism** — three full render+dumps (A/B/C).
2. **Readback determinism** — repeated pure-probe re-reads of words 0..15 via the
   `OFF_LPDDR_RDADDR` (0x03C) latch, with NO re-render, on the frame left by dump C.

### Result — anomaly did NOT reproduce

| dump | SHA-256 | sum32 | words 0..7 |
|------|---------|-------|------------|
| A (render+dump) | `d0047677…` | `0xaad0b94d` | golden (dark) |
| B (render+dump) | `d0047677…` | `0xaad0b94d` | golden (dark) |
| C (render+dump) | `d0047677…` | `0xaad0b94d` | golden (dark) |

First 16 words, identical across A/B/C:
`040c0c0b 030c0b0b 030a0909 030b0b0b 030d0b0b 040e0c0c 050f0e0e 050f0e0e 050b0a0a 050a0909 05090808 050a0a0a 050e0d0d 050d0d0c 050d0c0b 050d0b0b`

Pure-probe re-reads (8 rounds, no re-render) returned those same values every round —
words 0..7 stable and golden, no bright first beat.

### Classification

The earlier 8-word bright first-beat was a **non-reproducible one-time transient** in that
single A/B dump — not a stable property of the stored framebuffer and not a deterministic
write or readback defect. Three fresh renders + repeated probe re-reads are byte-identical
to golden across the full frame, including words 0..7. **Framebuffer-memory integrity for
this scene is confirmed deterministic (`d0047677…`).** Evidence integrity is resolved.

This triage does NOT diagnose `LPDDR_STATUS[5]`; that is the scanout/HDMI (arid=3) path,
addressed separately (see `scanout_status_bit5_proposal.md`).

### Raw logs
`sh3_zsrt139f52_ch437_redump_[ABC].log`, `redump_triage_console.log`.