[WIP] Adding support for Netgear Orbi RBR50 V2 (IPQ4019, NAND)

sminkkinen · March 26, 2026, 7:56am

Hi everyone,

I've been working on an OpenWrt port for the Netgear Orbi RBR50 V2, the cost-reduced NAND variant of the RBR50. This is (to my knowledge) the first-ever OpenWrt installation on V2 hardware. Everything is fully working — persistent squashfs + UBI overlay, all three WiFi radios, Ethernet, LEDs, and sysupgrade.

The code and pre-built images are available on GitHub: https://github.com/minkkisa/openwrt-rbr50v2

Hardware

Feature	Specification
SoC	Qualcomm IPQ4019 (4× ARM Cortex-A7)
RAM	512 MB DDR3L
Flash	512 MB SPI NAND (Macronix MX30LF4G18AC)
WiFi 2.4 GHz	IPQ4019 integrated (2×2 MIMO, ath10k-ct)
WiFi 5 GHz (low)	IPQ4019 integrated (2×2 MIMO, ath10k-ct)
WiFi 5 GHz (high)	QCA9984 PCIe (4×4 MIMO, VHT80/160, backhaul)
Ethernet	QCA8075 5-port GbE switch (WAN + 3× LAN, DSA)
LEDs	GPIO 22–27 + TLC59208F I2C ring LED controller
USB / Bluetooth	None (removed in V2)

OpenWrt build info

Target: ipq40xx/generic
Version: SNAPSHOT r0-17784ad
Kernel: 6.12.77

Key differences from the officially supported RBR50 V1

512 MB SPI NAND instead of 4 GB eMMC
LED GPIOs relocated (22–27 vs. V1's 53/54/57/60/63/64)
I2C SDA/SCL on GPIO 20/21 (V1 uses 58/59, which are QPIC NAND bus on V2)
No USB, no Bluetooth
Different NETGEAR_HW_ID: 29765913 (V1: 29765352)

Critical discovery: `fdt_high=0x87000000`

This was the key to getting OpenWrt to boot on this device, and it took quite some debugging to find.

DNI's modified U-Boot (based on 2012.07) performs a 128 KB NAND read after bootm. If the device tree happens to be loaded above address 0x87000000, this read silently overwrites the FDT in memory. The result is a kernel crash with absolutely no output after Starting kernel... — making it very hard to diagnose.

The fix is a one-time U-Boot environment variable:

setenv fdt_high 0x87000000
saveenv

Without this, no modern kernel (including the official V1 OpenWrt image) will boot on V2 hardware.

What works

Persistent installation (squashfs root + UBIFS overlay, ~23 MB writable)
Ethernet: WAN + 3× LAN via QCA8075 DSA switch, 1 Gbps
WiFi: All 3 radios — AP mode and monitor mode tested
WiFi DFS: Radar detection working on QCA9984 (ETSI, country FI)
PCIe: QCA9984 detected and working (Gen.2 x1)
NAND: 24 partitions, MTD + UBI
sysupgrade: nand_do_upgrade, tested initramfs → squashfs
LEDs: GPIO direct + TLC59208F I2C ring LED (via kmod-leds-tlc591xx)
Board detection: LAN/WAN and LED auto-configuration
MAC addresses: Read from boarddata1 NAND partition
Tailscale VPN: tested with static ARM binary, userspace networking mode — works well for remote management

Tri-band simultaneous monitor mode

One notable capability of this device: all three radios can run in monitor mode simultaneously, covering the full 2.4 GHz + 5 GHz low + 5 GHz DFS spectrum. I've tested this for 10+ hours continuously with airodump-ng — completely stable, ~115 MB RAM used out of 506 MB, CPU load around 1.5 on 4 cores.

This kind of tri-band concurrent monitoring is uncommon in consumer hardware running OpenWrt.

WiFi radio details

Radio	Band	Channels	Capabilities
phy0 (QCA9984, PCIe)	5 GHz high	100–140 (DFS)	VHT80, VHT160, 80+80, 4×4 MIMO
phy1 (IPQ4019)	2.4 GHz	1–13	HT20/HT40, 2×2 MIMO
phy2 (IPQ4019)	5 GHz low	36–64	VHT80, 2×2 MIMO

Installation (requires UART — no alternative)

A USB-UART adapter (3.3V TTL) is mandatory for the first-time installation.

There is no way around this: the fdt_high U-Boot environment variable and a modified bootcmd must be set via the U-Boot console before any OpenWrt kernel will boot. The stock bootcmd uses DNI's load_chk_dniimg which rejects non-Netgear images, and fw_setenv is not available from stock Linux. NMRP recovery alone is not sufficient.

After the one-time U-Boot setup, subsequent upgrades work normally via sysupgrade (no UART needed).

Connect USB-UART adapter to J01 header (115200 8N1, 3.3V TTL)
Stop U-Boot autoboot, set fdt_high=0x87000000 and saveenv
TFTP boot the initramfs image
Run sysupgrade with the squashfs image for persistent installation

Full installation guide and pre-built images are in the GitHub repo.

Files for upstream

New: target/linux/ipq40xx/dts/qcom-ipq4019-rbr50v2.dts
Modified: target/linux/ipq40xx/image/generic.mk — Device/netgear_rbr50v2
Modified: target/linux/ipq40xx/base-files/lib/upgrade/platform.sh — nand_do_upgrade
Modified: target/linux/ipq40xx/base-files/etc/board.d/02_network — LAN/WAN config
Modified: target/linux/ipq40xx/base-files/etc/board.d/01_leds — power LED default

I'm planning to submit a PR to the openwrt/openwrt repository. Any feedback on the DTS, build definitions, or the approach in general would be very welcome before I do that.

Thanks!

LS3434 · March 26, 2026, 8:21am

There is a PR on github about this device already.

sminkkinen · March 26, 2026, 8:23am

Thank you for that information. I just searched openwrt forums, but did not see PR for v2. Do you have the link for the git repo?

LS3434 · March 26, 2026, 8:23am

github.com/openwrt/openwrt

ipq40xx: add support for Netgear RBR50v2 and RBS50v2 (#22321)

main ← cptpcrd:add-rbk50v2

opened 08:24PM - 07 Mar 26 UTC

cptpcrd

+640 -0

The Netgear RBR50 and RBS50 (support added in 2cb24b3f3cd89692f3c0bd137f3f560ada…359bfa) had a second hardware revision which switches to NAND flash and makes a few other changes (details in the commit message). This patch adds support for both devices. All features seem to work. A few notes: - This is my first time writing a device tree. I relied heavily on the other `qcom-ipq4019-*.dts*` files for examples, and everything seems to work. - The device tree as written includes `qcom-ipq4019-orbi.dtsi` (which has a lot of Netgear Orbi-common functionality), though some of the GPIO pin assignments changed for this model so I had to override a few of the properties. I think it's still similar enough to continue using `qcom-ipq4019-orbi.dtsi` as a base, but if preferred I could just copy the relevant portions over and base it on `qcom-ipq4019.dtsi` directly (like [`qcom-ipq4019-rbx20.dtsi`](https://github.com/openwrt/openwrt/blob/557b092273e7ecb4f59305e2be63789522182145/target/linux/ipq40xx/dts/qcom-ipq4019-rbx20.dtsi) does). - As an experiment, I backported to 25.12 and tested (see the [`add-rbk50v2-25.12`](https://github.com/cptpcrd/openwrt/tree/add-rbk50v2-25.12) branch on my fork), and it works. No changes were needed except for renaming the device tree files (they were moved in 6c982c7db449648f4b9c6d5f0acf6c5fcd6f42e3). Based on the criteria for [backporting device support](https://openwrt.org/docs/guide-developer/device-support-policies#device_support_backports), this seems that it could _perhaps_ qualify (it's not a 100% clone but is quite close, and is easily confused with the v1 model).

sminkkinen · March 26, 2026, 8:24am

Oh wow! Great Good to see that this is an active platform!

LS3434 · March 26, 2026, 8:26am

No worries. It’s great that this device finally get some love form the devs. And appreciate the work you have done.

sminkkinen · March 26, 2026, 8:41am

Added this note to the repo!

NOTE: A more complete and community-reviewed OpenWrt port for both RBR50v2 (router) and RBS50v2 (satellite) is available at:

openwrt/openwrt#22321

That PR (by cptpcrd) includes proper DTS hierarchy inheriting from qcom-ipq4019-orbi.dtsi, support for both router and satellite, correct LED polarity, full NAND partition utilization (~103 MB vs our 43 MB), and nmrpflash installation without UART. We recommend using that PR as the primary source for flashing OpenWrt on RBR50v2/RBS50v2.