research: NextBSD on the Raspberry Pi 500+ — native boot options + driver map

A survey of every route to booting NextBSD natively on a Pi 500+ (BCM2712 D0,
16 GB, onboard NVMe), and a per-device map of what can be ported today vs
written new. Decisions deliberately deferred — nine open calls are gathered
in §9 with what would settle each.

Two findings drive it:

- FreeBSD can already be booted directly by the Pi firmware with zero new boot
  code. std.arm64:70 sets LINUX_BOOT_ABI, Makefile.arm64:87 has a kernel.bin
  target, arm_kernel_boothdr.awk emits a real arm64 Image_header, and the Pi 5
  firmware parses exactly that.

- OpenBSD 7.8 already ships the whole BCM2712+RP1 stack in 4,113 LOC of ISC
  (rpone, bcmmip, bcmpcie, bcmstbpinctrl, ...) — ~4x smaller than Linux's
  equivalent and licence-clean. LinuxKPI cannot host a devicetree driver at
  all: platform_driver_register() returns -ENXIO and there is no clk/OF/
  pinctrl/regulator shim.

Also documents why worproject/rpi5-uefi cannot boot this board (D0 silicon,
board type 0x19 absent, archived Feb 2025 — 16 GB is not the cause), the
hardware inventory measured over ssh, and the graphics analysis building on
nextbsd-kernel-modules#33.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: pkgdemon

nextbsd-research.html

@@ -54,6 +54,10 @@ <h1>NextBSD Research</h1>
 <h2>NextBSD</h2>
 <ul class="guides">
 <li>
+    <a href="nextbsd-rpi500-native-boot-plan.html?v=20260817">NextBSD on the Raspberry&nbsp;Pi&nbsp;500+ &mdash; native boot, and the driver map <span class="pill info">Survey / options &middot; new sub-project</span></a>
+    <span class="desc"><strong>Booting NextBSD on real arm64 hardware, without UEFI.</strong> The target is a <strong>Pi&nbsp;500+</strong>: BCM2712 <strong>D0</strong> silicon, 16&nbsp;GB, built-in NVMe, and a keyboard five layers deep behind PCIe&rarr;RP1&rarr;dwc3&rarr;xHCI&rarr;HID. <a href="https://github.com/worproject/rpi5-uefi">worproject/rpi5-uefi</a> cannot boot it for three verified reasons &mdash; archived since Feb&nbsp;2025, releases target pre-D0 <code>BCM2712C1</code> only, and board type <code>0x19</code> was never added (16&nbsp;GB is <em>not</em> the cause). <strong>The headline: FreeBSD can already be booted directly by the Pi firmware with zero new boot code</strong> &mdash; <code>std.arm64:70</code> sets <code>LINUX_BOOT_ABI</code>, <code>Makefile.arm64:87</code> has a <code>kernel.bin</code> target, <code>arm_kernel_boothdr.awk</code> emits a real arm64 <code>Image_header</code>, and the firmware parses exactly that. Second headline: <strong>OpenBSD&nbsp;7.8 already ships the whole BCM2712+RP1 stack in 4,113&nbsp;LOC of ISC</strong> (<code>rpone</code>, <code>bcmmip</code>, <code>bcmpcie</code>, <code>bcmstbpinctrl</code>&hellip;) &mdash; ~4&times; smaller than Linux's equivalent and licence-clean, so <strong>Tier&nbsp;A ports from OpenBSD, not Linux</strong>. Settles the LinuxKPI question too: <code>platform_driver_register()</code> literally returns <code>-ENXIO</code> and there is no clk/OF/pinctrl/regulator shim, so devicetree drivers must be native newbus/FDT. Includes the full hardware inventory measured over ssh, four boot routes costed, a per-device port/graft/net-new map, the kext three-tier split, the vc4-vs-v3d graphics analysis (building on <a href="https://github.com/nextbsd-redux/nextbsd-kernel-modules/pull/33">#33</a>'s arm64 drm-kmod result), an 8-phase sequence, and the upstream dependency on <a href="https://reviews.freebsd.org/D58105">D58105</a> (<code>dma-ranges</code>). <strong>A survey, not a decision</strong> &mdash; nine open calls are gathered at the end (which boot route ships, whether the image can be loader-less, kext granularity on arm64, vc4 baseline, EEPROM update first) with what would settle each. Planning only.</span>
+  </li>
+  <li>
     <a href="nextbsd-directoryservices-plan.html?v=20260716">NextBSD DirectoryServices &mdash; the file-level porting plan (<code>directoryservicesd</code>) <span class="pill pill-warn">Plan &middot; top-level goal</span></a>
     <span class="desc"><strong>The top-level goal.</strong> Give NextBSD <strong>network users spanning Mac OS X 10.3 &rarr; macOS 26</strong>, via a net-new <code>directoryservicesd</code> &mdash; a Path-B C daemon wrapping DirectoryService-621.12's in-process plugins behind the C API, with <code>pam_directoryservices</code> + an <code>nss_directoryservices</code> nsswitch module and <code>org.nextbsd.*</code> Mach names (from a 4-agent source-grounded scope). Home directories for those users are served by <strong>NFS</strong> (preferred, NextBSD&harr;NextBSD) and <strong>AFP</strong> (optional, legacy Macs to macOS 26) &mdash; the sequence nested below. Filesystem decisions: <strong>UFS is the live-ISO filesystem</strong> (plus the case-insensitivity patch for Mac shares); <strong>ZFS</strong> stays a supported <em>installed-system</em> option delivered via a future separate <code>zfs-img</code> (never the live ISO &mdash; NextBSD may eventually ship <code>iso</code> / <code>ufs-img</code> / <code>zfs-img</code> variants); <strong>HFS+</strong> is a footnote (read-only Mac-disk migration). <em>Next piece to wire: NFS as launchd daemons.</em> Planning only.</span>
     <ul>