Active threads

Yes. Please wait. I was busy with other personal projects, so I haven't been doing armbian stuff for a few weeks.

I don't know what you could improve right now... But I know that LCD only receives data. My LCD works the same, with its MISO pin connected or disconnected.

According to your serial log, the name of the dtb file is "rk-kernel.dtb". You should find that file somewhere below /boot/dtb/ . You can simply copy that from your running system (e.g. using "scp"). But if you want to extract it from an image, you can use e.g. "kpartx -av YOURIMAGE.img" to create loop devices ("/dev/mapper/loop*") for each contained partition, which you can then mount as usual. Too sad that ctrl+c does not seem to work. Did you try having "ctrl+c" already pressed before powering up the board - and keeping it pressed, while it boots? There's also a chance that the board will accidentally boot from the usb-drive, if it contains the same image as the emmc (i.e. the partition UUIDs need to be identical). It happened to me in about 1 out of 3-5 attempts. Described here.

I bricked my original H96MAX TV box while tinkering with it, so I bought a new one. The new unit works fine with both wireless and wired networks on Android, but after flashing the firmware Armbian_26.2.0-trunk.302_H96-tvbox-3566_forky_current_6.18.6_minimal.img, the wired network stops working and only the wireless network is functional. Please help me fix this issue, thank you!

Try this. It worked on radxa-e54c with Cinnamon. rm -rf ~/.local/share/cinnamon && sudo reboot

@Nick A Since both the A7a and A7z have the same CPU family, I made a build using the exact same options, but selecting the A7a instead in the compile menu. This build did start to boot, I saw the Radxa logo, then some Linux console boot messages (but it was scrambled on the screen a bit), and lastly I saw the Armbian logo and the spinning circle. Eventually that all went away and the screen was just empty. No response from key presses, etc., but my HDMI screen was still getting signal, it was just blank. I also tested different distros and versions available to see if that made any difference (ex. debian vs ubuntu, nodel vs plucky vs bookworm; etc...), non of that had any effect. So it appears, at a first start, to be a A7a vs A7z build difference to at least get an attempt at boot. Then the next issue is that it never fully reaches a usable OS console. Thanks!

Mhhh..... Image for OrangePi 3b works out of the box (and it's also possible to install to the eMMC), but it doesn't seem to support some features (i.e. there are no devices like "/dev/video*", "/dev/rknpu", etc.). Otherwise the images for BananaPI CM4 doesn't seem even to boot on OrangePI CM4: comparing both images, those are indeed different (i.e. "initrd.img", "vmlinuz", etc. are under "/boot" folder rather than in "/"). Dies anyone knows a simple way to burn BananaPI CM4 images (or another image) to OrangePI CM4 (to SD Card or better to eMMC)? Regards,

If you mean the built-in script as described in the instructions linked to from the download page (https://www.armbian.com/amlogic-s9xx-tv-box) Then yes that should do everything you need.

@SteeMan - there is no pressure to do it quickly or at all ... if you should look at it and have questions, just ask me here (i'm reading here regularly, but sometimes with a few days delay) or create an issue in my github repo. i'm always happy to see that you are keeping the amlogic boxes stuff alive pretty well in armbian.

Can't you run on sdcard? It is heavily suggested to run on sdcard before installing on emmc. However the overlay is emmc-pins

Yes. Probably this week.

You can switch to beta to get faster updates, though they're untested autobuilds, so if something breaks, you have to unbrick yourself.

The Evolution of SBCs: From Hobby Boards to Edge ComputingOver the past two decades, single-board computers (SBCs) have transformed from experimental maker tools into the backbone of modern embedded and edge systems. What started as a handful of affordable hobby boards has grown into a diverse ecosystem powering automation, AI, and connected infrastructure around the world. From Prototypes to PossibilityEarly SBCs were humble experiments — small circuit boards combining processor, memory, and I/O on one platform. For years they lived quietly inside industrial machines and educational kits. The real turning point came in the early 2010s with boards like the Raspberry Pi, BeagleBone, and Cubieboard, which brought Linux to the maker community at a scale and price that anyone could access. These boards opened the floodgates for innovation. Suddenly, home labs, classrooms, and startups could prototype full Linux systems for the cost of a dinner. The appeal wasn’t just price — it was openness, GPIO access, and a thriving community that treated hardware as something to explore, not just consume. The Rise of a Global EcosystemAs demand grew, more vendors entered the field: Orange Pi, FriendlyElec, Radxa, and dozens of others expanded on the idea, each offering faster SoCs, more memory, and better I/O. Modern SBCs can now host NVMe storage, multiple displays, gigabit networking, and dedicated NPUs for AI workloads — features once reserved for full desktops or servers. They power digital signage, smart gateways, home servers, and even small AI clusters. Developers began caring not just about hardware specs, but also kernel stability, upstream drivers, and long-term support — exactly where Armbian excels. What’s NextLooking ahead, the direction is clear: AI acceleration everywhere – NPUs and neural engines are becoming standard on SBCs.Unified software stacks – Containers, orchestration tools, and reproducible builds are reaching the edge.Energy-aware computing – Solar and battery-powered deployments highlight the need for lean, resilient systems.Armbian’s role in this landscape is to provide the stable software foundation that ties it all together — open, optimized, and reliable across dozens of architectures. In SummarySBCs have grown up. They are no longer just learning tools or proof-of-concept boards — they are the quiet engines running modern infrastructure at the edge. Armbian sits at the heart of that transformation, helping these devices boot faster, run cleaner, and stay useful long after their first flash. The evolution of the SBC mirrors the story of open computing itself: innovation born from community effort, refined through shared knowledge, and extended by software that stays light enough to go anywhere. View the full article

@quaSimba: Fantastic work! Will put a link at the top of the tutorial for visibility.

Armbian recently merged and will be releasing (and backporting) a patched devicetree file for the Odroid C4 and HC4 that eliminates the second power-cycle "glitch" during boot. Hopefully this will fix at least one issue people have been reporting, where some HDDs (or other devices) do not react well to rapid power double-tap during boot. https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch It will also be released (and likely backported) upstream in next Linux kernel release and/or fixes. Also, something else people have been reporting is the HC4 struggling to spin up two large HDDs at the same time. If you have an HDD with a "Power Up In Standby" (PUIS) setting, such as the Seagate IronWolf, then you can configure all non-system (non-boot) drives in this manner, and then mount and access them sequentially after the system has booted. Depending on how much power the HDDs use in regular operation, this might work to get both spun up and running. Theoretically, you could also access just one drive at a time and then place it back in standby before using the other drive. YMMV.

@kil I also own a T95H and playing around with that now. Would it be possible getting your final dts, dtb and .config for u-boot? Thanks in advance & best regards

Hi, I could try to help, my board is exactly the same as yours. Can you provide me a source with instructions of how to do that?

Hello, I am facing an issue with my Youyeetoo YY3568 board. After that, I attempted to flash my own Yocto (Radxa manifest–based) wic image for the YY3568 using RKDevTool on Windows, but the flashing did not complete successfully. Since then, the board is always detected in Maskrom mode and never switches back to Loader mode. What I have tried so far: 1- Flashed prebuilt Ubuntu image (YY3568_Ubuntu_EDP.img) from the official link: https://drive.google.com/drive/folders/1D90vztL9fRfWV7laV9mdcnZ5kNpxx_tl → Board still shows Maskrom mode after flashing. 2- Flashed SDK-based image and loader built using the official documentation: https://wiki.youyeetoo.com/en/YY3568/ubuntu → Board remains in Maskrom mode. I have tried flashing from both Windows (RKDevTool) and Linux (rkdeveloptool), but the board is consistently detected in Maskrom mode. Question: How can I recover the board from Maskrom mode and bring it back into Loader mode, so that I can flash images and make the board operational again? Any guidance would be appreciated. Thank you.

psst, I ordered a board, hopefully I've time and may get it going it takes a lot of *work* to even get it working and with more often than not , no (scant) documentation (e.g. missing dram controller docs ) / codes to even get it working. btw it is good for those who wish to have board support to donate in support of armbian in support of it, it is probably the only sustainable way to do so.

Should be there. https://github.com/armbian/build/blob/00b6e17abfd859893a39f6445715a3327fed150a/config/kernel/linux-meson64-edge.config#L355 https://cateee.net/lkddb/web-lkddb/IP_NF_IPTABLES.html

thank you. I'l give that a try when I wake again.

http://blog.armbian.com/content/images/2026/01/githubhighlights-2.png This week’s Armbian development saw a major cleanup of legacy toolchain code, alongside numerous board-specific improvements and kernel updates. Support was added for the Nuvoton MA35D1 NuMaker IoT board, while the BananaPi CM4/M2S and Khadas VIM3L boards received updated U-Boot bootloaders. Several fixes addressed hardware compatibility, including Bluetooth on Orange Pi Zero2, Type-C issues on Helios64, and build stability for the Raspberry Pi 4B. The release also introduced enhanced audio support for Genio devices and new AV1 patches for Rockchip64. Continuous integration workflows were reorganized, and the Ubuntu Resolute image build was enabled, reflecting ongoing efforts to streamline and modernize the Armbian build system. "get completely rid of dead code toolchain stuff", pt2. by @rpardini in armbian/build#9218"get completely rid of dead code toolchain stuff", pt3. by @rpardini in armbian/build#9252"get completely rid of dead code toolchain stuff", pt4 - fixes. by @rpardini in armbian/build#9256Add post-build Armbian extension for burnable JetHub boards. by @QwaSeeK in armbian/build#8844BananaPi CM4/M2S: Update u-boot to v2026.01. by @pyavitz in armbian/build#9250board: add Nuvoton MA35D1 NuMaker IoT board support. by @TuAFBogey in armbian/build#9205bunch o' fixes: 6.18/current .configs (uefi-all/meson64) + boards KERNEL_TARGET + meson64 6.18 pcie debork again-again. by @rpardini in armbian/build#9247ci: organize GitHub Actions into meaningful categories. by @igorpecovnik in armbian/build#9260Enable Ubuntu Resolute image build. by @iav in armbian/build#9164Fix OP-TEE build on Ubuntu Jammy (older binutils). by @TuAFBogey in armbian/build#9249Fix Panther-X2. by @sicXnull in armbian/build#9243Fix typec on pinebook pro. by @amazingfate in armbian/build#9245genio: add alsa-ucm-conf + ucm2 config for working audio in userspace. by @rpardini in armbian/build#9235genio: collabora: bump to collabora's 6.19-rc5. by @rpardini in armbian/build#9251Helios64: fix Type-C PHY registration. by @iav in armbian/build#9158khadas-vim3l: u-boot: update v2026.01 u-boot fanciness. by @rpardini in armbian/build#9257mainline: bump edge to rc5. by @EvilOlaf in armbian/build#9244Meson64: Delete patches that are not required. by @pyavitz in armbian/build#9239meson64: remove upstreamed patch for 6.18.6 and rewrite the rest. by @EvilOlaf in armbian/build#9266mixtile-core3588e: alias ethernet0 to gmac0 for stable MAC address. by @rpardini in armbian/build#9237orangepizero2: fix bluetooth in edge kernel. by @EvilOlaf in armbian/build#9242radxa-zero2: fancy u-boot v2026.01 // minimal+full fusb302 enablement. by @rpardini in armbian/build#9253rockchip64-6.19: arm64: dts: rockchip: describe pcie ethernets on FriendlyElec NanoPC-T6. by @rpardini in armbian/build#9238Rockchip64: Add verisilion av1 patches. by @amazingfate in armbian/build#9240rockchip64: Helios64: fix Type-C PD negotiation. by @iav in armbian/build#9255rpi4b: fix build and boot issues. by @EvilOlaf in armbian/build#9267sunxi-current: recover lost Makefile entries. by @EvilOlaf in armbian/build#9236sunxi: bump current and edge to latest minor. by @EvilOlaf in armbian/build#9229sunxi: resolve some cross patch dependencies. by @EvilOlaf in armbian/build#9232sunxi: switch current and edge back to auto bumping. by @EvilOlaf in armbian/build#9234u-boot: run binwalk on all the produced u-boot bins (always). by @rpardini in armbian/build#9192Update jethome j200 kernel patchset, uboot to 2025.04. by @adeepn in armbian/build#9231View the full article

Hi @ff255, There is an effort to add this calculation in the U-Boot bootscript. I'll have a look at doing this during updates to initramfs or kernel, good suggestion! Groetjes,

Thank you very much! Regards, Chris

update on this. I did try to install Helium/Helium Miner and it does not work. ill work on the devicetree to get that functionality present but for now be warned.