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.

driver for sv6051p working in kernel 7 @Qvy: https://github.com/eloirotava/6051 horray!

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.

Nice @Kevin su. my results with the eth0 working was similar to yours. but after an "ip link set down dev eth0" got those lower. whatever. Its alive after all!

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 !!!

It looks like the issue is likely related to display resolution settings if you can see the initial boot text but get a black screen with "no signal" once the GUI loads. Try the following steps: Switch to a TTY session If the system is running but the display is not working, press Ctrl + Alt + F1 (or F2, F3, etc.) to access a terminal. Check the current display settings If you can log in via SSH or TTY, try running: "xrandr" This will list the available resolutions. If the default resolution is not supported by your LCD panel, you may need to adjust it manually.

On a headless machine, I use Xvfb (a virtual display server) and x11vnc to enable remote access. Here's what works for me: Xvfb :1 -screen 0 1280x720x16 & DISPLAY=:1 startx & x11vnc -display :1 -rfbport 5900 -forever & Make sure you have Xvfb and x11vnc installed! Xvfb :1 -screen 0 1280x720x16 → Starts a virtual display at :1 with a resolution of 1280x720 and 16-bit color depth. DISPLAY=:1 startx → Starts the X session using the virtual display. x11vnc -display :1 -rfbport 5900 -forever → Starts the VNC server on display :1, keeping the session active after disconnects.

Hi! You should use netmask 255.255.255.0 instead of subnetmask. If NetworkManager is managing your interfaces, it might override manual settings. Try disabling it or configuring the static IP within nmcli. Let me know if you need more help! Thanks, Eloi.