rpi5_native_boot.c: Pi 5 DTB->BootInfo constructor (FABRIC-3.md §IV.3 item 2)

rpi5_native_boot() populates the existing BootInfo struct from the
devicetree instead of UEFI protocols, then calls the existing, unmodified
kernel_main() -- the crux of why most of M1-M9 stays shared between the
UEFI and native boot paths. native_rpi5_entry.S now tail-calls into it
instead of halting.

memory_map is built from /memory's own reg, honoring the *root* node's
#address-cells/#size-cells (confirmed against bcm2712.dtsi's actual root
node -- <2>/<2> -- not assumed; a wrong cell width here would compile and
boot clean in QEMU while silently corrupting the real memory map on real
silicon). Required a new fdt_find_node_by_device_type() since /memory is
identified by device_type = "memory" per DT spec, not compatible.

args comes from /chosen's bootargs fed into the existing
cmdline_parse_ascii() (confirmed pure C99 with no UEFI coupling before
reusing it). framebuffer comes from the already-built
rpi5_mailbox_get_framebuffer() at a fixed 1920x1080x32 default -- no EDID
query exists in this codebase, flagged rather than guessed past.

Deliberately scoped out, not silently skipped: /reserved-memory is not
parsed. Carving reserved sub-ranges out of /memory's span needs
interval-splitting logic that would be written blind against hardware not
yet in hand -- exactly the kind of code that hides a bug until real
silicon. pmm.c's Pass 3 only ever clears pages this file lists as
EfiConventionalMemory, so the gap is "less usable RAM than optimal," never
"reserved RAM wrongly marked free." Left as its own future item.

Also fixes a real link failure this work surfaced: boot/cmdline.c was only
in LOADER_SRCS_BASE (the .efi target), not KERNEL_SRCS_BASE (the separate
.elf target arch/aarch64/*.c also wildcards into) -- added it there too.

Compile-only-verified; nothing in the existing UEFI/QEMU path calls
rpi5_native_boot(), so this cannot be exercised until real hardware.
Verified 3-arch boot to ok>/zuse)ok>.

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

FABRIC-3.md

@@ -315,17 +315,41 @@ blocker for free.
    loop) afterward rather than tail-calling into item 2's constructor, which doesn't exist yet.
    **Not yet linked at `0x80000`** — that needs its own linker script/build target (item 6's own
    `config.txt` work is the sibling piece; the separate-image build itself is not scoped into
-   this item). Verified 3-arch boot to `ok>`/`zuse)ok>` — `Makefile.starkernel`'s `KERNEL_ASM`
-   wildcards every `*.S` in `arch/aarch64/`, so this file compiles and links into the existing
-   QEMU/UEFI acceptance build as dead code (unreferenced symbol, nothing there ever branches to
-   it), same as `rpi5_dtb.c`/`rpi5_mailbox.c` before it.
-2. **DTB → `BootInfo` constructor**: new C function populating the *existing* `BootInfo`
-   struct (`include/starkernel/uefi.h`) from the DTB instead of UEFI protocols — `dtb` = the
-   real pointer, `acpi_table` = `NULL` (already the correct value for "no ACPI," per IV's own
-   research above), `runtime_services` = `NULL`, `memory_map`/`framebuffer`/`args` populated
-   from DTB `/memory`+`/reserved-memory`, the mailbox interface (next item), and DTB `/chosen`
-   `bootargs` respectively. Then calls the **existing, unmodified** `kernel_main()` — this is
-   the crux of why most of M1–M9 stays shared.
+   this item). Now tail-calls item 2's constructor (below) instead of halting — updated
+   2026-09-04 when that item landed. Verified 3-arch boot to `ok>`/`zuse)ok>` —
+   `Makefile.starkernel`'s `KERNEL_ASM` wildcards every `*.S` in `arch/aarch64/`, so this file
+   compiles and links into the existing QEMU/UEFI acceptance build as dead code (unreferenced
+   symbol, nothing there ever branches to it), same as `rpi5_dtb.c`/`rpi5_mailbox.c` before it.
+2. **DTB → `BootInfo` constructor — DONE 2026-09-04.** New
+   `include/starkernel/rpi5_native_boot.h` / `src/starkernel/arch/aarch64/rpi5_native_boot.c`:
+   `rpi5_native_boot()` populates the *existing* `BootInfo` struct from the devicetree instead
+   of UEFI protocols (`dtb` = the real pointer, `acpi_table`/`runtime_services` = `NULL`,
+   `kernel_stack_base` = `NULL`/BSS-fallback — aarch64 has no `kernel_entry.S` trampoline at
+   all, so item 1's own BSS stack already *is* the stack `kernel_main_impl` runs on),
+   `args` via `/chosen`'s `bootargs` fed straight into the *existing*
+   `cmdline_parse_ascii()` (pure C99, no UEFI coupling — confirmed before reusing it, not
+   assumed), `framebuffer` via item 3's `rpi5_mailbox_get_framebuffer()` at a fixed
+   1920x1080x32 default (no EDID query exists in this codebase — flagged, not guessed past
+   this comment, revisit once real hardware and a real attached display are in hand), then
+   calls the **existing, unmodified** `kernel_main()` — this is the crux of why most of M1–M9
+   stays shared. `memory_map` comes from `/memory`'s own `reg`, honoring the *root* node's
+   `#address-cells`/`#size-cells` (confirmed against `bcm2712.dtsi`'s actual root node — `<2>`/
+   `<2>` — not assumed; a hardcoded-wrong cell width here would compile clean and boot clean in
+   QEMU while silently corrupting the real memory map on real silicon, so this was verified
+   from the source rather than recalled). Required a new `fdt_find_node_by_device_type()`
+   (`fdt.c`/`fdt.h`) since `/memory` is identified by `device_type = "memory"` per DT spec
+   §3.4, not `compatible`. Required a Makefile fix: `boot/cmdline.c` was only in `LOADER_SRCS_BASE`
+   (the `.efi` target), not `KERNEL_SRCS_BASE` (the separate `.elf` target `arch/aarch64/*.c`
+   also wildcards into) — added it there too, a real link failure caught before it could ship.
+   **Deliberately scoped out, not silently skipped:** `/reserved-memory` is not parsed —
+   carving reserved sub-ranges out of `/memory`'s span needs interval-splitting logic that
+   would be written blind against hardware not yet in hand, exactly the kind of code that
+   hides a bug until real silicon; left as its own future item. `memory/pmm.c`'s Pass 3 only
+   ever clears pages this file explicitly lists as `EfiConventionalMemory`, so the gap is
+   "less usable RAM than optimal," never "reserved RAM wrongly marked free." Verified 3-arch
+   boot to `ok>`/`zuse)ok>` — compile-only, same caveat as every item in this list: nothing in
+   the existing UEFI/QEMU path calls `rpi5_native_boot()`, so this cannot be exercised until
+   real hardware.
 3. **Mailbox-property-interface framebuffer driver — DONE 2026-09-04.** New
    `include/starkernel/rpi5_mailbox.h` / `src/starkernel/arch/aarch64/rpi5_mailbox.c`:
    `rpi5_mailbox_get_framebuffer()` builds and sends one property-tag buffer (phys size, virt