sr4armbian

MXQ S805 running modern Armbian from raw NAND — because apparently I cannot throw old TV boxes away
 
Well... I have good news for the approximately seven people on Earth who still care about the Amlogic S805.
 
I am one of them.
 
Actually, I have three MXQ S805 boxes.
 
And several other TV boxes.
 
At this point I prefer to describe this as preservation of historically relevant ARM hardware, because “I have emotional attachment to electronic garbage” sounds less professional.
 
Also, I have tokens and I am not afraid to use them.
 
So after an unreasonable amount of digging through ancient Amlogic code, vendor kernels, NAND layouts, mysterious blobs, device trees and things that probably should have remained buried in Linux 3.10 forever... with Claude, Codex and Cursor enthusiastically helping me make questionable decisions.
 
The MXQ S805 is now running Debian 13 Trixie, kernel 6.12, directly from its original raw NAND.
 
No SD card.
No USB root filesystem.
No “modern kernel boots from SD but the internal NAND is just decoration”.
The root filesystem is actually on NAND.
Yes, HDMI.
 
Some proof from the box:
 
Linux aml-s805-mxq 6.12.28-current-meson #2 SMP Fri May 9 07:50:53 UTC 2025 armv7l GNU/Linux
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION="13 (trixie)"
And yes, this is still the mighty S805:
Architecture: armv7l
CPU(s): 4
CPU max MHz: 1536.0000
CPU min MHz: 96.0000
Flags: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 vfpd32
4 cores, 1.5 GHz, NEON.
 
Please stop laughing.
 
It is running Debian 13 from NAND, which is more than anyone reasonably expected from this thing.
 
The machine identifies as:
Machine model: MXQ S805 (raw NAND variant)
 
The NAND driver detects the original 8 GiB chip:
 
NAND device id: 45 de 94 93 76 50 e 4
detect NAND device: A serials NAND 8GiB SDTNRGAMA-008G
 
The old Amlogic NFTL layer comes up:
 
nftl ok!
aml_nftl_open ok!
amlnf_m3: added disk /dev/data size=10993664 sectors
 
And, most importantly:
 
/dev/data ext4 rw,noatime,errors=remount-ro,commit=600
 
lsblk:
 
NAME       SIZE TYPE FSTYPE MOUNTPOINTS
cache      512M disk
logo        32M disk
recovery    32M disk
misc        32M disk
boot        32M disk
system       1G disk
data       5.2G disk        /
zram0    491.7M disk swap   [SWAP]
 
And because someone will inevitably ask whether /dev/data is really the root filesystem:
 
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        459M     0  459M   0% /dev
/dev/data       5.1G  640M  4.5G  13% /
tmpfs           492M     0  492M   0% /dev/shm
tmpfs           197M  4.2M  193M   3% /run
tmpfs           492M     0  492M   0% /tmp
So yes.
 
/dev/data is /.
 
There is no SD card hidden behind the curtain.
 
No USB stick doing the actual work.
 
No assistant standing backstage holding an ext4 filesystem.
 
The S805 is genuinely running Trixie and 6.12 from its original NAND.
 
The driver also correctly sees the factory bad blocks:
 
nand block at blk 18 is bad
nand block at blk 19 is bad
nand block at blk 20 is bad
nand block at blk 21 is bad
 
Which, strangely enough, made me happier than finding no bad blocks.
 
Seeing the same factory bad-block information survive all these years feels almost archaeological.
 
The NAND work is here:
 
https://github.com/eloirotava/amlnf 
 
This is basically the old Amlogic NAND/NTD/NFTL stack dragged, complaining loudly, from the Linux 3.10 era into a modern kernel.
 
And because apparently one obsolete driver was not enough...
 
I have also been working on the infamous SSV6051/SSV6030 and SSV6256 Wi-Fi chips used in many old TV boxes.
That driver is here:
 
https://github.com/eloirotava/ssv6xxx
 
So yes:
Old Amlogic TV boxes.
Modern kernel.
Modern Debian.
Raw NAND.
Old weird Wi-Fi chips.
HDMI.
 
And an owner who clearly refuses to accept the concept of planned obsolescence.
 
I originally kept these boxes because “they may be useful someday”.
 
This is usually something people say immediately before throwing something away five years later.
 
Is booting Debian 13 from its original 8 GiB raw NAND in 2026 completely unnecessary?
 
Absolutely.
Which is exactly why it had to be done.

@Hqnicolas Thanks for your inputs and guidance. Ethernet port issue got sorted out and it is working fine with 1Gbps connectivity. Also there was some issue with USB 2.0 port that got sorted now as well. I am enclosing the .dts and .dtb files for anyone having similar board. 
Note: I haven't tested the desktop version, Analog Audio port, SPIDF, WiFi Connection etc.
As of now the display is working fine, Ethernet is 1 Gbps, USB 3.0 and USB 2.0 is working fine. I will try to get the Front Side VFD working but as other experts have already mentioned it may or may not work. 
t95plus-rk3566-working.dtb t95plus-rk3566-working.dts

@sr4armbian, this DTS is from android, so you should use it as a base to create the linux DTS.
create a codex account, claude, antigravity, and setup an environment to convert it,
grab this repo, https://github.com/hqnicolas/ArmBoardBringUp
drop your android DTS file inside of it and ask your agent to create the linux version based on the repo.
if you don't like big tech sh!t just use https://opencode.ai
this repo is an overlay for armbian compiler to enable box devices to compile

@mmie4jbcu Thanks for sharing the links. The chinagadgetsreviews firmware link taking us to t95plus.com which is not responding any more. 
 
In the boxput.notation site, The first firmware link looked promising, so I downloaded it. The site didn't allow a direct file download, clicking opened raw firmware code in a new window, which I saved as an .img file. I successfully flashed the image using Factory Tool v1.72.9. The box now boots with the T95Plus logo, erases old data, and loads default apps. You are a lifesaver, you saved my cash and kept this box out of the landfill. Thanks a ton 🙏
 

 

@sr4armbian Try and see if the firmware from here works (gdrive link): https://chinagadgetsreviews.com/download-android-11-stock-firmware-for-t95-plus-tv-box-2.html
 
Edit: Also found another download link : https://boxput.notion.site/T95-Series-Fireware-0e06257cb57340dc8e75e52f8a8747cd   from here

@sr4armbian don't ask for images, you can take the dts files from other users and compile an updated image.

https://docs.armbian.com/Developer-Guide_Build-Preparation/

Yes, but now, I'm trying to make Bluetooth work and put Armbian to boot from eMMC. But I don't know exactly how to correctly submit these changes.

Hi all!
 
I'd like to share a small personal project that I've been working on recently for the Orange Pi 5 (and potentially other RK3588 boards).
Like many RK3588 users, I wanted to run Kodi on a modern mainline Linux kernel instead of relying on older vendor kernels. After a lot of testing, debugging and learning, this project started to take shape, and I've a stable almost "all works" setup
 
Tested on Armbian (minimal Debian and Ubuntu 24.04) with mainline kernel
 
Not working:
-HDR
-Maybe some network services
 
Next up:
-Wayland support
-Audio visualisers
 
 
https://github.com/Danibos/mainline-kodi-rk3588
 
A few important notes:
I'm not a kernel developer, but I have a great passion for all IT stuff, and this SBC encouraged me to dive much deeper into the Linux world. Of course this is only possible thanks to the incredible efforts from the Linux community, Collabora, LibreELEC, Armbian and many other contributors. I have mainly focused on bringing together different patches, configurations and components into a working setup for RK3588 devices, providing working .deb packages for the Kernel, FFmpeg and Kodi Piers
 
This is a personal project that I wanted to share because I know it could be really useful for many people out there. Due to my limited knowledge in this area and the little free time I have, I can't really offer it as a proper collaboration, but I'll still be happy to try to help if any issues come up. Feel free to open an issue or leave feedback!
I hope this project can be useful for other RK3588 users.
 
Thanks!
Dani

Sitrep / confirmed fix for “unhealthy: privileged” on Armbian Home Assistant Supervised
After installing Home Assistant Supervised via Armbian on an Orange Pi 4 LTS, Supervisor was blocking add-on installation with:
‘AppManager.install’ blocked from execution, system is not healthy - privileged
ha resolution info showed:
unhealthy:
privileged
unsupported:
os
However Docker itself showed the Supervisor container was already privileged:
docker inspect hassio_supervisor –format ‘{{.HostConfig.Privileged}}’
Output:
true
So the problem was not Docker missing –privileged.
The Supervisor log also showed:
Not privileged to run udev monitor!
I checked the Supervisor AppArmor profile:
sudo grep -n ‘deny network raw’ /var/lib/homeassistant/apparmor/hassio-supervisor
It returned:
8:  deny network raw,
70:    deny network raw,
Removing those deny network raw, lines from the AppArmor profile, reloading the profile, and restarting Supervisor fixed it.
Commands used:
sudo cp -a /var/lib/homeassistant/apparmor/hassio-supervisor /root/hassio-supervisor.apparmor.bak.$(date +%Y%m%d-%H%M%S)
sudo sed -i ‘/^[[:space:]]deny network raw,[[:space:]]$/d’ /var/lib/homeassistant/apparmor/hassio-supervisor
sudo apparmor_parser -r /var/lib/homeassistant/apparmor/hassio-supervisor
sudo docker restart hassio_supervisor
After restart:
ha resolution info
ha supervisor info
Now shows:
unhealthy: []
healthy: true
unsupported:
os
supported: false
I also tested the failing udev/netlink path directly:
sudo docker exec hassio_supervisor python3 -c ‘import pyudev; pyudev.Monitor.from_netlink(pyudev.Context())’
It returned silently with no error.
Conclusion: on this install, the “privileged” unhealthy state was caused by AppArmor blocking raw netlink access via deny network raw, in the hassio-supervisor profile. Docker was already privileged. Removing that AppArmor deny rule fixed Supervisor health and cleared the add-on install blocker.
The remaining unsupported: os warning is expected for Armbian/Supervised and is separate from the privileged health failure.

Created a Pull Request:
https://github.com/armbian/linux-rockchip/pull/500

Final DTB: rk3566-box-X88PRO20-npu.dtb

@Hqnicolas do you know how I can add the board as selectable from the Armbian website? Do I have to also add DTS that will work for latest kernel?
 

@sr4armbian You could try building your own X98H image and use the kernel headers from your build. Your kernel headers will be in the build/output/debs directory, and the image will be in the build/output/images directory. I would recommend starting with a fresh install with this new image and kernel headers.
 
git clone https://github.com/NickAlilovic/build.git --branch v20250306
cd build
./compile.sh
choose "Do not change kernel configuration"
choose "Show CSC/WIP/EOS/TVB"
choose "I understand and agree"
choose "X98H"
choose "edge"
rest is up to you...
 
I used this method to get my display working. But that was a while ago.
 
 

I extracted DTB/DTS from the Android FW (files attached).
 
For whatever reason they are signed in the image as rk3568. No ideas why.
02_dtbdump_rockchip,rk3568-evb.dtb 02_dtbdump_rockchip,rk3568-evb.dtb.dts
 
 
Attention: They are for Android! Linux might not boot with them!

I've created a guide here how to run a Home Assistant OS
 
suprisingly it run mostly natively. Didn't do anything except replacing the DTB. Also right away flashed it into a emmc. On my board emmc is from Samsung and has a read speed on 180Mb/s...

One interesting thing I discovered today is that you can actually boot from a flash drive, if you don't have a SD Card! In my case, I would have to buy a SD Card and had a flash drive laying around so I thought I might just give it a try, worked on an Arm Cortex-A53 CPU. I used u-boot-s905x-912 for .ext and meson-gxl-s905x-p212.dtb.

UPDATE for Multitool
 
Finally I managed to let the Opensource OP-TEE work with the rockchip miniloader!
This means that the Multitool should now work on any board, without freezes and booting issues!
 
The new version can be downloaded from the first page of this thread.
Please report if it works for you, thanks!

@sr4armbian

I know of at least 3 main issues:
no wifi
LAN is 100mbps limited
usb is 2.0 limited

Also does not look like anyone is actively developing this.

Since i use this as a server, i know that HDMI works to the point of showing the console, but i have no experience on a desktop environment.


If you dont yet have one of this devices, dont buy one to get a linux box. Not worth it.

I’ve been testing Armbian on an Amlogic-based TV box, and wanted to share a short user experience. The device originally runs Android, but thanks to the Amlogic S9xx platform, it can boot Armbian from an SD card without touching the internal firmware.
 
In my case, the system booted reliably and was usable for basic tasks like SSH access, light services, and general Linux testing. Ethernet and USB worked out of the box, while Wi-Fi and power management still required some manual tweaks, which seems common for community-supported TV boxes.
 
For reference, the hardware I used belongs to the category of Amlogic TV boxes that are widely available on the market. These devices are not officially supported by Armbian, but they can still be interesting low-cost platforms for learning, testing, or small home projects.
 
I’m curious if others here have experience with Armbian on similar Amlogic TV boxes, and which SoCs or configurations worked best for you.

ok found the issue, I got the wrong multitool image. the link on 1st post was broken returning 404 so I had to search elsewhere ended up choosing 322x folder instead of 3318. 
 
correct link to update 1st post
 
https://users.armbian.com/users.armbian.com/jock/web/rk3318/

I want to give it a try on MeCool KM6 Deluxe, just started researching. 

@mmie4jbcu Thanks for the suggestion. I am also using that file in my amlogic S905x3 tv box. unfortunately Armbian_23.02.2_Aml-s9xx-box_jammy_current_6.1.11 is no longer available from the link you posted.  so, i found it at this link https://armbian.lv.auroradev.org/archive/aml-s9xx-box/archive/

@jockNow, I've finally solved this problem. Successfully flashed the latest version of armbian, https://github.com/armbian/community/releases/download/26.2.0-trunk.151/Armbian_community_26.2.0-trunk.151_Rk3318-box_noble_current_6.12.63_gnome_ desktop.img.xz

Next, I will share my problem-solving journey. I found that I couldn't enter maskrom/loader mode anyway, and when I accidentally inserted the USB flash drive into the multitool.img into the TV box and powered it directly on, I found that it actually started the system directly in the USB flash drive. So I guess that it may have changed the boot order after flashing the loader.bin before, and the armbian system I flashed in before it continued to toss before it could be configured, probably because the system files of the root partition were corrupted, causing it to not boot normally. Therefore, I simply tried to flash the firmware of the rk3188-box in the official community directly into the USB flash drive, because after these images are flashed into the USB flash drive, there is only the root partition, that is, the system. And there is no boot partition. I guess the boot partition may have been written somewhere else, and I don't need to worry about it anymore. So, I plugged the USB flash drive into the latest rk3318 firmware into the box and waited for a few minutes after powering on it directly and starting it, it obtained the IP address assigned by my router DHCP, I was so excited, I quickly connected to the rk3318-box through SSH, and made the preliminary configuration. Quickly enter the command armbian-install and select item 2, and immediately write the system on the USB flash drive to emmc. After the writing is completed, turn it off, unplug the USB flash drive, power on, wait for a few minutes, and the startup is successful. It means that I have successfully flashed the phone this time. Thank you very much for your help. @jockand @fabiobassa, You're passionate and highly skilled.

First of all, a huge thank you for your work on bringing Armbian to RK3128 TV boxes. Your guide is incredibly detailed and practical — not just theoretically correct, but actually usable in real-world scenarios where hardware varies wildly. That’s something many tutorials lack. It’s clear you spent a lot of time testing across different boards, and it really helps people like me who are dealing with these unpredictable cheap TV boxes.
I also want to say I truly appreciate how you approached the NAND installation process using rkdeveloptool. The way you structured the workflow, especially handling boot components and low-level flashing, made it much easier to understand what’s actually happening under the hood instead of just blindly following commands.
I happen to have a bunch of RK3128 devices myself, and thanks to your work, I’ve successfully brought several of them back to life. Even with different variants of RK3128, I was able to get them running properly on NAND with kernel 4.x, which is honestly impressive given how inconsistent these boards can be.
That said, I’d like to ask if you might consider extending your approach to RK3228/RK3229 devices using rkdeveloptool on Windows, similar to what you’ve done for RK3128. I’ve been trying to replicate a similar workflow based on your guide and also by studying the multitool source, especially the step-nand function.
So far, I’ve attempted:
Reusing trust.img and legacy U-Boot from the multitool BSP folder
Manually creating a GPT at 0x8000
Writing the image with dd while skipping the first 4MB (similar to step-nand logic)
Unfortunately, none of these attempts have worked so far.
The main challenge is that many RK3229 boards don’t have an accessible SD card slot (or even pads for one), which makes recovery and testing much harder. If SD boot were available, this would be much easier to debug and iterate.
Since you’ve already done the hard work of figuring things out for RK3128 using rkdeveloptool, I was wondering if you might be willing to give RK3229 a try using a similar method. Even a partial guide or some hints about differences in bootloader layout, trust image, or NAND handling would be extremely helpful.
Thanks again for your contribution — it’s genuinely valuable for the community. Hopefully RK3229 can be the next one to crack
Cheers!

DISCLAIMERS (PLEASE READ):
- Everything in this post is provided AS-IS. This is not an official Armbian-supported target, and neither the Armbian project nor I am responsible for any damage, data loss, or broken devices caused by flashing or testing these images.
- As with other TV boxes, please assume there may be board variants, undocumented hardware changes, weak power supplies, and marginal NAND/eMMC chips. Test carefully before writing anything to internal storage.
- Please keep discussion and support in the forum thread, not in the official Armbian issue tracker.
 
Hi all,
I would like to share my work on bringing Armbian to Rockchip RK3128 TV boxes.
These boxes are quite old now, and I do not think they are especially common anymore. Still, I suspect a lot of people may have one lying around somewhere in a drawer, unused after Android updates stopped or the original firmware became too slow to care about. I also had several of them lying around at home, which is what pushed me to start this project in the first place. Since I could not find an RK3128 Armbian effort comparable to the RK322x one, I decided to try doing the port myself. Another important motivation was simply to reduce e-waste: if even some of these old boxes can be turned into usable Linux machines again instead of being thrown away, that already feels worthwhile to me.

 
First and foremost, I want to send special thanks to @jock and @fabiobassa for their RK322x TV box work on this forum. Their work was the foundation that made this RK3128 effort much easier to start from.
 
1. Main references and source code:
Blog post with the full write-up: https://chieunhatnang.de/p/building-armbian-for-rockchip-rk3128/ Follow-up post for kernel 6.6.89 work: https://chieunhatnang.de/p/building-armbian-for-rockchip-rk3128-part-2/ Build scripts and releases: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts RK3128 kernel 4.4 tree: https://github.com/chieunhatnang-personal/linux-kernel-4.4-rk3128-tvbox RK3128 kernel 6.6 tree: https://github.com/chieunhatnang-personal/linux-kernel-6.6-rk3128-tvbox  
2. Current status
At the moment I have two kernel lines:
`4.4.194`, the older vendor-based line, which is already usable in practice `6.6.89`, the newer line, which allows these boxes to run a more up-to-date Armbian userspace  
What works in the current build:
Custom U-Boot based on Rockchip U-Boot 2017.09 All four CPU cores, up to 1.2 GHz CPU frequency scaling and governors DRAM frequency control, both dynamic and fixed NAND, eMMC, SD card, and USB booting. The booting order is: USB >> SD Card >> NAND/eMMC (NAND and eMMC cannot be enabled at the same time because they share pins) OTG and EHCI/OHCI USB support Ethernet Wi-Fi support for SSV6051P, ESP8089, and several Realtek chips GPU acceleration UART1 and UART2, configurable  
Kernel `6.6.89` status in a bit more detail:
CPU DVFS is stable after replacing the inherited/leakage-based OPP assumptions with a board-specific RK3128-safe table. The stable points I ended up using are `216 / 408 / 600 / 816 / 1008 / 1200 MHz` DMC / RAM devfreq works. In practice, simply enabling `dmc` works much better than I first expected, and boards can settle at different normal rates such as `396 MHz` or `456 MHz` GPU on `6.6.89` uses `Lima`, not the old Mali blob stack. That gives a maintainable Mesa/DRM path and hardware-accelerated OpenGL ES instead of depending on a legacy userspace blob VPU/video decode is still the weak point. I tried both `RKMPP` and `Hantro/V4L2` directions, but video processing is still limited, so I do not consider this a polished media-playback setup yet  
What does not work yet / known limitations:
Bluetooth: not implemented or at least not validated, because I do not have a board with Bluetooth to test VPU / hardware video decoding is not in good shape yet SD card and SDIO Wi-Fi are currently using PIO mode on both kernel lines. This is slower than DMA, but stable enough for normal use  
 
3. Image implementation
I also made two RK3128 Armbian images based on existing RK322x Armbian images rather than building everything from scratch:
Armbian 22.02: Based on the build provided by @jock, running kernel 4.4.189 Armbian 26.02: Based on the official Armbian build for rk322x, running kernel 6.6.89  
In both cases, the idea was the same: keep the working RK322x Armbian userspace as a base, then replace the RK322x-specific parts with RK3128 ones, while the kernels themselves are based on Rockchip kernel sources.
 
Compared with the original RK322x images, the RK3128 work mainly replaces or adds:
boot.cmd / boot.scr changes so the boot flow can handle NAND and USB properly RK3128-specific Wi-Fi drivers and boot-time module loading logic rk3128-config a delayed Wi-Fi loader service RK3128-specific motd information the RK3128 kernel, DTB, and overlays  
For the `6.6.89` image specifically, there is some extra image-level cleanup and repackaging:
remove the RK322x kernel / dtb / u-boot / BSP packages from the donor image pin those RK322x packages so they do not come back on upgrade install the RK3128 `6.6.89` Debian kernel packages rebuild the BSP package under the RK3128 name  

 
4. Quick installation notes
All required files are available from the releases page:
The releaes page: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases Armbian 26.02 image: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases/download/kernel-6.6-armbian-26-v1.0/A26-release-20260415.zip Armbian 22.02 image: https://github.com/chieunhatnang-personal/RK3128-Linux-SupportingScripts/releases/download/kernel-4.4-armbian-22-v1.1/release-20260412.zip
There are three installation layouts that are currently supported:
 
1. SD card only Pros: safest option, does not touch internal storage, easy to test and easy to remove, and if a board has an SD slot it can still be useful even when NAND/eMMC is completely dead Cons: slower than internal storage, and not every board has an SD slot Best for: first boot, testing, and boards where you want to keep the original Android install untouched 2. Full install to NAND / eMMC Pros: fastest and cleanest setup, uses the internal storage already present on the board Cons: overwrites the original Android install, and old NAND/eMMC may already be unreliable Best for: boards with healthy internal storage when you want a fully self-contained install 3. Hybrid install: bootloader on NAND / eMMC, rootfs on USB or SD card Pros: usually the most practical option for old TV boxes, works well when internal storage is only reliable enough for bootloader pieces, and can also help on boxes with problematic Android boot behavior Cons: more manual than the other methods, still depends on internal storage for the bootloader, and performance depends on the USB drive or SD card used Best for: boxes with weak or aging internal NAND/eMMC, or boxes where you want to avoid a full install to internal storage
  I describe each method in more detail below.
 
4.1. Install and boot from SD card
Prepare:
idbloader.img uboot.img trust.img rootfs.img Create an MBR partition table on the SD card, leave the first 16 MB empty, create one Linux partition, then write:
idbloader.img to the raw device at seek=64 uboot.img to the raw device at seek=16384 trust.img to the raw device at seek=24576 rootfs.img to the first partition, not to the whole disk
  Example:
DEV=/dev/sdX sudo parted -s "$DEV" mklabel msdos sudo parted -s "$DEV" mkpart primary ext4 16MB 100% sudo partprobe "$DEV" sudo dd if=idbloader.img of="$DEV" seek=64 conv=fsync sudo dd if=uboot.img of="$DEV" seek=16384 conv=fsync sudo dd if=trust.img of="$DEV" seek=24576 conv=fsync sudo dd if=rootfs.img of="${DEV}1" bs=4M status=progress conv=fsync sync I also provide a bootcardmaker.sh helper script in the same release directory to simplify this process.
 
4. 2. Full install to NAND / eMMC
Prepare:
rkxx_loader_vx.xx.xxx.bin parameter.txt uboot.img trust.img rootfs.img  
Then:
Boot the board normally Connect a USB cable to the OTG port Open RKDevTool v2.69 In Advanced Function, erase the first 0x10000 sectors with Start LBA = 0x0 and Count = 0x10000 Press ResetDevice Wait for the board to return in MaskROM mode Go to Download Image Flash Loader, parameter, U-Boot, Trust, and rootfs  

 
4. 3. Hybrid install: bootloader on NAND / eMMC, rootfs on USB or SD card
This is the layout I use most often, and in practice it is probably the most useful one for old TV boxes.
It is especially useful when internal NAND/eMMC is still good enough for Loader / parameter / U-Boot / Trust, but not reliable enough for a full root filesystem. A common symptom on these old boxes is that Android starts to boot and then hangs, or that the internal storage is simply too unreliable to trust with a full install.
In this hybrid layout:
Internal NAND/eMMC stores Loader, parameter, U-Boot, and Trust The root filesystem lives on USB or SD card Important:
rootfs.img is a filesystem image, not a full disk image Write rootfs.img to a partition such as /dev/sdX1, not to the whole device Tools like BalenaEtcher are the wrong fit for this particular image layout Example:
sudo dd if=rootfs.img of=/dev/sdX1 bs=4M status=progress conv=fsync sync  
4.4. Post-install configuration
After the board boots successfully, you can configure it either from the local console over HDMI or remotely over SSH if Ethernet is connected.
Default login:
user: root password: 1234 The first login will ask you to change the password.
 
After that, run:
rk3128-config This is the board-specific configuration tool for enabling and adjusting hardware features that may differ between RK3128 boxes.
The most important options are:
Wi-Fi chip selection RAM dynamic frequency: disabled by default. Enabling it can improve performance, but on some boards it may cause kernel hangs. If that happens, switch it back to disabled SD card storage enablement when booting from another device Display resolution OTG mode selection  
5. Testing feedback is welcome
If anyone here has RK3128 boards and wants to test, feedback would be very useful, especially for:
Board photos and PCB markings Whether the board uses NAND or eMMC Boot method that works: SD, USB, NAND, eMMC Which Wi-Fi chip is present Serial logs, dmesg, and failure reports If there is enough interest and enough board coverage, I would be happy to keep improving this, cleaning it up further, and making it easier for other people to test.
 
6. Credits
- @jock and @fabiobassa for the RK322x TV box work on the Armbian forum, which provided the main starting point, the images and practical reference for this RK3128 effort
- Rockchip for the original kernel code base used as the foundation for both kernel lines
 

Continuing to dig into this. Updated the Armbian images - available via the same links above (md5sum mismatch):
 
How to add the module to an already working system (so you don't have to reinstall from scratch):
1. Download the archive ws2801-1.0.tar.gz with the dkms source code for the ws2801 module.
2. Extract the source folder to /usr/src/ :
sudo tar -xzvf ~/ws2801-1.0.tar.gz -C /usr/src/ (here ~/ is the /home directory of my user)
3. Install the module step-by-step via dkms:
sudo dkms add ws2801/1.0 sudo dkms build ws2801/1.0 sudo dkms install ws2801/1.0 4. To avoid rebooting, you can load the module immediately:
sudo modprobe ws2801  
By default, Red should start blinking as a "heartbeat" trigger.
 
Description of dts and demo:
 
 

my Rupa 88 Pro 20, wifi/bt chip is cdtech 208821c (rtl8821cs), with real 4g32 had no bluetooth with mmie4jbcu's dtb or the included box-demo.dtb. with a lil help from claude.ai, i mix mmie4jbcu's dtb with x96x6.dtb from another thread here. et voilá bluetooth is working after  
apt install armbian-firmware-full rk3566-box-X88PRO20.dtb