native_rpi5_entry.S: Pi 5 native (non-UEFI) boot entry stub (FABRIC-3.md §IV.3 item 1)

rpi5_native_start masks x0 down to the documented 32-bit DTB-pointer range
(the firmware's own entry protocol leaves the upper 32 bits unspecified),
stores it into g_rpi5_dtb_ptr for the still-open DTB->BootInfo constructor
(item 2) to read, then switches sp to a dedicated 2 MiB BSS stack -- this
path has no EDK2 boot stack to inherit, unlike every other entry path in
this codebase.

Intentionally halts (wfe/b loop) afterward rather than tail-calling into
item 2's constructor, which doesn't exist yet -- no stub function pretending
to be more than it is.

Not yet linked at the real 0x80000 load address; that needs its own linker
script/build target, not scoped into this item. Compiles and links into the
existing ARCH=aarch64 QEMU/UEFI acceptance build as dead code (ELF kernel
build's KERNEL_ASM wildcards every *.S in arch/aarch64/; nothing there
branches to it), same as rpi5_dtb.c/rpi5_mailbox.c before it.

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

@@ -305,10 +305,20 @@ hypervisor" when `acpi_table` is `NULL` — no fix needed there).
 until now because QEMU's own UEFI firmware never publishes one; Pi 5 native boot removes that
 blocker for free.
 
-1. **Entry stub**: new `boot/native_rpi5_entry.S` (or similar) — linked at `0x80000`, receives
-   `x0` = DTB pointer per the researched protocol (§IV.1), minimal early setup (stack — either
-   a small fixed BSS region, matching `BootInfo.kernel_stack_base`'s existing "zero = fall
-   back to 2 MiB BSS stack" convention, or something new if that's insufficient this early).
+1. **Entry stub — DONE 2026-09-04.** New
+   `src/starkernel/arch/aarch64/native_rpi5_entry.S` / `include/starkernel/rpi5_native_entry.h`:
+   `rpi5_native_start` masks `x0` down to the documented 32-bit DTB-pointer range (§IV.1: the
+   firmware leaves the upper 32 bits of the register unspecified), stores it into
+   `g_rpi5_dtb_ptr` for item 2's still-open constructor to read, then switches `sp` to a
+   dedicated 2 MiB BSS stack (this path has no EDK2 boot stack to inherit — there is no EDK2 at
+   all here, unlike every other entry path this codebase has). Intentionally halts (`wfe`/`b`
+   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