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