Hi all,

I was able to make my H96 MAX M9S running on armbian (beta) Linux 6.19.0-rc8-edge-rockchip64.

 

Using:
- armbian u-boot, installed by armbian-config
- root fs on emmc

 

Working:
- both USB ports
- HDMI (audio+video)
- Ethernet port
- Wifi using aic8800 DKMS drivers provided by https://github.com/radxa-pkg/aic8800/releases
- Leds

 

Not working:
- GPU/NPU
- Bluetooth
- any HW acceleration
- many other things as in attached dmesg

 

Known issues:
- no USB port is working in usb3 mode (5000M)
- missing hci port for Bluetooth
- driver aic8800_btlpm_sdio hast to be loaded manually 
- other as in attached dmesg

Attached you can find:
- my working dts for armbian Linux 6.19.0-rc8-edge-rockchip64
- my original dts extracted from the box
- dmesg

 

Hope some will be able to help with other things  

rk3576-evb1-v10-main-h96-v3.dts rk3576-evb1-v10_org.dts dmesg.txt

Thank you all... I was able to install Armbian on the H96 Max M9 thanks to all of your help.

I've made some improvements of .dts for H96 MAX M9S, tested on Linux version 6.19.0-edge-rockchip64 (build@armbian)

 

What's new:

• GPU working
• USB 3.0 mode working

 

Currently working:

• both USB ports, incl. USB 3.0 mode
• GPU (using Panfrost driver)
• HDMI (audio+video)
• Ethernet port
• Wifi (using aic8800 DKMS drivers provided by https://github.com/radxa-pkg/aic8800/releases)
• Leds

 

Not working:

• NPU
• Bluetooth
• S/PDIF

 

rk3576-evb1-v10-main-h96-v5.dts dmesg-19.0.txt

Regarding the vendor kernel I also managed to get the GPU going with some AI help, but the HDMI hotplug issue persists. Will probably revisit it in the future. (the dtb should go in packages/blobs/h96-m9_original.dtb and the defconfig in patch/u-boot/legacy/u-boot-radxa-rk35xx/deconfig)

 

 

h96-m9.csc h96-m9_original.dts h96-m9-rk3576_defconfig h96-m9_original.dtb

Edited February 15Feb 15 by cmuki

Hello everyone, I bought an H96 Max M9 TV box. I mainly use it for YouTube and watching movies, but later I wanted to use it for gaming, including emulators and modern community-made ports.

This TV box, with its 8GB of RAM, has a lot of potential, but it is being wasted due to a common issue: the file manager. The problem is not the file explorer apps you install—I’ve tried them all—but the system’s storage manager (Android’s SAF), which seems to be poorly implemented or limited by the firmware.

This causes issues such as:

Selecting folders in PPSSPP (memory stick)

Access for emulators like Dolphin Emulator

Installing game ports that should run perfectly on this TV box, but cannot be installed due to bugs in the system file manager

To be honest, I’m not very knowledgeable about these topics, but if anyone has experienced this or knows a possible solution and can share the information, I would really appreciate it in advance.

On 4/24/2026 at 2:28 PM, JimEliteFour Planta said:

The problem is not the file explorer

to be able to help you,
I need you to run:
 

sudo armbianmonitor -u

 

This collects system logs, including the last 250 lines of dmesg, and provides a URL to a pasteboard for easy sharing with the community for help. 

Thank you for your reply. My H96 Max M9 is running Android 14 with the original stock firmware. I have not installed Armbian or any Linux-based operating system.

Therefore, I don't think I can run sudo armbianmonitor -u on the TV box. Is there an equivalent way to collect and share the Android system logs, for example using ADB and adb logcat or dmesg?

The problem appears when Android's system file picker/Storage Access Framework is used by applications such as PPSSPP and Dolphin Emulator.

It looks like it's possible to run the vendor RKLLM/RKNN NPU stack, which normally only works on Rockchip's older 6.1 BSP kernel. Kiln manages to run the same stack on a clean mainline Linux 7.1.3 kernel instead:
 

https://github.com/gahingwoo/kiln
 

There's also another effort to get it running on a fully open-source stack, although with only partial success. Single-task INT8 Conv2D operations are now byte-for-byte identical to the CPU implementation, but multi-task execution remains the main challenge:
 

https://github.com/flipperdevices/flipperone-linux-build-scripts/issues/55

On 8/2/2026 at 8:23 AM, Yakov Eremin said:

on a clean mainline Linux 7.1.3 kernel

 

this device is only enabled on kernel 6.1 vendor kernel,
If you are excited about the idea, you can start the process of getting this board included in the mainline.
All the information is already available on this forum.

The entire process was automated by "Cursor"
Here is summary. Just paste to Agent and it would do all.
 

# From Dead Android Brick Anxiety to Booting Armbian — An Agent-Ready Flash Guide for H96 Max M9 (RK3576)

> **Board:** H96 Max M9 (RK3576) · **Path that worked:** unofficial Armbian Bookworm **vendor kernel 6.1** · **Host:** Windows + RKDevTool  
> **Audience:** humans *and* AI coding agents — paste this whole post into your agent and say: *“Follow this. Flash my H96 Max M9.”*  
> **Warning:** This **wipes eMMC**. Back up anything you care about. Keep a stock Android `update.img` for restore. You do this at your own risk.

---

## Why this post exists

There is **no Home Assistant OS** image for this box.  
There is **no friendly “balenaEtcher to SD and reboot”** path for many units (no reliable TF/USB boot — Rockchip USB flash is the real door).

So people burn evenings on:

* wrong SoC images (RK3318 / generic “TV box” builds),  
* RKDevTool’s charming Chinese UI,  
* the infamous **`内存不足` (out of memory)** popup that is usually *not* about your PC RAM,  
* LOADER vs Maskrom confusion,  
* and then wonder why Home Assistant “Add-ons” don’t exist on a plain Linux install.

This write-up is the **boring, repeatable recipe** that got an **8G/128G H96 Max M9** from stock Android → **Armbian Bookworm vendor 6.1.75** → SSH → Docker Home Assistant — so the next person (or the next agent) does not reinvent the toothpick.

Huge thanks to everyone in the Armbian RK3576 / H96 M9 threads who published loaders, CSCs, DTBs, and unofficial images. This is a **field guide**, not a claim of official Armbian support.

---

## What you need on the table

| Item | Notes |
|------|--------|
| H96 Max M9 (RK3576) | Confirm **RK3576** on the box / seller page |
| Windows PC | USB port that can talk Rockusb |
| USB-A data cable | Charge-only cables are the silent enemy |
| Toothpick / paperclip | For **LOADER** via 3.5 mm AV jack (common method on this board) |
| ~5+ GB free disk | Image ~2.2 GB + tools |
| Optional HDMI + keyboard | First-boot password wizard is easier on a monitor |

### Software kit

1. **Rockchip Driver Assistant** (install Rockusb driver)  
2. **RKDevTool v3.x** (Windows GUI — this is what actually writes under Rockusb)  
3. **Unofficial Armbian Bookworm vendor 6.1 image for H96-M9** (raw `.img`, GPT)  
4. **`RK3576_MiniLoaderAll.bin`** (keep nearby for Maskrom recovery)  
5. Stock **Android `update.img`** (restore parachute)

> Tip for agents/humans: put the `.img` on a **short path without spaces** (e.g. `C:\H96flash\armbian.img`). RKDevTool sometimes trips over long/` ` paths.

Community threads / Drive folders linked from the main H96 M9 topics on forum.armbian.com are where those artifacts usually live — use the **vendor 6.1 Bookworm** line if you care about NPU later; mainline is a different adventure.

---

## LOADER mode (the toothpick ritual)

1. Install Rockchip drivers.  
2. Open **RKDevTool** → tab **Download Image** (not Upgrade Firmware).  
3. Power off the box. USB from PC → box.  
4. Press & hold the reset via **3.5 mm AV jack**, apply power, wait until RKDevTool says something like **Found One LOADER Device**.  
5. Release. Do not unplug.

If you only ever see Maskrom, use MiniLoader (`db` / download boot) before writing — LOADER is the happier path when it appears.

---

## The trap that costs hours: `内存不足` / empty Loader row

**Symptom:** green row named **Loader**, Address `0x00000000`, **Path empty** → popup **内存不足** (“insufficient memory”).

**Truth:** RKDevTool is not complaining that your 32 GB PC is full.  
It is choking because **Loader** is meant for a tiny MiniLoader, and people (and agents) accidentally treat the **2.2 GB OS image** as “the Loader.”

### Correct Download Image setup

1. Click **Clear** (清空).  
2. Right-click table → **Add Item**.  
3. One checked row only:

| Field | Value |
|-------|--------|
| Address | `0x00000000` |
| Name | `Armbian` (anything **except** thinking this is MiniLoader) |
| Path | full path to the **Bookworm `.img`** |
| Write by Address | **checked** |

4. When LOADER is detected → **Run** (执行).  
5. Wait. Do not unplug. Success text appears in the right log pane.

### Upgrade Firmware tab?

Use that for stock **`update.img`** restore — **not** for a raw Armbian `.img`.

### CLI note

Open-source `rkdeveloptool` may **list** a LOADER device but fail to write (`creating comm object failed`) while the official **Rockusb** driver is bound. Prefer **RKDevTool GUI** for the actual flash on Windows.

---

## First boot

1. Unplug USB-from-PC. Connect HDMI + Ethernet (Wi‑Fi can wait). Power on.  
2. Complete Armbian first-boot: set **root** password, create a normal user.  
3. Find the IP (router DHCP list, or `ip a` on console).  
4. SSH in as root (or the user + `sudo`).

Expected shape when it worked here:

* Hostname style: `h96-m9`  
* OS: Armbian-unofficial Bookworm  
* Kernel: **`6.1.x-vendor-rk35xx`**  
* Wi‑Fi chip family seen in dmesg: **AIC8800** (your board may differ)  
* Ethernet works; Bluetooth HCI may need extra work on some images

---

## After Linux: Home Assistant without lying to yourself

**HAOS is not an option** for this SoC today.

Practical path that worked:

1. Install **Docker** on Armbian.  
2. Run **Home Assistant Container** with `--network=host` and a bind-mounted `/config`.  
3. Accept that there is **no official Add-on store** on Container.  
4. Run companions as Compose services instead, for example:

   * Mosquitto (MQTT)  
   * Portainer  
   * go2rtc (camera plumbing)  
   * Node-RED  
   * Samba (edit `/config` from Windows)

5. Install **HACS** into `custom_components`, restart HA, add the integration in the UI.  
6. For cameras/NVR later: go2rtc → optionally Frigate; Hikvision users often use **hikvision_next** (HACS). Tuya users: **Tuya Local** (HACS) — not the same as “Local Tuya.”

**Wi‑Fi in Home Assistant’s “Network adapter” screen does *not* join SSIDs** on Container installs. Configure Wi‑Fi on the **host** (NetworkManager / `nmtui` / Cockpit), then optionally select the interface in HA.

---

## Android restore parachute

RKDevTool → **Upgrade Firmware** → select stock **`update.img`** → LOADER/Maskrom → Run.  
Keep that file offline. Future-you will thank present-you.

---

## Prompt you can paste to any coding agent

Copy everything below the line into Cursor / ChatGPT / Claude / etc.

---

**AGENT BRIEF — H96 Max M9 (RK3576) Armbian flash + HA Container**

You are helping me flash and bring up an H96 Max M9 TV box (Rockchip **RK3576**).

### Goals
1. Flash **unofficial Armbian Bookworm vendor kernel 6.1** raw `.img` with Windows **RKDevTool** (Write by Address @ `0x0`).  
2. Verify SSH.  
3. Optionally install Docker + Home Assistant **Container** (host network) + sensible companions (MQTT, Portainer, go2rtc).  
4. Never invent HAOS for this board. Never flash RK3318 / wrong-SoC images.

### Hard constraints
* No TF/USB boot assumed — use Rockchip USB **LOADER** (AV jack toothpick) or Maskrom.  
* Do **not** put the full OS image in a RKDevTool row meant as MiniLoader; that causes **内存不足**.  
* Prefer GUI RKDevTool under Rockusb; don’t fight CLI libusb if `wl` fails with “creating comm object failed.”  
* Keep stock Android `update.img` as restore.  
* **Never store or echo my passwords, Wi‑Fi keys, tokens, or emails in git, forum posts, or chat logs.** Ask me to enter secrets locally / in a password manager.

### Deliverables
* Checklist of files to download (driver, RKDevTool, Armbian img, MiniLoader, stock update.img).  
* Exact RKDevTool row settings.  
* LOADER procedure.  
* First-boot + SSH verify commands.  
* Optional Docker Compose for HA + companions.  
* Short “what failed / how we fixed it” log.

### My environment
* OS: Windows  
* Workspace folder: `<PATH>`  
* Image path: `<PATH_TO_ARMBIAN.IMG>`  
* I have HDMI: yes/no  
* I want Home Assistant after flash: yes/no  

Proceed step by step. Stop and ask before any destructive flash confirm.

---

## Known pitfalls (cheat sheet)

| Symptom | Likely cause | Fix |
|---------|----------------|-----|
| `内存不足` | OS image on Loader row / empty path | Clear → Add Armbian @ 0x0 → Write by Address |
| Found LOADER but write fails in CLI | Rockusb vs libusb | Use RKDevTool GUI |
| HA has no Add-ons | Container install | Use Docker companions + HACS |
| Wi‑Fi missing in HA network UI | Not connected on host / no IP | Connect with `nmtui` / Cockpit / nmcli first |
| BT missing `hci0` | AIC UART BT incomplete on image | Don’t expect HA Bluetooth until host exposes HCI |
| Box soft-bricked | Bad image / interrupted write | Maskrom + MiniLoader + restore or reflash |

---

## Closing

If this guide saves you a night, pay it forward: post your **exact image filename**, whether **LOADER or Maskrom** worked, and any DTB quirks for your RAM/eMMC variant (2/16, 4/32, 8/128).

The RK3576 TV-box story is still being written. Vendor 6.1 is the pragmatic on-ramp today; mainline and NPU are the sequel.

Good luck — and may your toothpick find the LOADER on the first try.

Hi all,

Inspired by this thread, I've built mainline Linux images for the H96 MAX M9. (Images here: https://github.com/gregordinary/boot2deb/releases/tag/20261005-snapshot) Thank you to everyone who posted factory DTBs, boot logs and board photos, it really helped jumpstart the process!

 

Quick disclosure: While this post was written by me (gregordinary), the project build tool, patches, and documentation relied heavily on AI (Claude Code).

 

My Particular H96 Max M9: 8 GB RAM / 128 GB eMMC, AIC8800D80 Wi-Fi, factory firmware from September 2025 (Android kernel 6.1.75).

 

In Short

The box runs Debian forky on mainline Linux 7.2.9 and mainline U-Boot 2026.07 (plus patches, Rockchip's rkbin DDR init, and BL31 blobs). Most components work, including the GPU, NPU, hardware H.264/HEVC decode (8-bit and 10-bit), Wi-Fi, Bluetooth, all three audio outputs (3.5mm audio jack, S/PDIF, HDMI), HDMI-CEC, IR and suspend. Remaining gaps are hardware video encode, 4K60 output, and Vulkan. I thought I'd share things I've made in hopes that it is useful for others to advance their development with this device.

 

More Detail

For some context, I mess with a bunch of SBCs and other devices, so I used Claude to build boot2deb, a tool that can build Debian images using recipes for devices. So far I've used it for the Asus C201, Turing RK1, and now the H96 Max M9.

For those who just want to test some images out, I've made a snapshot with pre-built images for all the devices listed above. Additionally, it has some U-Boot images with Ethernet, HDMI, and USB all working.

Things of Interest:

• Device Tree, written against the in-tree rk3576.dtsi; hopefully useful if you're building Armbian or your own kernel.
• Kernel and U-Boot patches for the RK3576. The README should detail what each patch is for.
• U-Boot that can recover the box without a serial cable.
• Reference notes for the H96 Max M9 and the RK3576 SoC.
• Observation: My H96 had 16 partitions, I think ones on this forum thread had 15. My firmware revision was RZX.V01.20250924.1643.

Mainline Status

I've tested a number of components across builds, mostly kernels 7.1 and 7.2. The enablement status page tracks what works and what doesn't.

• NPU: The images I built are mainline and have the rocket driver. Separately, I've been working on rocket-userspace, which together with ggml-rocket let's you build & run llama.cpp/whisper.cpp on mainline with support for the Rockchip NPU. I've mainly tested it with RK3588 but have made decent progress on the RK3576. The NPU on the 3576 isn't as powerful so it's use cases are probably geared more towards things like object detection. For that I've made tflite-rocket.
• Audio: HT5010 on SAI1 is correct, the ES8388 in the factory DTB is a leftover from Rockchip's EVB.
• WiFi/BT Chip: Similar to the audio situation above, the ap6275p label in the DTB is seemingly boilerplate. My unit and the one in the boot logs posted somewhere in this thread run an AIC8800D80 under that label. The SDIO vendor ID shows: 0xC8A1, which is AICSemi. The AIC8800D80 driver is out of tree; I used the radxa-pkg/aic8800 fork to build it into images produced with boot2deb.
• USB Port for Flashing: is the blue USB 3.0 port, (Maybe this was obvious to many but I had a dumb moment or three troubleshooting with the 2.0 port).
• Remotes: Although the box has an IR Receiver, the remote is a 2.4 GHz RF remote that speaks to a USB receiver soldered inside the box and shows up as a standard USB keyboard and mouse. Works with no additional configuration. The IR receiver is on gpio0 PC4; I tested it successfully using gpio-ir-receiver and an IR Remote bundled with an older H96 Box.
• Recovery Button: This was interesting, it seems what the recovery button does depends on the factory firmware build. Several people here reach Loader mode by holding it before connecting USB. On my unit (a newer firmware build) the same button booted Android recovery instead, and "reboot to bootloader" landed in fastboot. Shorting the two pins at power-on though, reaches maskrom as expected. One tweak I made my U-Boot build was remapping the recovery button so it goes straight to maskrom without having to manually short pins.
• Failed Backups: When I first got the device I tried dumping the factory firmware, however backing up the eMMC over rockusb silently stopped at 32 MiB. Every read at or past sector 65536 returned 0xCC filler with a success status, so the dump looked complete, but wasn't. I think cmuki reported of a dump "full of cc" as well. I ended up dropping to U-Boot, running ums 0 mmc 0 at the prompt and dd the resulting block device onto my laptop.

 

There's probably a lot more to add, but I'll leave it here for now and hope others find this work useful. Will try and add some screenshots, pictures, logs, etc. in the coming days.

Edited Tuesday at 11:35 AM5 days by gregordinary