FABRIC-3.md §IV.3 item 5: pci_init() DTB path re-scoped, doc-only, nothing implementable this pass

Re-examined the Pi 5 RP1 PCIe access re-scoping (§IV.3 item 5) to see what
was actually buildable before real hardware arrives (2026-09-17), and
found nothing safely implementable this pass -- recorded three corrections:

1. The "vmm_map_range() needed for native boot" secondary finding is
   wrong as stated: arch_mmu_init() is a stub on both non-amd64 ISAs,
   vmm.c's load_cr3() is a no-op outside __x86_64__, and riscv64's satp
   is explicitly left at Bare (this session's own §V.3 item 7 fix). No
   non-amd64 ISA ever turns its own MMU on today, so VA==PA and there is
   nothing to map. Reframed as a future concern conditional on MMU
   bring-up, not a current prerequisite.

2. No silent-wrong-answer risk exists today: with no ACPI on native Pi 5
   boot, pci_init()'s MCFG parse already fails cleanly and aarch64 takes
   no ECAM fallback, rather than misreading RP1's 37 KB indirect window
   as flat ECAM.

3. The "make config-space dispatch runtime instead of compile-time" half
   of the re-scoped fix, considered on its own, isn't separable:
   portio_read32() and siblings use outl/inl inline asm that cannot exist
   in an aarch64/riscv64 translation unit, so any case referencing them
   stays #ifdef-gated regardless -- an enum wearing the same compile-time
   selection. It only becomes real dispatch once a second non-amd64
   mechanism is actually compiled in.

Broadcom indirect access itself remains unimplemented: no QEMU model
exists for "brcm,bcm2712-pcie" (zero branches would ever execute before
real hardware, unlike the guard-exercised GIC/PLIC DTB fixes), and
config-space access alone is insufficient for RP1 to enumerate without
the real driver's controller bring-up (link training, PERST, window
setup) -- building only the index/data window would compile and boot
while silently never working.

No code changed. 3-arch acceptance run anyway per convention: all three
reach zuse)ok> with identical virtio-blk/xHCI PCI device discovery to
the pre-change baseline (commit 9b6de5d), confirming no regression from
a change that touched no source.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var

FABRIC-3.md

@@ -491,17 +491,48 @@ blocker for free.
      (Broadcom indirect windowing) are the **same build** (`ARCH=aarch64`), so the dispatch
      must become a runtime choice, not a compile-time one — a real change to a shared file all
      three architectures currently boot clean through, not a small addition.
-   - Secondary finding, not yet acted on: `pci_init()`'s `vmm_map_range()` call for the ECAM
-     window is inside `#ifdef ARCH_AMD64` only (`pci.c:306–318`) — aarch64/riscv64 rely on
-     UEFI's own identity map instead (per this file's own header comment). Native boot has no
-     UEFI identity map at all, so **any** PCIe work on this path — regardless of access
-     mechanism — needs its own explicit `vmm_map_range()` call, not just a new config-access
-     branch.
-   - **Not implemented this pass.** The re-scoped shape (add a third, runtime-selected
-     Broadcom-indirect access mode to `pci.c`, plus explicit VMM mapping for the native path)
-     is a materially larger, higher-blast-radius change than items 1–4 — it touches a file all
-     three architectures share and boot through today. Recording the real shape here is this
-     pass's own deliverable; building it is future work.
+   - **Secondary finding, corrected 2026-09-05 — not a current blocker.** This item originally
+     claimed native boot's lack of a UEFI identity map means "**any** PCIe work on this path...
+     needs its own explicit `vmm_map_range()` call." Traced against actual source rather than
+     assumed: `arch_mmu_init()` is a stub on both non-amd64 ISAs (aarch64 and riscv64 alike,
+     `arch/{aarch64,riscv64}/arch.c`), `vmm.c`'s own `load_cr3()` is a no-op outside
+     `__x86_64__`, and — confirmed directly by this session's own riscv64 satp fix (§V.3
+     item 7) — `satp` is explicitly left at Bare mode on that ISA. **No non-amd64 ISA ever
+     turns its own MMU on today**, native or QEMU/UEFI boot alike; with translation off,
+     VA==PA everywhere and there is nothing for a mapping call to do. The concern is real but
+     conditional — it becomes a genuine prerequisite only once a future milestone actually
+     brings up aarch64/riscv64 paging (`arch_mmu_init()`'s own stub comment: "deferred to a
+     later milestone"), not before.
+   - **Also checked while re-scoping, not previously stated: no silent-wrong-answer risk
+     today.** With no ACPI table on the native Pi 5 boot path, `pci_init()`'s existing MCFG
+     parse fails cleanly (`rc != 0`) and aarch64 takes no ECAM fallback (unlike riscv64's own
+     QEMU-constant fallback) — it already prints `"PCI: MCFG parse failed on aarch64 — no
+     ECAM"` and stops, rather than misreading RP1's 37 KB indirect-window `reg` as if it were
+     flat 256 MB ECAM. No diagnostic gap to close here.
+   - **Still not implemented, and the runtime-dispatch prerequisite re-examined 2026-09-05 —
+     not separable from the Broadcom mode itself.** Considered building the "make dispatch
+     runtime, not compile-time" half alone (reusing the DTB node-scoped lookup primitive that
+     closed the aarch64 GIC base and riscv64 PLIC base findings, §IV.3/§V.3 item 7 and item 3)
+     — rejected on inspection, not scope: `portio_read32()` and its siblings use `outl`/`inl`
+     inline asm that cannot exist in an aarch64 or riscv64 translation unit at all, so any
+     `case PCI_CFG_MODE_PORTIO:` referencing them must itself stay `#ifdef ARCH_AMD64`-gated.
+     That leaves exactly one reachable case per architecture's build either way — an enum
+     wearing the same compile-time selection, fixing nothing. The dispatch can only become
+     genuinely runtime once a second real non-amd64 mechanism is actually compiled in, which
+     means this "prerequisite" and the Broadcom mode below are one change, not two sequenceable
+     ones.
+   - **Broadcom indirect access: not implemented, reason is unverifiability and incompleteness,
+     not size.** No QEMU model exists for `"brcm,bcm2712-pcie"` — no boot on this system can
+     execute a new branch built for it, so unlike the GIC/PLIC DTB-discovery fixes (guard
+     exercised, success branch pending hardware) this would be *zero* branches ever exercised
+     before 2026-09-17. Separately, config-space access alone is not sufficient for RP1 to
+     enumerate: `pcie-brcmstb.c`'s real driver does controller bring-up (link training, PERST,
+     inbound/outbound window setup) before `brcm_pcie_map_bus()` returns anything but
+     `0xFFFFFFFF` — implementing only the `IDX_ADDR`/`DATA_ADDR` index-window mechanism would
+     compile and boot cleanly while silently never working, exactly the half-finished
+     implementation this project's own conventions rule out. Recording the real shape remains
+     this pass's deliverable; building it needs real Pi 5 + RP1 hardware to verify against, not
+     available until 2026-09-17.
 6. **`config.txt` contents — DONE, 2026-09-04.** Written to `boot_media/rpi5/config.txt`
    (new directory — `configs/` is Kconfig defconfigs, `img/` is banners/docs, neither fits).
    Researched against the official current `config.txt` reference