Armbian for Amlogic, Rockchip and Allwinner TV boxes: what ophub/amlogic-s9xxx-armbian actually installs
Supports running Armbian on Amlogic, Allwinner, and Rockchip devices. Support a311d, s922x, s905x3, s905x2, s912, s905d, s905x, s905w, s905, s905l, rk3588, rk3568, rk3399, rk3328, h6, etc.
At a glance
- What is it?
- The ophub/amlogic-s9xxx-armbian project builds Debian and Ubuntu images for TV boxes and single-board computers that official Armbian does not cover. Here is what the repository documents, how the install path works, and where it stops being the right choice.
- Who is it for?
- Adopt it if you own a listed box such as an X96-Max+, HK1-Box or Beelink-GT-King and want a Debian or Ubuntu server on it, and you accept that the boot chain and eMMC write are the risky steps. Do not adopt it for hardware outside the supported SoC table, or for a device you cannot reflash after a failed write.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 23, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this project fills: TV boxes that official Armbian does not build for
Official Armbian targets boards its maintainers support directly. A TV box bought for Android TV is not one of them, even when the SoC inside it is a standard Amlogic part. This project exists to close that gap. The README describes it as preserving the integrity of the official Armbian system while extending support for unofficially supported devices such as TV boxes, and adding a set of convenient management commands.
The audience is narrow and practical. It is people who already own hardware from the supported list, which the README organises by SoC: a311d, s922x, s905x3, s905x2, s905l3a, s905l3b and more, plus Rockchip parts such as rk3588, rk3568, rk3399 and rk3328, and Allwinner h6. Each row links to per-device issue threads, which is a signal of how support actually works here: a model is covered because someone reported that it boots, not because a vendor validated it.
The payoff is turning a device whose vendor stopped shipping updates into a machine you control, running packages from the Debian or Ubuntu archives. The cost is that you are running a distribution on hardware the distribution upstream does not officially claim. That trade-off is the whole project.
How the images are built and what lands on the device
The repository is a build system, not a single binary. The top-level entries include build-armbian/, compile-kernel/, rebuild, recompile, action.yml, documents/ and the README files in English, Chinese and Japanese. The primary language is Shell, and the build runs as a GitHub Action, which is why releases appear on a monthly cadence rather than on demand.
Recent releases follow a dated naming scheme: Armbian_bookworm_arm64_server_2026.09, Armbian_noble_arm64_server_2026.09 and Armbian_resolute_arm64_server_2026.09, all published on 2026-09-01. The names tell you the base: bookworm and noble are Debian and Ubuntu release codenames, arm64 is the architecture, and server means no desktop. The kernel comes from a separate repository, ophub/kernel, with a kernel_stable tag referenced throughout the device table.
On first boot the system presents a known default: username root, password 1234, SSH on port 22, and an IP address the README says to obtain from the router. Those defaults are documented, not secret, which means the first thing a new install needs is a password change and a look at what else is listening. The README also lists a Docker variant, Armbian.Docker, with the same root/1234 credentials and a static MacVLAN IP instead of a DHCP lease.
Writing to eMMC and updating the kernel are both named as supported features, and both are where the project's real complexity lives.
Installing Armbian on an Amlogic box and getting to a first login
The README does not inline a step-by-step flashing procedure. It points to the Armbian User Documentation under documents/ and to the Releases page for images, where the assets are named by base and date. The README's default information table gives the login details for the installed system: username root, password 1234, SSH port 22, and an IP address obtained from the router.
# Default Information for Armbian System
# System Name: Armbian.OS
# Default Username: root
# Default Password: 1234
# SSH Port: 22
# IP Address: Obtain from routerBecause the README publishes those values rather than generating per-device credentials, the first login is also the first security step. The README does not describe a forced password change on first boot, so treat the change as something you perform yourself.
Once you are in, the project's own management commands are the ones worth learning first. The README refers to them as a set of convenient management commands; the documents directory covers their use. Kernel updates and writing the running system to eMMC are the two operations the README calls out by name, and both are invoked from the installed system rather than from a host PC.
The Docker path differs in one respect that matters for networking: the README states that Armbian.Docker uses a static MacVLAN IP rather than an address handed out by the router, so plan your subnet before you start it.
The supported device list is the real compatibility contract
Everything about this project is downstream of one table. The README ranks models by SoC performance from high to low and links each one to an issue or pull request where that model was discussed. That structure is honest about how support arrives: a311d covers Khadas-VIM3 and WXY-OES; s922x covers Beelink-GT-King, Beelink-GT-King-Pro, Ugoos-AM6-Plus, ODROID-N2, X88-King, Ali-CT2000 and WXY-OES-Plus; s905x3 is the longest list, running from X96-Max+ and HK1-Box through Vontar-X3, H96-Max-X3, Ugoos-X3, several TX3 revisions, X96-Air and Khadas-VIM3L.
The lower tiers are where the cheap hardware lives. s905x2 lists X96Max-4G, X96Max-2G, MECOOL-KM3-4G, Tanix-Tx5-Max, A95X-F2, HG680-FJ and ZTE-B860H-V5. The s905l3a and s905l3b rows are almost entirely carrier-issued boxes: E900V22C/D, CM311-1a-YST, M401A, M411A, UNT403A, UNT413A, ZTE-B863AV3.2-M, CM201-1, CM211-1, M302A/M304A, Hisense-IP103H, TY1608, MGV2000 and B860AV-2.1M.
Read that as a warning as much as a feature list. Two boxes with the same SoC can differ in RAM, eMMC size, WiFi chip and, most importantly, bootloader. The table tells you a model has been reported working; it does not tell you that your unit, from a different production batch, will behave the same way. When a model is missing, the README offers no generic fallback, and the correct move is to search the issue tracker before flashing anything.
Where it fails: eMMC writes, boot chains and unlisted hardware
The riskiest documented operation is writing the system to eMMC. It is listed as a feature, and it is also the step that can leave a box unbootable if the image does not match the hardware or the write is interrupted. The README does not document a rollback path for a failed eMMC write, and it does not describe a recovery procedure for a device that no longer boots from internal storage. If you have no way to reflash the box from a host PC, keep the system on the SD card or USB stick and treat eMMC as optional.
The second failure mode is quieter. The default credentials are published in the README: root, password 1234, port 22. A box that boots successfully and is left on a network with those credentials is a box anyone on that network can log into. This is not a flaw in the image so much as a consequence of shipping a known default, but it means the first login is a security step, not a formality.
Third, this is the wrong tool outside its list. If your device is not in the SoC table, the project does not claim to support it, and no amount of build flags changes that. And if you want a desktop, the published images are server builds; the release names say so explicitly. A TV box with 2 GB of RAM and a slow eMMC is a poor desktop anyway, which is presumably why the project does not ship one.
How it differs from running official Armbian or a vendor Android image
Official Armbian is the closest comparison and the most useful one. The difference is scope, not philosophy: official Armbian builds for boards its maintainers can test, and this project builds for the leftovers, using the same Debian and Ubuntu bases and the same package ecosystem. If your board is officially supported, official Armbian is the better choice, because the boot configuration is maintained by the people who own the hardware. If it is not, this project is the one that has a device table at all.
The other alternative is leaving the vendor Android image in place. That keeps the remote, the launcher and whatever streaming apps the box shipped with, and it keeps the vendor's update schedule, which for a discontinued TV box is usually no schedule. The README frames the switch as replacing the Android TV system to turn the box into a server. That framing is accurate about the trade: you gain a normal Linux userland and lose the media interface the box was designed around.
A third option, for people who only want a router or a network appliance, is the sibling project referenced throughout the device links, ophub/amlogic-s9xxx-openwrt. Several device entries point there rather than to this repository. If your goal is routing rather than a general-purpose server, that is the branch of the family to look at first.
Maintenance, licensing and what a monthly release cadence costs you
The repository is not archived, and the last push was on 2026-09-21. The release train is monthly: the three 2026.09 images were published on 2026-09-01, and earlier months follow the same pattern. That cadence is the maintenance model. There is no long-term support branch named in the README, so the practical upgrade path is to take a newer monthly image and rewrite the device, or to update the kernel from the ophub/kernel releases.
That has a real cost. A monthly image means the base distribution moves under you, and a rebuild is not an in-place distribution upgrade. Kernel updates are supported, and the kernel repository is versioned by tag, which gives you something to pin to, but the README does not describe a rollback for a kernel that fails to boot on your specific box.
The licence is GPL-2.0. The practical implication is the usual one for a build system: if you fork it and distribute modified images, the source for those modifications has to travel with them. That is a statement about the licence text, not legal advice, and anyone shipping these images commercially should read the licence and the Debian and Ubuntu terms for the packages inside the image separately. The README explicitly invites forking and customising, so the project anticipates derivative builds.
Editorial conclusion
Adopt it if you own a listed box such as an X96-Max+, HK1-Box or Beelink-GT-King and want a Debian or Ubuntu server on it, and you accept that the boot chain and eMMC write are the risky steps. Do not adopt it for hardware outside the supported SoC table, or for a device you cannot reflash after a failed write. Verify first that your exact model appears in the table, that the release archive contains an image for your SoC, and that you know how to reach the device over SSH on port 22 after the first boot.
Frequently asked questions
What is Armbian for?
Armbian is a lightweight Linux distribution built for ARM chips and based on Debian or Ubuntu, according to the README. This project extends it to unofficially supported devices such as TV boxes, so a box that shipped with Android TV can run a Debian or Ubuntu server instead.
How do I install Armbian on a supported TV box?
The README does not inline a flashing procedure; it points to the Armbian User Documentation under documents/ and to the Releases page for images. After the first boot you log in as root with password 1234 on SSH port 22.
Is Armbian good for beginners?
The published images are server builds with a documented default login, and the README lists writing to eMMC and kernel updates as supported operations, neither of which it walks through step by step. A user who cannot reflash the box from a host PC after a failed eMMC write should keep the system on SD or USB instead.
Community notes