sbwml/builder ships a prebuilt OpenWrt with plugins for NanoPi routers

The repository is a distribution point, not a build tree

The first thing to understand is where the work actually lives. The top level of this repository contains a .github directory and a README, and nothing else, while the homepage field points at a different repository, the r4s_build_script project. So the naming is misleading if you read builder as the build system. What this repository is, in practice, is the published front door: the place where the project explains what the images are, where to download them for each board, and how to flash them. The build scripts that produce the images are a separate repository, which is a reasonable split, since the scripts change on a different cadence from the documentation, but it means anyone who wants to change the firmware has to go and find a second repository. The topics attached to it, nanopi-r4s, nanopi-r5s, nanopi-r76s, openwrt and x86-64, describe the output rather than the mechanism.

Three release channels, and only one of them is recommended

The versioning section lays out three flavours and the recommendation is unambiguous. The Releases channel is described as the official version, built from the latest OpenWrt Releases source code and packages, and it is the one marked as recommended. The Snapshots channel is the development version, built from the latest openwrt-25.12 branch source and packages, and it is built every night. The Minimal channel is the lightweight version, built from the same Releases source but with no built-in plugins, and it carries a note that it is not recommended. Each of the three sits behind its own address, with the snapshots on a separate host, and the release tags in the repository match the pattern, with v25.12.5, v25.12.5-standard and v25.12.5-minimal all published on 2026-07-01. The three-way split is the design decision to understand, since a nightly snapshot is a reasonable thing to run on a spare router and a poor thing to run as your only router.

SquashFS or ext4, and why the read-only image is the safer default

The firmware comes in two filesystem flavours and the documentation explains the trade-off rather than leaving it implicit. The firmware is split into two file systems, SquashFS and Ext4. The SquashFS image, whose filename carries the word squashfs, is the recommended one: it is a read-only file system, it supports a system reset, it is less likely to trigger a write protection on the SD card file system, and it supports online OTA upgrades, which makes it the right choice for most users. The Ext4 image, whose filename carries ext4, gives a partition that is readable and writable throughout, which suits people who are comfortable with Linux systems, but an unexpected power cut can leave the partition write protected. That is a real failure mode rather than a theoretical one for a router that lives on a shared SD card, and it explains why the feature list below advertises firmware reset and online OTA upgrade as available on the squashfs builds.

The plugin set is the reason most people use these images

The built-in plugin table is the substance of the customisation, and it is long. It includes HomeProxy and Nikki for proxying, MosDNS for DNS, qBittorrent with the Quick file manager and DiskMan for storage, rtp2httpd, Watchcat for process supervision, a KMS server, Socat, dynamic DNS, WireGuard, L2TP, ZeroTier, WebDav, Alist, a TTY terminal, network wake on lan, access control, IP rate limiting, a Ruijie authentication client, FRP, UPnP, nlbw bandwidth monitoring, SQM queue management, speed testing, custom commands and OTA. The AirPlay 2 entry carries a specific caveat, since it is described as a simple, easy to use AirPlay audio player that needs an external USB sound card. A LuCI menu listing in the readme matches the plugin set, grouped under status, system, services, Docker and network, with the Docker section covering containers, images, networks, volumes and events.

Kernel and network tweaks, including the ones that are policy choices

Beyond plugins, the images carry a set of changes to the kernel and the network stack, and a few of them are opinionated. The list includes kmod kernel module installation, full cone NAT with both NFT and BCM schemes, build optimisation with O3 and LTO, AES hardware acceleration for SSL, GPU hardware acceleration, kernel and module optimisation using Clang and LLVM ThinLTO, HDMI terminal output, the HYM8563 real time clock, BBRv3 congestion control, TCP Brutal congestion control, LLVM-BPF support, Shortcut-FE with inbound UDP support, KVM virtualisation support, the v59 LRNG random number generator, HTTP3 and QUIC support through NGINX and CURL, and PWM fan control. TCP Brutal and BBRv3 together are a deliberate throughput oriented choice rather than a default, and Shortcut-FE with inbound UDP is a firewall behaviour change, so anyone who relies on shaped or inspected traffic should read that row before flashing. The NanoPi R76S has its own table, and it is the board with the most board-specific work in it. The R76S entries cover the Rocket NPU driver, booting from microSD, SDIO WiFi in both access point and client mode alongside Bluetooth, and PCI-MSI interrupt optimisation for the A72 cores. The R4S and R5S do not get a separate table, which means the general feature list is what applies to them. The R4S, R5S and R76S are FriendlyElec boards and each has its own download address, and there is a separate one for x86_64, so the project is not tied to a single board family even though the plugin set clearly started with the NanoPi line. The R5S also has the eMMC path described in the flashing section, which is the one part of the documentation that is board-specific enough to trip people up.

Flashing the R5S eMMC means a Windows PC and the Rockchip tool

The eMMC flashing procedure for the R5S is the longest section in the readme and it is the part with the most hard requirements. You need a computer running Windows, with other operating systems left to find their own tools, and a USB-A to USB-A or Type-C to USB-A cable. The project supplies the Rockchip development tool as a specific zip, RKDevTool_Release_v2.84.zip, and a Mask device driver as DriverAssitant_v5.1.1.zip. You download the firmware and extract the .img file, install the Mask driver, and then connect in Mask mode with the R5S powered off and the SD card removed, holding the Mask button while powering the R5S until the computer finds a new device and then releasing the button. The tool tells you which state you are in, a Maskrom device found means the driver is present and no device found means it is missing. You then pick the IMG through the system path selection button and press execute, and the board reboots into OpenWrt when the write finishes.

Copying the image to eMMC from a running system

There is a second route to eMMC that avoids Windows entirely, and it uses a built-in command on a running system. You download the latest Releases firmware and boot it from an SD card first, then upload a copy of the firmware to the /tmp directory, either with a file transfer tool such as Xftp or by downloading it in the terminal with wget, and then run the built-in command that writes the firmware to eMMC storage.

emmc-install /tmp/openwrt

The path in the command is the one the documentation uses as an example, and the text notes that you should adjust it to the actual file name and path you used. Running it from a live system on a read-only squashfs build is the reason the squashfs variant is the recommended one for SD boot, since the upload target is a tmpfs partition that does not need the whole root to be writable. The same section also notes that for the SD card route on the R4S, R5S and R76S the recommended tool is balena Etcher, the card needs to be 2GB or more, and the firmware file does not need to be unpacked before writing.

Where these images are the wrong choice

The first wrong case is a user who wants control over the package set, because the whole value proposition of a custom image is that the selection has already been made. The plugin list above, with Docker, WireGuard, ZeroTier, a torrent client, a KMS server and an AirPlay receiver all compiled in, is more than many routers need, and the Minimal flavour exists precisely because the full image is not for everyone even though the documentation advises against it. The second wrong case is a user who wants upstream support, since these are modified builds and the modifications listed above, from the congestion control algorithms to the Shortcut-FE inbound UDP behaviour, are not the behaviour upstream OpenWrt ships. The third is a user on a board that is not in the list, since the images are built for three FriendlyElec boards and x86_64, and the plugin set assumes that hardware. The fourth is anyone who treats the nightly snapshot channel as a release, since a snapshot is rebuilt every night and can change under you, which is fine for a test router and not fine for a gateway. The fifth is a user who expects a build system in this repository, and the readme structure tells you immediately that the build scripts live in r4s_build_script instead.

Editorial conclusion

Owners of a NanoPi R4S, R5S or R76S who want a router firmware with a working set of LuCI plugins, WireGuard, Docker and an SQM queue manager already compiled in are the people these images are for, and the three flavours let you choose between a stable release, a nightly snapshot and a plugin-free build. It is the wrong choice for someone who wants to build their own OpenWrt with their own package selection, since the point of these images is that the selection has been made for you, and it is the wrong choice if you need a supported upstream image, since these are custom builds with modifications layered on top. Check three things before you flash: that you pick the squashfs image rather than ext4 unless you specifically want a writable partition, since the documentation attributes the ext4 risk of a write-protected partition to unexpected power loss, that you understand the default credentials are the root user with no password at http://10.0.0.1 or http://openwrt.lan, and that you know where the build scripts actually live, because this repository contains only a .github directory and a README while the homepage points to a separate r4s_build_script repository. The last push was on 2026-09-11 and the newest tagged builds are the v25.12.5 series from 2026-07-01.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sbwml/builder on GitHub