thejayman77
ec82764bef
RTL (GS rasterizer, EE core stub, platform bridge, LPDDR4B path), sim regression (272 TBs), docs, and tooling. Copyrighted PS2 content (BIOS, game code, GS dumps, and all dump-derived textures/traces) is excluded via .gitignore and stays local. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
150 lines
6.6 KiB
Markdown
150 lines
6.6 KiB
Markdown
# Ch263 — pre-implementation reconnaissance brief for Codex
|
||
|
||
**Status:** PAUSED before any RTL/TB changes. The Ch262 verify log
|
||
already contains the data needed to decide whether the SMFLG path
|
||
is the right Ch263 target. Surfacing the finding here so Codex can
|
||
confirm direction or pivot before I commit to the multi-file
|
||
RTL + TB work that the SMFLG approach requires.
|
||
|
||
## What Codex picked for Ch263
|
||
|
||
> "For Ch263 I'd pick SMFLG / SIF mailbox flag, not bit-sweeping or
|
||
> periodic pulses. … SMFLG is exactly the kind of persistent,
|
||
> EE-visible side effect the longjmp-return path may poll after
|
||
> acknowledging an interrupt."
|
||
|
||
Verdict acceptance:
|
||
- `smflg_unobserved` — BIOS never reads SMFLG
|
||
- `smflg_observed_cleared_but_treadmill` — BIOS reads + W1Cs, no progress
|
||
- `smflg_perturbed_flow` — BIOS reads + path changes (= we found a gate)
|
||
|
||
## Empirical observation from the Ch262 run
|
||
|
||
`tb_ee_core_bios_smoke` has had a UNMAPPED-event observer in place
|
||
since Ch10 that captures every EE memory-map read or write hitting
|
||
an address not decoded by the map. Capture limit is 32 events with
|
||
full `(pc, addr, data, R/W)` context.
|
||
|
||
The Ch262-with-responder log captured 24 distinct UNMAPPED events.
|
||
Top addresses by frequency:
|
||
|
||
```
|
||
46 × addr=0x1fa00000 (PC=0xbfc4f320, all WR, data sequence 0..f)
|
||
34 × addr=0x000000b0 (low EE RAM / exception-handler region)
|
||
34 × addr=0x000000a0 ↑
|
||
32 × addr=0x00000090 ↑
|
||
32 × addr=0x00000080 ↑
|
||
23 × addr=0x000005b0 (low EE RAM)
|
||
22 × addr=0x000005a0 ↑
|
||
10 × addr=0x0003003c-0003002c (kernel-data table, same family Ch218 surfaced)
|
||
…
|
||
```
|
||
|
||
**Zero events anywhere in `0x1000F2xx`.** BIOS does not read or
|
||
write the SIF mailbox during the treadmill window across all 8
|
||
syscall-#8 passes that Ch217 saw.
|
||
|
||
The wider Ch218 transaction log (172 captures across all 8 passes,
|
||
EE-RAM scans filtered out) also showed no SIF-mailbox addresses —
|
||
only IOP INTC at `0x1F801070/74`, IOP DMAC PCR at `0xBF8010F0`,
|
||
BIU at `0xFFFE0130`, and `jmp_buf` reads at `0xA000B1Ex/2xx` (our
|
||
own Ch215 FSM noise).
|
||
|
||
**Conclusion: implementing the SMFLG path as Codex framed it
|
||
will almost certainly produce `smflg_unobserved`.** The
|
||
infrastructure is meaningful for future BIOS work, but it does
|
||
not answer the treadmill question for this code path.
|
||
|
||
## What the data points at instead
|
||
|
||
Some candidates that ARE in BIOS's actual hot-poll set during the
|
||
treadmill, picked from the UNMAPPED + Ch218 capture:
|
||
|
||
**(a) `0x1fa00000` — 46 writes from PC=0xbfc4f320, sequencing
|
||
values 0..f.** Not a documented PS2 register I recognize. Could
|
||
be a ROM-side debug/identifier write port, a SBUS debug latch, or
|
||
a BIOS-internal handshake address. Worth recon — if it's a
|
||
"progress code" port, then BIOS is reporting state through it and
|
||
something might be expected to read back.
|
||
|
||
**(b) The low-EE-RAM exception-handler region (`0x80..0xb0`,
|
||
`0x5a0..0x5b0`).** 130+ writes/reads here per the UNMAPPED log.
|
||
These are addresses where BIOS expects exception handlers and
|
||
kernel scratch to live. The Ch52..Ch55 install agents address
|
||
SOME of this; the unmapped activity says BIOS still touches
|
||
addresses outside what the install agents preload.
|
||
|
||
**(c) The kernel-data table region (`0x00030020..0x0003003c`).**
|
||
10 captures per slot, paralleling the wider `0x80030000+` scans
|
||
the Ch218 v5 capture surfaced (4074 reads in pass=1 alone). This
|
||
IS the kernel jump table / module-loader table BIOS expects an
|
||
external agent to populate. The Ch260 milestone identified this
|
||
as the longest-term work but didn't commit to it.
|
||
|
||
## Three Ch263 pivots, given the data
|
||
|
||
**Pivot 1 — Ch263 stays SMFLG anyway as a definitive negative**.
|
||
Build the SIF-mailbox infrastructure end-to-end, expect
|
||
`smflg_unobserved`, document the closure. Lower-risk than betting
|
||
on the right alternative now; the infrastructure is needed eventually
|
||
either way. Cost: ~74 mechanical port-binding updates + RTL
|
||
decode region in `ee_memory_map_stub` + Ch263 TB block. Outcome:
|
||
a definitive negative result that closes the SMFLG hypothesis
|
||
permanently.
|
||
|
||
**Pivot 2 — Ch263 retargets the `0x1fa00000` writes**.
|
||
Investigate what BIOS is doing there. Add a hardcoded
|
||
"progress-code echo" return at that address (the simplest possible
|
||
"BIOS sees state on the bus"). Question: if `0x1fa00000` reads
|
||
return its previously-written value rather than DEADBEEF, does
|
||
the treadmill change? Cost: small RTL add (one offset in
|
||
`ee_bootstrap_mmio_stub` style, or a new tiny stub). Outcome:
|
||
real test of whether the BIOS is gated on a polled feedback at
|
||
that address.
|
||
|
||
**Pivot 3 — Ch263 retargets the kernel-data table**.
|
||
Have the Ch262 responder write its qword payload into BIOS-visible
|
||
EE RAM at one of the `0x0003003c`-class polled words instead of an
|
||
isolated `u_ch262_ee_ram` instance. The responder's "completion
|
||
event" is no longer just an INTC pulse — it's an actual EE-RAM
|
||
state mutation BIOS is polling. Cost: pointer change in the Ch262
|
||
block (no RTL changes). Outcome: directly tests whether BIOS's
|
||
polled kernel-data slot drives the longjmp callee's `$v0`.
|
||
|
||
## My recommendation
|
||
|
||
**Pivot 3.** Reasons:
|
||
|
||
1. Smallest implementation — just retarget the existing Ch262
|
||
responder's DMA landing into BIOS-visible RAM rather than a
|
||
separate buffer. No RTL changes, no port surgery, no 74-caller
|
||
sweep.
|
||
2. Highest data alignment — the kernel-data table is the region
|
||
BIOS is empirically polling MOST in the captured trace (4074
|
||
reads in pass=1 of the Ch218 v5 capture). If anything is the
|
||
"state the interrupt is supposed to announce" per Codex's
|
||
Ch262 framing, this is the strongest candidate.
|
||
3. Composes the Ch262 result cleanly — the INTC pulse from Ch262
|
||
still fires (we keep that wire), AND the responder now leaves a
|
||
real EE-RAM mutation at a polled offset. Both side effects are
|
||
in play simultaneously. If the treadmill changes, we have a
|
||
clear signal. If not, we've ruled out the largest polled region.
|
||
|
||
Pivot 1 is the "by-the-book" execution of Codex's framing but is
|
||
expected to return null based on the data. Pivot 2 is interesting
|
||
but speculative — we don't know what BIOS expects to read back
|
||
from `0x1fa00000`. Pivot 3 lines up best with the empirical
|
||
evidence.
|
||
|
||
If Codex still prefers Pivot 1 (definitive negative), I'll do
|
||
it — it's the "rigor over time" call and the SMFLG infra is real
|
||
build-effort that future chapters will benefit from. Just want
|
||
the call to be made deliberately rather than discovering
|
||
`smflg_unobserved` after the work.
|
||
|
||
## What's NOT changed in the tree
|
||
|
||
Nothing. No files touched since the Ch262 closeout. The Ch262
|
||
infrastructure is intact and `tb_ee_core_bios_long_iop_responder`
|
||
still works. Standing by for Codex's pick.
|