FABRIC-3.md: riscv64 boot chain resolved, BeagleBone Black noted, header bug fixed

Milk-V Mars boot chain resolved via VisionFive 2 research: the Mars is
a documented mainline U-Boot target using the exact same binaries as
the VisionFive 2 (same StarFive JH7110 SoC) -- U-Boot + OpenSBI +
devicetree, not UEFI, same fork already decided for aarch64. Entry
point 0x40000000, mhartid CSR for core ID, UART at 0x10000000/115200 --
DTB pointer/hart-ID register convention at actual kernel entry not yet
confirmed for this specific chain.

Fixes a real bug from the earlier aarch64 edit: the "## V. riscv64 --
Milk-V Mars" section header had been accidentally dropped, leaving a
stale duplicate "Already true"/"Genuinely open" block sitting where
the real section should have started. Removed the duplicate, restored
the header, folded today's research into the section properly.

BeagleBone Black added to SS VI's hardware-identification reference per
direct instruction -- recorded only, no work scoped around it: it's a
32-bit ARM (TI AM335x, Cortex-A8) SoC, a genuinely different, fourth
architecture this kernel has no support for, not another board under
an existing one.

FABRIC-4.md SS2: captured the pinned-GPIO-VM idea raised in conversation
(Pi 5 needs one, Milk-V Mars explicitly undecided) as a theory-stage
note, cross-referenced from SSIV/SSV's own open-questions lists.

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

FABRIC-4.md

@@ -73,3 +73,34 @@ level up the stack.
   build the one wheel concretely first, generalize only if/when a second one is actually
   needed (this project's own standing convention — three similar lines beat a premature
   abstraction).
+
+## 2. A pinned GPIO VM per real-hardware board (2026-09-04)
+
+Raised in conversation with Captain Bob during `FABRIC-3.md` §IV/§V's bare-metal-boot
+planning — theory stage, no code, no scope, deliberately not punch-listed yet.
+
+**The idea, as stated:** the Raspberry Pi 5 will need a special pinned VM dedicated to GPIO —
+presumably following the same Tripod precedent Hermes/Artemis already established (a
+permanently-pinned, born-at-boot VM with a fixed role, per `FABRIC-2.md` §H.1's "pinned
+sessions never leave" model). Whether the Milk-V Mars needs the same treatment is explicitly
+**not yet decided** — Captain Bob's own framing: "same for Milk-V (? not sure here)." Worth
+noting the Mars does have its own 40-pin GPIO header (§VI), so the question isn't "does it
+have GPIO" but whether it needs its own *dedicated pinned VM* for it the same way the Pi 5
+does, or whether GPIO access there fits some other shape.
+
+**Why a dedicated VM, not just a C driver, presumably (not yet confirmed as the actual
+reasoning — inferred from the Tripod precedent, not stated outright):** GPIO is shared,
+stateful hardware that multiple capsules/patrons might want to touch — the same category of
+problem Hermes (messaging) and Artemis (block storage) already solve by being a dedicated,
+addressable VM other patrons talk to, rather than a bare C primitive anyone can call directly.
+
+**Explicitly not decided yet:**
+- Whether Milk-V Mars needs the same pinned-VM treatment, or something else.
+- What this VM's own vocabulary/interface would look like (a `GPIO-READ`/`GPIO-WRITE`-shaped
+  word set? something richer, given the Pi 5's GPIO header also muxes UART/SPI per §IV.1?).
+- Whether this is one pinned VM per board doing double duty (GPIO + whatever else that board's
+  bring-up needs) or GPIO specifically warrants its own separate VM distinct from, say, a
+  future UART-handling VM.
+- How this interacts with §IV.1's own still-open native-boot-flow work — a GPIO VM needs GPIO
+  register addresses from the DTB the same way the rest of that bring-up does, so this idea
+  isn't independent of that work, just downstream of it.