ophub/amlogic-s9xxx-openwrt: OpenWrt Firmware for Amlogic, Rockchip and Allwinner TV Boxes

The problem: Android TV boxes with no supported router firmware

Cheap Amlogic, Rockchip and Allwinner boxes sit in drawers once their Android build stops receiving updates. Their SoCs are capable of routing, and the hardware is already paid for. The problem is that no upstream OpenWrt target covers these boards as a group. OpenWrt's own device support is per-board and per-commit, and a TV box vendor's Android kernel is not a substitute.

This project fills that gap by building OpenWrt images for a long list of boxes. The README states it builds for Amlogic, Rockchip and Allwinner boxes, supports installation to eMMC and kernel updates, and points to documents/ for detailed usage. The audience is people who already own one of the listed devices: X96-Max+, HK1-Box, Ugoos-AM6-Plus, ODROID-N2, Khadas-VIM3, Beelink-GT-King, and many others in the SoC table. It is not aimed at someone shopping for a router. It is aimed at someone who has a box and wants OpenWrt on it.

How the build works: SoC table, kernel repository, release branches

The repository is a build system, not a firmware binary. The README's supported-device table maps each SoC (a311d, s922x, s905x3, s905x2, s905l3a, s905l3b, and others) to concrete device names and to a kernel source at ophub/kernel, tagged kernel_stable. So the path is: pick your device, find its SoC row, and use the kernel branch that row points at.

Releases are published as saves of upstream OpenWrt trees. The three most recent are OpenWrt_openwrt_main_save_2026.09, OpenWrt_lede_master_save_2026.09 and OpenWrt_immortalwrt_master_save_2026.09, all dated 2026-09-01. The naming tells you which upstream branch each image was built from: openwrt main, lede master, immortalwrt master. That matters because package sets and LuCI versions differ between those trees. The top-level repository layout includes config/, make-openwrt/, action.yml and remake, which is consistent with a GitHub Actions driven build that takes a config, composes an image and publishes it. The README does not document the internal build steps in the excerpt available, so treat the directory names as the visible structure rather than a documented pipeline.

Installing ophub OpenWrt on a supported box

The README says the latest firmware is downloaded from Releases and that usage instructions live in the documents/ directory. It also gives the default credentials and network settings in a table, which is what you need before you can log in. The default username is root, the default password is password, SSH runs on port 22, and the default IP address is 192.168.1.1. The same table applies to both OpenWrt.OS and OpenWrt.Docker images.

Start by identifying your SoC row in the README table and downloading the matching release asset from the Releases page. The release tags follow the save pattern shown in the README, for example OpenWrt_openwrt_main_save_2026.09, OpenWrt_lede_master_save_2026.09 and OpenWrt_immortalwrt_master_save_2026.09. After flashing according to documents/, the box should come up at the default address. Connect an Ethernet cable to the box and to your computer, then reach the web interface or SSH using the README's default information table:

System Name    | Default Username | Default Password  | SSH Port  | IP Address
OpenWrt.OS     | root             | password          | 22        | 192.168.1.1
OpenWrt.Docker | root             | password          | 22        | 192.168.1.1

Once in, the first real use is confirming the kernel and board were detected as expected, then installing packages through opkg as you would on any OpenWrt system. The README notes OpenWrt provides a writable filesystem with package management, so the box behaves like a normal OpenWrt router after boot. The documents/ directory is the authoritative place for the flashing steps; the README does not reproduce them.

Where it breaks: recovery, unlisted hardware and kernel drift

The honest limitation is hardware coverage. The README lists specific models per SoC, and a device that is not in that table is not supported, however similar its SoC looks. Two boxes with the same s905x3 label can differ in RAM, eMMC layout or Ethernet PHY, and the README's device links point to individual issue threads precisely because those differences were discovered one box at a time.

Recovery is the second constraint. Flashing to eMMC replaces the Android system, and the README does not document rollback in the excerpt available. If a build does not boot, you are relying on the recovery procedure in documents/ or on Amlogic's own flashing tools, not on a supported vendor path. Kernel updates add another variable: the README routes kernels through ophub/kernel at kernel_stable, and a kernel that works for one board in a SoC row is not a guarantee for another.

It is also the wrong tool for anyone who wants a router with a warranty, vendor firmware updates and a support contract. A repurposed TV box has none of those.

Compared with building OpenWrt yourself or using a general-purpose image

The alternative is the OpenWrt build system directly. You would clone the OpenWrt or ImmortalWrt tree, add a target and device definition for your box, and compile. That gives you full control over packages and kernel patches, and it is the right path if your board is not in the README table or if you need a patch that upstream does not carry. The cost is that you own the device tree, the bootloader handoff and every subsequent kernel bump.

This project's difference is that the device definitions and the kernel selection already exist as a maintained set, and releases are cut from three upstream trees (openwrt main, lede master, immortalwrt master) on a monthly cadence, with the most recent saves dated 2026-09-01. You trade control for a working starting point. If your box is listed and you want OpenWrt without writing a device port, that trade is the whole point. If it is not listed, the trade does not exist and you are back to the build system.

Licence, maintenance and upgrade cost

The repository is licensed GPL-2.0. That is the same licence family as OpenWrt itself, so redistribution of modified images carries the usual source-availability obligations. This is a description of the licence identifier, not legal advice; if you ship a modified image commercially, read the licence text in LICENSE and take your own counsel.

Maintenance is visible in two places. The last push to the default branch was on 2026-09-21, and the newest release saves are dated 2026-09-01. That pattern suggests a monthly release cadence tied to upstream branch saves, which means upgrade cost is mostly re-flashing or updating the kernel rather than patching a fork. The README points kernel work at ophub/kernel with the stable tag, so kernel upgrades follow that repository's releases.

The hidden cost is device-specific: every upgrade is a chance that a board which booted last month does not boot this month, and the recovery path is the one in documents/, not a vendor tool.

Editorial conclusion

Adopt it if you own a box from the README's supported device table and you are comfortable flashing eMMC and recovering a device that may not boot. Do not adopt it if your hardware is not listed, or if you need a vendor-supported router with a warranty. Before flashing, verify your exact model appears in the supported table for your SoC, check which kernel branch (stable) the release targets, and read the OpenWrt User Guide in documents/ for the recovery procedure.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. ophub/amlogic-s9xxx-openwrt on GitHub
4. README
5. Releases