Active threads

Oh, I do not have a nanopi r3s, and I do not plan to buy it. The image is for the radxa zero 3w, but as I provided the source of building it, you can customize it to build with nanopi, too. The reason I mentioned nanopi r3s is because it has a dedicated case for it. I ended up using raspberry pi zero case for it, with some custom modifications. Sorry, Raspberry Pi 1/2/3, zero/zero w/zero w2 won't work, because they only have 1 USB controller. The trick here is to have at least 2 USB controllers: 1 in host mode to connect to the UAC2.0 speakers, and 1 in gadget mode as a UAC1.0 USB device. Raspberry Pi 4/5 should work, but you need to make sure the power supply is strong enough, which is a big issue here, because with the official image, you can only connect the USB C port for power and as a USB gadget port, yet PS5 probably won't support that much power for RPi 4/5, so you ended up needing a USB power and data splitter for that, and connect the data port to PS5, then a separate power supply for the power port.

I am working on a new version of the Luckfox Core3566 Board and Patches, as well as adding the Orange PI CM4 board to Armbian. Both rely on the Rockchip RK3566. Luckfox Core3566 Starting with the Core3566: The current board is just the vendor u-boot and kernel. It lacks PCIe support, but surely it is helpful to be as near to manufacturer configuration in their patches. My board config on the other side is not supporting the vendor specific patches, but based on a clean u-boot v2025.10 and runs nicely with current and edge kernels and also runs smoothly with nvme storage. The luckfox-core3566 config is currently maintainerless, but maybe users would like to have this vendor kernel version. My question: 1) Would the Armbian rather like to replace the vendor board config with a more future proof board config like mine or 2) Keep both board versions ( like rename config/boards/luckfox-core3566.csc to config/boards/luckfox-core3566_vendor.csc ) and let my variant replace the config/boards/luckfox-core3566.csc as default? 3)rd option would be combine both configs, but I had struggle to do so, as my version is using a different u-boot, using a simplified partition setup etc. Orange Pi cm4 I created a new board configuration to let Orange PI CM4 to work with Armbian as well. It is pretty similar to the bigtreetech cb2, but it's ethernet wiring and pcie powering device config differs from latter. Is it okay to create a MR directly in Github or does it need alignment with Moderators first? Cheers, Daniel PS: Nice to have time to work on embedded arm systems again. I did work on the sunxi based cubieboard and cubietruck back in the days, but job, family and basically life pulled me away from it for such a long time.

I'll buy a new USB cable today and try connecting via ADB again. I can't even find the original firmware for this console. It seems like a trivial task to restore build.prop, but it's already driving me crazy. It won't connect via ADB, I can't find the firmware for this device, and it doesn't see the internal memory via Multitool. I'm at a dead end.

Feel free to reach out and become a partner: https://www.armbian.com/partners/

Hello using an inovato quadra and would like it to start a specific program on boot how do I go about doing such a thing Pointer or instructions appreciated Thank you Jacques

Hello @Malay! No need to raise your voice. Anyhow - thanks for the feedback. The missing HDMI audio has a deeper reason: the communication with the Realtime-CPUs does not work. Background: HDMI audio needs a special DMA: adma, that in turn is supported by the rCPUs (the extra Cores running the real-time-OS from esos.elf) and that does not communicate correctly via rpmsg currently. Not sure why and also not sure if this is true with the other RiscV/Spacemit boards. The 2280 M.2 slot works, I am pretty sure. If you need a running Armbian *with* HDMI audio, grab the orangepi-rv2-ky branch from my repo. It's older and I use it to compare working vs. non-working currently. Also, there's a reason this has no pull request to Armbian/main: it's work-in-progress. LG // Sven-Ola

LMAO! So... What exactly is your question? Did you try "the mouse & keyboard" and they did not work? I would say you will get basic functionality on almost any usb mouse or keyboard on linux. wifi on the other hand can be a hit or miss. A quick search on "USB Logitech Unifier Nano dongle" gave me this: https://forums.linuxmint.com/viewtopic.php?t=373365 so it seems you might want to use solaar to configure the stuff. As for the Inovato Quadra4K, it looks like it is an allwinner H6 processor so I suspect it should work using armbian....

@Bones558 I think the LED is always on by default and doesn't blink. You can try kernel 5.15, I'm using Armbian-unofficial_25.11.0-trunk_Radxa-cubie-a7z_jammy_legacy_5.15.147.img Since I don't have any TTL modules or display adapters, I directly followed the instructions at https://docs.armbian.com/User-Guide_Autoconfig/ to set up the wireless network. After powering it on and waiting for a while, I could directly access SSH. Hope this helps.

Hi, I'm a long time Armbian user and overall extremely happy. It my default Linux distro everywhere! Thanks to everyone who is developing or contributing to it! Every time I pickup a new board and deploy Armbian I have to edit the `armbianEnv.txt` file and change verbosity to 7. The same question repeats in my head. Why is it not the default? Systemd and startup messages spam up like crazy and they have nothing interesting to offer. I do care what hardware did the kernel detect or was a protocol correctly negotiated etc. I personally would have it in reverse, verbose kernel, quiet systemd. But thats just me. Could we at least have parity, if systemd verbose then make kernel verbose too, if kernel quiet then systemd quiet too. I'm trying to understand what was the rationale for having quiet kernel and verbose systemd? Thanks!!

https://docs.armbian.com/Developer-Guide_Build-Switches/ Check for ARTIFACT_IGNORE_CACHE diy packages are locally cached. automated packages from the CI are stored online in ghcr. not only this, also the status of build framework internals (like stuff in https://github.com/armbian/build/tree/main/lib/functions) since they also can alter a package. "development" should be sufficient.

Build from branch v20250306. error! [ Failed to fetch SHA1 of 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git' 'tag' 'v6.12.11' - make sure it's correct ] How to remove the error?

Does anyone here may have recommendations of standard sdcard or flashdrive that supports for installation on amlogic s905x devices? eg: sdcard only sdhc types or it will work with sdxc or any kind of limitations capacities for certain SBC ? . thank you in advance for your most kind replies. best regards

Hi Lessard can you please check this error (X88 PRO-B-RK3318-D4-V1.6)? root@GREEN:~/tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI -include /root/tm16xx-display/drivers/auxdisplay/tm16xx_compat.h -I/root/tm16xx-display/include/" -C /lib/modules/6.18.6-current-rockchip64/build M=/root/tm16xx-display/drivers/auxdisplay CONFIG_TM16XX=m CONFIG_TM16XX_KEYPAD=y CONFIG_TM16XX_I2C=m CONFIG_TM16XX_SPI=m CONFIG_LINEDISP=m modules make[1]: Entering directory '/usr/src/linux-headers-6.18.6-current-rockchip64' make[2]: Entering directory '/root/tm16xx-display/drivers/auxdisplay' CC [M] line-display.o CC [M] tm16xx_core.o CC [M] tm16xx_keypad.o tm16xx_keypad.c:81:6: error: redefinition of ‘tm16xx_set_key’ 81 | void tm16xx_set_key(const struct tm16xx_display *display, const int row, | ^~~~~~~~~~~~~~ In file included from tm16xx_keypad.c:18: tm16xx.h:189:20: note: previous definition of ‘tm16xx_set_key’ with type ‘void(const struct tm16xx_display *, const int, const int, const bool)’ {aka ‘void(const struct tm16xx_display *, const int, const int, const _Bool)’} 189 | static inline void tm16xx_set_key(const struct tm16xx_display *display, | ^~~~~~~~~~~~~~ tm16xx_keypad.c:135:5: error: redefinition of ‘tm16xx_keypad_probe’ 135 | int tm16xx_keypad_probe(struct tm16xx_display *display) | ^~~~~~~~~~~~~~~~~~~ tm16xx.h:184:19: note: previous definition of ‘tm16xx_keypad_probe’ with type ‘int(struct tm16xx_display *)’ 184 | static inline int tm16xx_keypad_probe(struct tm16xx_display *display) | ^~~~~~~~~~~~~~~~~~~ make[4]: *** [/usr/src/linux-headers-6.18.6-current-rockchip64/scripts/Makefile.build:290: tm16xx_keypad.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.18.6-current-rockchip64/Makefile:2010: .] Error 2 make[2]: *** [/usr/src/linux-headers-6.18.6-current-rockchip64/Makefile:248: __sub-make] Error 2 make[2]: Leaving directory '/root/tm16xx-display/drivers/auxdisplay' make[1]: *** [Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.18.6-current-rockchip64' make: *** [Makefile:50: module] Error 2 Thank you

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

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.

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.