eloirotava

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.

now working with:
Download: 8.06 Mbit/s
Upload: 10.08 Mbit/s
 
in kernel 7. https://github.com/eloirotava/6051
testes on s90w amlogic.
also work with 6030p rockchip.

now working with:
Download: 8.06 Mbit/s
Upload: 10.08 Mbit/s
 
in kernel 7. https://github.com/eloirotava/6051
testes on s90w amlogic.
also work with 6030p rockchip.

Hey guys and @jock. Thanks for the references.
 
not very fast, but stable and working on a s905w. (guess to be a tx3 mini, but who knows...)
 
kernel 6.18.10 and ssv6051p. 
 
Linux aml-s9xx-box 6.18.10-current-meson64 #3 SMP PREEMPT Wed Feb 11 12:42:01 UTC 2026 aarch64 GNU/Linux
 
with speedtest-cli
Download: 3.43 Mbit/s
Upload: 1.55 Mbit/s
yeah, slow. but stable... i guess
 
dmesg
[   11.938463] SSV WLAN driver ssv6200: chip id: RSV6200A0-201311, tag: 2014012420010960
[   12.006600] SSV WLAN driver ssv6200: attempt to load firmware ssv6051-sw.bin
[   12.021645] SSV WLAN driver ssv6200: firmware upload complete (wrote 80 blocks, verified 80 blocks)
[   12.138546] SSV WLAN driver ssv6200: Firmware version 16380
[   12.141013] SSV WLAN driver ssv6200: Calibration successful
 
https://github.com/eloirotava/6051
 
the repo has also the rtl8188fu driver to the same soc/kernel. it is better than the ssv for sure...
 
The trick was tuning the ssv6051-wifi.cfg to disableHT/AMPDU that usually kill the SDIO bus on these SOCs.
 
 

after some research i have (finally) found the original archives form balbes. they can also been burn to the internal eemc. with some work you can run bookworm with kernel 3.10.99 (dont ask why) from the internal storage...
https://archive.org/details/amlogic-s805-linux
tks for 0jw4tts witch uploaded those files to archive.og !!!