// the find
buildwithparallel/openwrt-morse-rpi5
OpenWrt 23.05 backport for Raspberry Pi 5 with Morse Micro HaLow support, kernel 6.6, mesh networking, and prebuilt firmware images.
A backport that stitches the Morse Micro HaLow SDK (stuck on OpenWrt 23.05 / kernel 5.15, Pi 4 only) together with the Pi 5's bcm2712/RP1 hardware support pulled forward from OpenWrt 24.10. It's for people building off-grid/long-range Wi-Fi mesh rigs on a Pi 5 who want HaLow now rather than waiting for Morse Micro's official Pi 5 SDK.
The core engineering is real, not a thin wrapper: vendoring bcm2712/RP1 device definitions into an older SDK tree to get a kernel 5.15-era driver stack building against kernel 6.6 is nontrivial cross-version work. The build docs include actual hard-won fixes, like pinning an in-tree Rust recipe to dodge an expired upstream LLVM CI download, and explaining why `chown` matters before building, which signals someone who actually hit these failures. Prebuilt images plus a full build/flash video walkthrough lower the barrier for people who don't want to compile OpenWrt themselves. The add-on package set (batman-adv mesh, WireGuard/Tailscale, dump1090/ADS-B, LoRa/Reticulum serial drivers for half a dozen named boards) is specific to a real use case rather than generic kitchen-sink bloat.
The headline hardware path people will actually want, the Seeed Studio HaLow HAT over SPI on a Pi 5, is explicitly listed as 'does not bind yet'; the only confirmed-working radio is a USB-tethered Gateworks module, which undercuts the main pitch. The README itself says this repo is a temporary bridge that will 'likely be superseded' once Morse Micro ships real Pi 5 support, so you're adopting a backport with a built-in expiration date and no clear migration story. It's heavily tied to one vendor's commercial product (Build with Parallel / Haven) with cross-links to its storefront, YouTube, and X account, which makes this look more like marketing collateral for a kit than a community-maintained OpenWrt fork, raising bus-factor risk for anyone depending on it long-term. There's no CI or test coverage for the backport's own changes (the vendored bcm2712 patches, SPI/DMA overlay work); the workflows present are just inherited generic OpenWrt CI, so regressions in the actual fork-specific code wouldn't be caught automatically.