riscv64: PLIC base address DTB-discovered, QEMU-virt constant as fallback (§V.3 item 3)

plic_init() now takes boot_info->dtb (threaded through apic_init()) and
tries fdt_find_node_by_compatible(dtb, "sifive,plic-1.0.0") ->
fdt_find_prop_in_node(..., "reg", ...) before falling back to the
QEMU-virt-specific constant it previously hardcoded unconditionally.
Reuses the node-scoped DTB lookup primitive built for the aarch64 GIC
base fix unchanged. s_plic_base is now a runtime uintptr_t, same shape
as apic.c's s_gicd_base/s_gicc_base.

This system's QEMU/UEFI riscv64 firmware does not forward a DTB to the
guest (timer.c's own timebase-frequency read falls back too, confirmed
in this boot's own log), so only the no-DTB fallback branch is exercised
here -- the success branch (a real DTB with a matching PLIC node) stays
unverified until real Milk-V Mars hardware. FABRIC-3.md's first-drafted
claim that the success branch would run (based on a stale comment in
plic.c's own pre-fix header) was checked against the actual log and
corrected before this commit.

3-arch acceptance: amd64/aarch64 don't compile these files, so their
runs are non-regression on untouched files only. riscv64's own boot log
confirms the fallback path prints exactly as designed and boot reaches
zuse)ok> unchanged.

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

FABRIC-3.md

@@ -708,26 +708,41 @@ Traced against real code before writing this, same discipline as §IV.3: `pci_in
 session's own hypervisor-detection check) — no further work needed there; it was built DTB-
 first from the start, unlike aarch64's timer which needed a new ACPI-based check today.
 
-**One real, already-flagged risk found while tracing this**: `arch/riscv64/apic.c`'s own doc
-comment says the PLIC base address is "a constant, not discovered from `boot_info->dtb`" —
-and `arch/riscv64/plic.c`'s own doc comment (predating this document) already warned
-`PLIC_BASE`/`PLIC_CONTEXT_S` are "QEMU-virt-specific... not assumed stable across" other
-configurations. That warning becomes concrete now: the JH7110's real PLIC address on the Mars
-is not confirmed to match QEMU-virt's, and the interrupt controller will not work correctly if
-it doesn't. This is a real punch-list item, not a hypothetical.
+**One real, already-flagged risk found while tracing this — FIXED 2026-09-05, see item 3
+below.** `arch/riscv64/apic.c`'s own doc comment said the PLIC base address was "a constant,
+not discovered from `boot_info->dtb`" — and `arch/riscv64/plic.c`'s own doc comment
+(predating this document) already warned `PLIC_BASE`/`PLIC_CONTEXT_S` are "QEMU-virt-
+specific... not assumed stable across" other configurations. That warning was concrete: the
+JH7110's real PLIC address on the Mars was not confirmed to match QEMU-virt's, and the
+interrupt controller would not have worked correctly if it didn't.
 
 1. **Entry stub**: new native riscv64 entry point at `0x40000000` (§V.1), receiving `a0`=hart
    ID, `a1`=DTB pointer directly (now-confirmed SBI convention) — no UEFI, no PE loader.
 2. **DTB → `BootInfo` constructor**: same shape as aarch64's (§IV.3 item 2) — `dtb`=real
    pointer, `acpi_table`=`NULL`, memory map from DTB `/memory`+`/reserved-memory`, `args` from
    `/chosen`/`bootargs`.
-3. **PLIC base address: make it DTB-discovered**, not the current QEMU-virt-specific
-   constant — the one concrete, already-flagged risk above. `fdt.c`'s node-scoped lookup
-   extension (§IV.3 item 4, **DONE 2026-09-04**, shared with the Pi 5's UART/mailbox
-   addresses) is the primitive this calls
-   (`fdt_find_node_by_compatible(fdt, "sifive,plic-1.0.0")` → `fdt_find_prop_in_node(..., "reg", ...)`,
-   plausible compatible string, not yet confirmed against the Mars's real DTB) — the actual
-   PLIC-init call site update is still open, only the primitive it needs now exists.
+3. **PLIC base address: make it DTB-discovered — DONE 2026-09-05.** `plic_init()`
+   (`arch/riscv64/plic.c`) now takes `boot_info->dtb`, passed through from `apic_init()`
+   (`arch/riscv64/apic.c`), and tries `fdt_find_node_by_compatible(dtb, "sifive,plic-1.0.0")`
+   → `fdt_find_prop_in_node(..., "reg", ...)` before falling back to the QEMU-virt constant —
+   exactly the primitive built for the aarch64 GIC base fix (§IV.3 item 7), reused unchanged.
+   `s_plic_base` is now a runtime `uintptr_t`, not a `#define`, same shape as apic.c's
+   `s_gicd_base`/`s_gicc_base`. **Correction, same day**: this document's own text at this
+   point originally predicted the success branch would run under QEMU, on the strength of a
+   stale claim in `plic.c`'s own pre-fix header ("riscv64 DTB access does work, unlike
+   aarch64") — checked against the actual boot log rather than trusted, and it doesn't hold
+   for this system's QEMU/UEFI riscv64 firmware specifically: `timer.c`'s own
+   `timebase-frequency` read falls back too (`"Timer: RISC-V time CSR @ 10000000 Hz
+   (FALLBACK, no devicetree)"`), and the new PLIC line confirms the same thing —
+   `"PLIC: no DTB PLIC node -- using QEMU virt-machine default (base=0x0c000000)"`. So this
+   fix is evidentially in the same position as the GIC fix: the guard (no-DTB fallback) is
+   exercised and correct, the success branch (a real DTB with a matching PLIC node) remains
+   unverified until real hardware. The stale claim that misled this paragraph's first draft
+   lived only in `plic.c`'s old header and was already replaced by this fix's own comment —
+   not re-introduced. The Mars's real JH7110 `reg` value stays unconfirmed either way — the
+   compatible string is architectural (SiFive PLIC-1.0.0 is a standard binding), not
+   board-specific, but no
+   hardware exists yet to check the Mars's own DTB against it.
 4. **Framebuffer for HDMI output**: JH7110's display path is genuinely unresearched this
    pass — unlike the Pi 5's mailbox interface (well-documented, reused across many Pi bare-
    metal projects), no equivalent research done yet for JH7110's own display controller.