diff --git a/FABRIC-3.md b/FABRIC-3.md
index acd7a59..9df7c83 100644
--- a/FABRIC-3.md
+++ b/FABRIC-3.md
@@ -210,15 +210,72 @@ is **not yet built** — today's `rng_get_bytes()` (`src/starkernel/rng/rng.c`)
 `virtio-rng` path, real on QEMU, meaningless on real Pi 5 hardware (no virtio device there).
 
 **Genuinely open, not yet decided:**
-- Raspberry Pi 5's own boot chain — UEFI (e.g. via the community EDK2 port) or the Pi's native
-  boot flow? This determines whether the existing UEFI-targeted boot code needs a different
-  entry path for this board at all, or just different ACPI/DTB-provided data.
-- Which peripheral RNG the Pi 5 actually exposes, and how to read it (memory-mapped peripheral
-  vs. a firmware call) — not yet researched.
 - Same observation-method question as amd64 (no QEMU serial socket on real hardware) —
   possibly shared tooling/approach across both boards once decided once.
 
-## V. riscv64 — Milk-V Mars
+### IV.1 — Boot-chain decision: UEFI vs. native, researched 2026-09-04
+
+**Researched, not assumed** (web search, current as of this session):
+
+**UEFI option investigated and found weak.** A real UEFI+ACPI firmware for Pi 5 exists —
+[`rpi5-uefi`](https://github.com/worproject/rpi5-uefi) (TF-A + EDK2, SBBR-compliant). But:
+it's **archived as of 2025-02-04**, support ended because newer Pi EEPROM firmware broke
+compatibility with it; its own README says ACPI support is "under development and limited to
+a few devices"; RP1 Ethernet/GPIO/PWM/EEPROM don't work under it. This kernel's whole
+aarch64 boot path (`boot/uefi_loader.c`, `BootInfo->acpi_table`) assumes UEFI+ACPI the same
+way amd64 and the QEMU aarch64 target do — but that assumption may not hold on a real,
+current-firmware Pi 5 at all.
+
+**Native boot flow — the real alternative, researched concretely:**
+- Boot partition needs `bcm2712-rpi-5-b.dtb`, `config.txt`, and the kernel image itself —
+  Pi 5 firmware defaults to loading `kernel_2712.img`, falling back to `kernel8.img` if that's
+  absent.
+- `config.txt` needs `os_check=0` for a non-Linux image, or the firmware assumes Linux and
+  loads from `0x200000` instead of the classic Pi bare-metal load address `0x80000`.
+- Entry protocol: `x0` = 32-bit DTB pointer (upper 32 bits of the 64-bit register
+  unspecified — must mask before use), `x1`–`x3` reserved/zero. **No UEFI PE loader, no ACPI
+  at all** — a completely different entry shape from `boot/uefi_loader.c`.
+- Framebuffer: the VideoCore **mailbox property interface** (channel 8) — a real, different
+  mechanism from UEFI GOP, no precedent anywhere in this codebase today.
+
+**Decision, per direct instruction 2026-09-04: native boot flow.** Not UEFI. The archived,
+partially-working UEFI project is too fragile a foundation to build a real-hardware release
+on top of.
+
+**What this actually means for the codebase, named honestly rather than estimated small:**
+- A **new, non-UEFI entry path** for aarch64 real hardware — this kernel's boot sequence
+  currently assumes `uefi_loader.c`'s PE-loader shape unconditionally on aarch64; a Pi 5
+  native boot needs its own entry point (linked at `0x80000`, receiving `x0` = DTB pointer
+  directly, no `BootInfo` from UEFI at all).
+- A **DTB-driven `BootInfo` equivalent** replacing ACPI-sourced data for this path — memory
+  map, peripheral addresses (UART, etc.) all come from the devicetree instead.
+- **One real, genuine piece of reusable groundwork**: `starkernel/hal/fdt.c`/`fdt.h`, the
+  minimal FDT reader already built for riscv64's `timebase-frequency` lookup
+  (`arch/riscv64/timer.c`), is directly extensible for this — parsing `bcm2712-rpi-5-b.dtb`
+  for peripheral addresses is the same kind of lookup, not a new mechanism.
+- A **new mailbox-property-interface framebuffer driver** — genuinely new code, no existing
+  precedent in this codebase, needed before the VT100 console framework
+  (`console.c`/`vt100.c`/`framebuffer.c`) has anything to draw onto for this board.
+- This is a real architectural fork for aarch64, not a small per-board addition — QEMU
+  aarch64 keeps its existing UEFI+ACPI path unchanged; Pi 5 real hardware gets a second,
+  parallel entry path. **Not yet scoped into a punch list** — that's the next step, once this
+  fork's own shape (how much of `kernel_main.c`'s post-entry sequence can stay shared between
+  the two paths vs. needs its own branch) is thought through.
+
+### IV.2 — Peripheral RNG: unresolved, not just under-researched
+
+`ROADMAP.md` names an "aarch64 peripheral-RNG backend" as part of `v2.4.0`'s gate. Researched
+directly rather than assumed still-TODO: Broadcom's `iproc-rng200` block (real, on Pi 4/BCM2711
+as `brcm,bcm2711-rng200`) has **no `bcm2712` compatible-string entry anywhere in current
+mainline Linux** (checked the actual driver's `of_device_id` table directly). The RP1
+companion chip's own published peripheral list (GPIO/USB/Ethernet/DMA/ADC/PLLs/SRAM/
+UARTs/SPIs) doesn't mention an RNG either. Two real possibilities, not yet distinguished:
+BCM2712 still has the RNG200 block but Linux hasn't wired it into a devicetree binding yet, or
+it genuinely isn't exposed to the ARM cores this generation. No public register address exists
+to target right now — this needs either a Broadcom datasheet (if one becomes available) or
+direct hardware probing once the board is in hand (scan the known BCM2711 RNG200 offset region
+on the BCM2712 memory map and see if anything responds — risky without a datasheet confirming
+it's safe to touch, so likely a "board in hand, careful probe" task, not a today task).
 
 **Already true:** `ROADMAP.md` names this (generically, "Milk-V") as part of `v2.5.0`'s gate:
 boots on the real board, the Zkr (RNDR) entropy backend live. Same gap as aarch64: