No description
  • C 60.9%
  • Makefile 23.2%
  • Shell 8.1%
  • Perl 2.7%
  • UnrealScript 2.1%
  • Other 2.9%
Find a file
Jonas Jelonek 98f3808362
realtek: add support for Ubiquiti UniFi USW Pro Max 24 PoE
Add support for RTL9302B-based Ubiquiti UniFi USW Pro Max 24 PoE switch
with 16x GbE and 8x 2.5G RJ45 ports, 2x SFP+, and a front display.

Hardware
========

  - RTL9302B switch SoC
  - 512 MiB RAM
  - 32 MiB SPI-NOR flash
  - 16x 100M/1G RJ45 ports via 2x RTL8218E
  - 8x 100M/1G/2.5G RJ45 ports via 2x RTL8224
  - PoE:
      - 400W total budget
      - 8x 802.3at, 32W per port (ports 1-8)
      - 16x 802.3bt, 60W per port (ports 9-24)
  - 2x SFP+ ports
  - Buttons: 1x Reset
  - LEDs: RGBW LED per port (Etherlighting)
  - Front touch display via USB ACM (see below)
  - Console: TTL 3.3V, 115200 8N1 (internal pin header close to SoC;
    layout front to back: VCC RX TX GND)
  - Etherlighting feature (lighting patterns and color control)
  - Vendor firmware: U-Boot + LEDE-based Ubiquiti OS

MAC address
===========

Single MAC address in EEPROM partition, applied to all ports.

Front touch display
===================

The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU. Unlike other Ubiquiti switches where the MCU is
connected to the SoC via UART directly, here it is exposed as a USB
CDC-ACM serial device through an on-board Genesys Logic GL850G USB hub.
The MCU runs Ubiquiti's LCM firmware and exposes a high-level JSON
protocol (page selection, button-press events, etc.); arbitrary
pixel-level control is not possible without replacing the MCU firmware.
Display support therefore depends on both USB host support and a driver
for the LCM protocol, neither of which is currently available.

Known issues
============

  - Etherlighting not controllable, driver WIP. Port LEDs for link work
    though. By default, the controller keeps the LEDs in a breathing
    state, gated by the link state delivered by the Realtek SoC.

Disclaimer
==========

Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt writes or invalidates both stock kernel slots; U-Boot
remains intact and can be used for recovery.

Installation
============

1. Enable SSH on the stock UniFi OS and log in with user account.

2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
   scp).

3. Adjust IMG below to point at the copied file, then run the block as a
   whole. It verifies the expected stock partition layout and image size,
   writes kernel0, splits into kernel1 if the image is larger than that
   slot (otherwise invalidates kernel1 so U-Boot cannot pick a stale
   bank), and reboots:

   set -e
   IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-pro-max-24-poe-squashfs-sysupgrade.bin
   K0_SIZE=$((0xf10000))
   K0_BLOCKS=$((K0_SIZE / 0x10000))

   grep -q '^mtd2: 00f10000 00010000 "kernel0"$' /proc/mtd
   grep -q '^mtd3: 00f20000 00010000 "kernel1"$' /proc/mtd
   IMG_SIZE=$(wc -c < "$IMG")
   [ "$IMG_SIZE" -gt 0 ]
   [ "$IMG_SIZE" -le $((0x1e30000)) ]

   dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
   if [ "$IMG_SIZE" -gt "$K0_SIZE" ]; then
       dd if="$IMG" of=/dev/mtdblock3 bs=64k skip=$K0_BLOCKS conv=fsync
   else
       dd if=/dev/zero of=/dev/mtdblock3 bs=64k count=1 conv=fsync
   fi
   sync
   reboot

   The switch comes up in OpenWrt after reboot.

4. It is recommended to modify the bootcmd to speed up the boot and
   prevent any issues due to the dual-boot selection. Since U-Boot by
   default uses bootubnt which does a lot of (unneeded) RTK
   initialization, quite some time passes until Linux is started.
   Additionally, the U-Boot logic fiddles with some bits on flash which
   causes JFFS2 errors in OpenWrt. While this doesn't seem to cause
   issues yet, be defensive and set the bootcmd from OpenWrt with:

     fw_setenv bootcmd 'bootm 0xb40b0000'
     fw_printenv bootcmd

   This directly boots the uImage from flash, without doing all the
   initialization. OpenWrt is able to bootstrap the networking
   completely on its own.

It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.

Recovery
========

Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).

1. Interrupt U-Boot autoboot by spamming a key during early boot to
   drop into the U-Boot prompt.

2. Bring up networking:

   rtk network on

3. Transfer an OpenWrt initramfs image via TFTP and boot it:

   tftpboot 0x82000000 <server>:<initramfs.bin>
   bootm 0x82000000

4. From the running initramfs OpenWrt, do a sysupgrade to reflash
   OpenWrt or whatever you want to recover. There is no need for the
   complicated procedure from installation since OpenWrt sees the
   firmware partition already as a whole.

Return to stock firmware
========================

There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.

The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:

   BLOB=<firmware.bin>
   OFF=$(grep -aboF $'\x27\x05\x19\x56' "$BLOB" | head -1 | cut -d: -f1)
   SIZE=$(( $(dd if="$BLOB" bs=1 skip=$((OFF + 12)) count=4 2>/dev/null \
               | hexdump -e '1/4 "%u"') + 64 ))
   dd if="$BLOB" of=kernel0.uImage bs=1 skip="$OFF" count="$SIZE"

Once you have a clean uImage, boot an OpenWrt initramfs as described in
Recovery, copy kernel0.uImage to /tmp, and run:

   set -e
   [ "$(wc -c < /tmp/kernel0.uImage)" -le $((0xf10000)) ] || exit 1
   mtd write /tmp/kernel0.uImage firmware
   fw_setenv bootcmd bootubnt
   fw_printenv bootcmd
   reboot

After rebooting, Ubiquiti's firmware should boot.

Or, if you made backups of the flash before installation, just write
the backup back to flash.

Link: https://github.com/openwrt/openwrt/pull/25280
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
2026-09-23 21:15:01 +02:00
.devcontainer/ci-env
.github
.vscode
config kernel: add KERNEL_TIME_NS Kconfig knob 2026-09-18 16:03:13 +01:00
include tools/cmake: pass -DBUILD_TESTING=OFF to bootstrap 2026-09-23 16:29:25 +02:00
LICENSES
package valgrind: fix ARMv7 detection on AArch64 2026-09-23 17:02:01 +02:00
scripts build: create reproducible CycloneDX SBOMs 2026-09-22 18:46:30 +02:00
target realtek: add support for Ubiquiti UniFi USW Pro Max 24 PoE 2026-09-23 21:15:01 +02:00
toolchain toolchain: keep the build path out of the target libraries 2026-09-22 18:46:30 +02:00
tools tools/cmake: pass testing option after bootstrap separator 2026-09-23 16:57:43 +02:00
.gitattributes
.gitignore
BSDmakefile
Config.in
COPYING
feeds.conf.default
Makefile build: write the build info files only when they change 2026-09-22 18:18:58 +02:00
README.md
rules.mk build: start the configure cache cold when its answers may be stale 2026-09-22 20:29:59 +02:00

OpenWrt logo

OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customization, to use the device in ways never envisioned.

Sunshine!

Download

Built firmware images are available for many architectures and come with a package selection to be used as WiFi home router. To quickly find a factory image usable to migrate from a vendor stock firmware to OpenWrt, try the Firmware Selector.

If your device is supported, please follow the Info link to see install instructions or consult the support resources listed below.

An advanced user may require additional or specific package. (Toolchain, SDK, ...) For everything else than simple firmware download, try the wiki download page:

Development

To build your own firmware you need a GNU/Linux, BSD or macOS system (case sensitive filesystem required). Cygwin is unsupported because of the lack of a case sensitive file system.

Requirements

You need the following tools to compile OpenWrt, the package names vary between distributions. A complete list with distribution specific packages is found in the Build System Setup documentation.

binutils bzip2 diff find flex gawk gcc-6+ getopt grep install libc-dev libz-dev
make4.1+ perl python3.8+ rsync subversion unzip which

Quickstart

  1. Run ./scripts/feeds update -a to obtain all the latest package definitions defined in feeds.conf / feeds.conf.default

  2. Run ./scripts/feeds install -a to install symlinks for all obtained packages into package/feeds/

  3. Run make menuconfig to select your preferred configuration for the toolchain, target system & firmware packages.

  4. Run make to build your firmware. This will download all sources, build the cross-compile toolchain and then cross-compile the GNU/Linux kernel & all chosen applications for your target system.

The main repository uses multiple sub-repositories to manage packages of different categories. All packages are installed via the OpenWrt package manager called opkg. If you're looking to develop the web interface or port packages to OpenWrt, please find the fitting repository below.

  • LuCI Web Interface: Modern and modular interface to control the device via a web browser.

  • OpenWrt Packages: Community repository of ported packages.

  • OpenWrt Routing: Packages specifically focused on (mesh) routing.

  • OpenWrt Video: Packages specifically focused on display servers and clients (Xorg and Wayland).

Support Information

For a list of supported devices see the OpenWrt Hardware Database

Documentation

Support Community

  • Forum: For usage, projects, discussions and hardware advise.
  • Support Chat: Channel #openwrt on oftc.net.

Developer Community

License

OpenWrt is licensed under GPL-2.0