# Offline triage: could `0x403` write the PSP transfer-slot descriptors?

**Status: signed-code target lead, not a live DMA or protection-bypass result. No new device request.** Do not write this block to test an opcode/status: it may hold *live* transfer/protection slots and there is no independent restoration oracle. The proven GCP→ASD `0x403` write is only established at two benign scratch addresses, not at this block.

## A specific PSP-side target, unlike host-programmable LSDMA

Signed SYS_DRV `.54` `sub_E218FC` computes `0x49007A00 + 24*slot + field`, checks the offset `<0x180`, and calls **`SVC 0x7C` width 4**. The matching `sub_E15EF0` calls **`SVC 0x7B` width 4** at the same indexed addresses. `sub_E1447C` calls `sub_E17EF4` to find/own a free slot, then writes start-page (`+0`), inclusive end-page (`+4`), mode/active bits (`+8`) and parameter (`+12`) for selected region classes. For class `0x31` it reaches all four writes. The owner/overlap table and slot index are **software gates** on the SYS_DRV route; GCP→ASD `0x403` does not invoke them. In sOS `.54`, `sub_6D20`'s address exclusions do **not** cover `0x49007A00`, but guard allowance is not proof of endpoint decode or requester acceptance.

The signed `.54` class switch at `sub_E1447C:0xE1454E..0xE1462C` **does not put the caller's region ID or an arbitrary source pointer directly into descriptor `+12`**. Representative cases before the final `sub_E218FC(slot, 8, mode)` and `sub_E218FC(slot, 12, parameter)`:

| region class | `+8` mode | `+12` parameter |
| --- | --- | --- |
| `0x31`, `0x32` | `0x37` | fixed `0x30038` |
| `0x33` | `0x37` | fixed `0x200038` |
| `0x53` | `0x37` | fixed `0x70038` |
| `0x68` | `0x37` | fixed `0x3F0038` |
| `0x54` | `0x35` | fixed `0x70038` |

The class switch admits additional modes and two auxiliary fixed `SVC 0x7C` stores; this is not a complete instruction-to-class table. In the signed `.54` direct xrefs to the bounded slot reader `sub_E15EF0`, **all six callsites** in `sub_E17EF4` and `sub_E13ABC` select only offsets `+0`, `+4` or `+8`; the eight direct xrefs to writer `sub_E218FC` include **`+12` writes but no signed `+12` readback through that helper**. This is not an exhaustive survey of every possible register reader, but it leaves the descriptor parameter's preimage and exact restoration unresolved even if a slot index were known. **If** the hardware interprets `+12` as a source or access-domain selector, a direct chosen fabric write could escape this signed software fixed-value set. Its actual semantics, accepted encodings and side effects are unknown; the repeated `...0038` shape is not a proof that it is a PSP physical address. In fact the **Navi22-only** `~/nv22_a0_memmap.txt` calls numeric `0x00030038` `GC_CP.CP_NUM_PRIM_NEEDED_COUNT1_LO` (an aliased graphics counter), **not** a SPI source. That name cannot be projected onto Navi31 but rules out treating the number alone as proof of a source pointer. Do not program it for a status check.

On a prior stock `.54` card, free SYS_DRV `0x105D` reached its leaf but returned `0xFFFF000F` before those descriptor writes (`fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md`). Its allocator `sub_E17EF4` returns that value for either a failed `SVC 0x7B` read or no free slot. Signed sOS `.54`'s `SVC 0x7B` case validates the destination and calls `sub_4730`; for an admitted width-4 read `sub_4730` returns 0 after mapping and loading, while an unmapped bus target might instead fault/stall. A full 16-slot table is therefore plausible, **not measured**; do not reclassify the clean `0xFFFF000F` as proof of PSP hardware denial. Writing over an occupied slot could disrupt another active client.

### Host-only readback is not an oracle for these slots

A narrowly bounded **read-only host SMN-window** check (standard `PCIE_INDEX2/DATA2`, not a PSP or DMA-register write) queried slot-0 `+8` at `0x49007A08` twice and slot-3 `+8` at `0x49007A50` once. All returned their **byte-swapped address mirrors** (`0x087A0049` twice; `0x507A0049`), interleaved with bogus `0x0FEEDC00 → 0x00DCEE0F` and live MP0 control `0x03810ACC → 0x80000000` before/after. One DF IH message appeared after the run; it has not been causally attributed to a particular read. This establishes **no host-SMN slot value**, not a hardware-zero or a PSP-fabric denial. There is no independent host readback/restoration oracle for slot writes on this card; **do not broaden the host survey or write these addresses** on the strength of mirrors/status.

## Correct a consequential `SVC 0xA1` label

Both signed sOS `.51` (`sub_5A0C`, case 80) and `.54` (`sub_59E8`, case 80) implement `SVC 0xA1` as **three stores to sOS global range/bounds words** (`.54` xrefs via `off_6440`/`off_6444`, as scoped in `fw/LEAD-GCP-SYSDRV-101E-OWNER-BYPASS-TEARDOWN.md`). There is no DMA kick in either case. SYS_DRV `.54` `sub_E142A0` invokes `SVC 0xA1` only **after** successful `sub_E19118` calls have written the fixed descriptor block for several classes; its `sub_E1447C`/`0x105D` path does **not** invoke `0xA1`. Earlier prose in `fw/DIFF-SPIROM_XFER-51-VS-54-TMR-FIX-SCOPE.md` and `psp_out/VULN-CONFIRMED-TMR-RANGE-ROLLBACK.md` described `SVC 0xA1` as a DMA “commit” and inferred `0x105D` was inert because it lacked that SVC. **That rationale is wrong.** It does **not** follow that descriptor writes alone execute a copy: the signed code may stage a protection window, a command may be elsewhere, and the `.51` host-observed `0xFF` striped memory after SETUP_TMR does not isolate which instruction caused it. Retain the independent `.51` observation and the `.54` post-boot allocator failure; retract only the unsupported causal/negative inference.

The `.54` SETUP_TMR `sub_E142A0` also calls `sub_E2136C` and `sub_E212DC` before slot writes. These are **range/overlap checks** (the latter wraps two fixed-range `sub_E0F2F0` checks), not a proven DMA commit. `sub_E19118` constructs the destination from its stored base plus offset and calls `sub_E1447C`; whether the peripheral acts when its control/parameter words are written is a **hardware-semantic unknown**.

## Boundary to a useful effect

To upgrade this from a target lead requires all of: (1) identify a *free* slot and the engine's operational state without destructively overwriting live entries; (2) show that ASD's width-4 fabric access with its window attribute (the demonstrated `R3=12`, encoded as `0xCC`) is accepted like SYS_DRV's access, rather than assuming equal requester/target permissions; (3) identify the actual copy trigger, source, and destination address domains; and (4) independently read back a benign target and exactly restore every touched slot. No such evidence exists. This is **not** an arbitrary PSP RAM write, a post-boot TMR bypass, or authorization for a card write.