May 26, 20251 yr If the desired image combination is not available DIY. That's the build framework made for https://github.com/armbian/build/
September 14, 20251 yr @Dominik Wójt Hey, I've picked up my mxq box again looking to put a newer OS on it. It seems the image you provided works with HDMI. Thanks! However, if I build it from the normal armbian repo it does not work. Any chance you can share what changes you made?
October 2, 20251 yr Hi @Fiery_Fire, all the changes I used have been merged to armbian. I tried to build an image from the current main branch and I got no HDMI output too. I tried a newer kernel and applied all the patches from xdarklight's branch https://github.com/xdarklight/linux/tree/meson-mx-integration-6.15-20250608, here is an armbian branch: https://github.com/domin144/armbian-build/tree/meson_6.16 I compiled with this command: ./compile.sh build BOARD=aml-s805-mxq BRANCH=edge BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED= DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=no RELEASE=trixie Now I get some output on HDMI, but it is so distorted, I cannot read any text. Something must have been changed in the 6.12 kernel between the time I tried it last and now. Unfortunately I will not have time to debug this in a foreseeable future. Hopefully this distorted output will be a better starting point for you than no output at all.
October 3, 20251 yr Hi @Dominik Wójt, Thank you for your time looking into this. I was really stuck in a loop looking for solutions and this is the conclusion I also came to: The issue is with the kernel, not with DTBs, config, distro, monitor or anything else. I got the output to work on a regular image by installing "linux-image-edge-meson" but still no access to NAND and the device does not run smoothly. Best experience I've had was with an old image with kernel 3.10.108 which had everything working and running smoothly. I would like to try these patches you mentioned but unfortunately I don't have the knowledge on how to do so, then how to put this into armbian during the build process... I've now given up on this. Installed LibreELEC with and old kernel and donated the box away. Though I want to thank you again for your suggestions and for your help.
March 23Mar 23 Hi, i have amlogic s805 tv box from mxq, how do i run armbian onecloud? bc none of this helped me.
September 22Sep 22 Working setup: BTV B8 (S805) with Armbian Onecloud bookworm, kernel 6.12, persistent SD boot Sharing what worked on my box, in case it helps someone with a similar S805 board. Thanks to hzyitc for the Onecloud builds and to everyone in this thread whose posts pointed me in the right direction. Hardware Box: BTV B8 (Brazilian brand) Board: A80_V2.0, dated 2017.02.15 SoC: Amlogic S805, 4x Cortex-A5 up to 1.54 GHz, Mali-450 MP RAM: 1 GB DDR3 (2x SK hynix H5TC4G63AFR) Storage: 8 GB eMMC (Samsung KLM8G1WEPD-B031) Ethernet: 10/100 (PPT PM44-11BP magnetics) Wi-Fi: Realtek module, probably RTL8189ETV (not tested) microSD slot, and labeled UART pads on the board (GND, TX, RX, 3V3) Stock firmware: Android 4.4, recovery build KOT49H.20170825 Image used From the hzyitc/armbian-onecloud GitHub releases (tag ci-20250823-102917-UTC): Armbian-unofficial_25.11.0-trunk_Onecloud_bookworm_current_6.12.43_minimal.img.xz Use the plain .img.xz. The .burn.img.xz files are for the USB Burning Tool and write to internal storage with the Onecloud bootloader, which can brick a different board. The boot problem The stock u-boot ignores the SD card. Holding the update button (under box) only boots into Android recovery, because the Onecloud image has no aml_autoscript. The fix was a set of small u-boot scripts placed on the BOOT partition (attached, compiled and as .cmd source): s805_autoscript: loads /uImage, /uInitrd and /dtb/meson8b-mxq.dtb from the SD card and boots. Runs on every boot. aml_autoscript: runs once via the update button. It saves the original bootcmd into bootcmd_orig, sets bootcmd to try the SD card first and fall back to the original, runs saveenv, then boots from SD. restaurar: restore script. It puts the original bootcmd back. Boot script (s805_autoscript.cmd😞 setenv bootargs "root=LABEL=armbi_root rootwait rw rootfstype=ext4 console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 net.ifnames=0" fatload mmc 0 0x14000000 /uImage || exit 1 fatload mmc 0 0x15000000 /uInitrd || exit 1 if fatload mmc 0 0x11800000 /dtb.img; then echo "using /dtb.img"; else fatload mmc 0 0x11800000 /dtb/meson8b-mxq.dtb || exit 1; fi bootm 0x14000000 0x15000000 0x11800000 Persistent setup (aml_autoscript.cmd😞 if test -n "${bootcmd_orig}"; then echo "original already saved"; else setenv bootcmd_orig "${bootcmd}"; fi setenv sdboot 'if mmcinfo; then if fatload mmc 0 0x11000000 /s805_autoscript; then autoscr 0x11000000; fi; fi' setenv bootcmd 'run sdboot; run bootcmd_orig' saveenv run sdboot To use a different dtb, copy it to the root of the BOOT partition and rename it to dtb.img. The script picks it up automatically. Steps Flash the image to a microSD card with balenaEtcher. Copy s805_autoscript, aml_autoscript and restaurar to the root of the BOOT partition (armbi_boot). Connect Ethernet, insert the card, hold the update button, plug in the power and keep holding for 10 to 15 seconds. Wait about 3 minutes (the first boot is slow), find the IP on your router and log in with ssh root@IP, password 1234. From then on, the box boots from SD by itself, even after a power loss. Without the card, it boots Android as usual. To undo: delete aml_autoscript from the card, rename restaurar to aml_autoscript and boot once with the update button. Status Working: Ethernet, 1 GB RAM detected, root filesystem on SD, SSH, CPU temperature reading (around 47 °C idle). Kernel reports 6.12.43-current-meson, model TRONFY MXQ S805. HDMI: not tested. I run it headless over SSH only. Wi-Fi: not tested. eMMC: not detected under Linux with the MXQ dtb (no mmcblk1), so Android stays untouched. Recommended after first login Hold the kernel packages, since a kernel update could change the files the boot script loads: apt-mark hold $(dpkg -l | awk '/linux-(image|dtb|u-boot)/{print $2}') Also keep /etc/netplan/20-eth-fixed-mac.yaml. Armbian creates it to fix the MAC address, since this board has no fixed one. Without it, the MAC changes on each boot and DHCP reservations break. The box has been running Pi-hole and Tailscale (subnet router) without issues. armbi_boot btv8.zip Edited September 22Sep 22 by ERIS
September 22Sep 22 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.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.