Active threads

That the Helios64 SW/firmware did sequencing of 3.5inch HDD spin-up is indeed a good method to limit the maximum current draw. I do not know how power architecture is done in Helios64, but w.r.t. 3.5inch disks, so the 12V power need, you might avoid letting the current of the 12V flow through the SBC/motherboard. It is not needed, there might be connectors, still it is not needed. Even for traditional x86 PCs, 12V (and 5V as well) comes straight from the PSU, that is 100-1000W or so usually. The 12V also does not need to be exactly 12V, I feed a 4TB WD HDD from a 12V car battery in the field, is solar powered and 10 years old or so. Due to battery wear out, it sees a voltage of 10.5-14 Volts or so. No problem. 5V for SBC and some other small stuff is via a 3A DC/DC module. A car battery (72Ah or so) should have no issue with spinning up a handfull of 3.5inch HDDs simultaneously. The PCIe-to-SATA chips support hotplug, so you could use some P-MOSFETs or so to have GPIO-controlled powerswitch, but is of course electronics circuit design and soldering etc. Also maybe think if you need all that 5 HDDs (and at the same time) and with a RK3588 SoCo that can go as low as 1.5Watt idle. 5 spinning disks is 20W or so.

@Nick A, @MeJune Luckly. On this thread: https://forum.manjaro.org/t/allwinner-h728-a523-a527-t527-initial-support-thread/173654/2 He working for a year to make the linux working stable on this box. This mean kernel, dtb, ... can be replace on armbian build. I super need new image for web-service hosting purpose. Hope all function working.

My NanoPi-R6C came with FriendlyWRT pre-installed (OpenWRT variant) and I bought it 2 years ago partly also because I had a Samsumg 970 Evo NVME that needed a computer wrapped around it. I do not use images, instead root-filesystems (Btrfs). I Initially kept the FriendlyElec U-Boot, with all rest on NVME. Now still use the same principle, but EDK2-UEFI v1.1 as bootloader in eMMC and Armbian Trixie or Opensuse Tumbleweed with Armbian kernel and grub-efi. With latest u-boot (2026 rc2) I get no HDMI audio. I thought it was a power/reset issue, but also later tested again with complete un-powering first, but then also no HDMI audio. It might simply be a latency issue. Both older U-Boot and even much older FriendlyElec U-Boot as well as EDK2-UEFI initialize HDMI before the kernel and do simple 1080p60, so you also see the kernel being loaded, before KMS (re)-inits the HDMI. EDK2-UEFI has GUI for its settings, so no surprise it works there. For Jellyfin, I currently use a ROCK5B Armbian Trixie with Armbian vendor 6.1.115 kernel (also EDK2-UEFI bootloader). There were some issue with Jellyfin strreaming/transcoding, also on N100, I currently don't know why/what. The jellyfin-ffmpeg via CLI works great though, so about 5x realtime transcoding HEVC->H264. But Firefox on N100 or x5-Z8350 uses HEVC HW decoder, so no real need to do transcoding for me. LibreElec a month ago or so on NanoPi-R6C temporary booted from SD-card did do HW decoding OK, except for VP9 it was artifacts, not usable actually. So there is unfortunately no easy 1-size-fits-all currenlty. You can scan the forum, there are people who took unfinished patches and use very latest unstable Debian stuff, then things might work same as for x86.

Easiest approach is the customize-image.sh script in userpatches/. https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

Finally, build successful on Ubuntu Noble.😃

Provide logs

moved to feedback

This spi-mcp251x.dts made me use can0 with SEENGREAT Dual-CH Can Hat on latest Armbian v25.11.2 for BananaPi BPI-M4-Zero running Armbian Linux 6.12.58-current-sunxi64: /* * Device tree overlay for mcp2517/18 @ can0 on SPI1.0 (BananaPi Zero M4) / Works with SEENGREAT Dual-CH Can Hat (can0 only) */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/"; __overlay__ { can0_osc_fixed: can0_osc_fixed { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <16000000>; }; }; }; fragment@1 { target = <&pio>; __overlay__ { can0_pin_irq: can0_pin_irq { pins = "PC2"; /* Pin 22 on BananaPi BPI-M4-Zero */ function = "irq"; bias-pull-up; }; }; }; fragment@2 { target = <&spi1>; /* Use SPI1 */ __overlay__ { #address-cells = <1>; #size-cells = <0>; mcp2518fd@1 { compatible = "microchip,mcp2515"; reg = <0>; /* Use SPIx.0 */ pinctrl-names = "default"; pinctrl-0 = <&can0_pin_irq>; spi-max-frequency = <10000000>; interrupt-parent = <&pio>; interrupts = <2 2 0x08>; /* PC2 IRQ_TYPE_LEVEL_LOW */ clocks = <&can0_osc_fixed>; status = "okay"; }; }; }; }; Create file: sudo nano /boot/dtb/spi-mcp251x.dts Add overlay: sudo armbian-add-overlay /boot/dtb/spi-mcp251x.dts Edit armbianEnv.txt: overlays=bananapi-m4-pi-5-6-i2c0 bananapi-m4-sdio-wifi-bt bananapi-m4-spi1-cs0-spidev spi-mcp251x param_spidev_spi_bus=1 dtparam=spi=on param_i2c_arm_baudrate=10000 I did not try to get can1 to work since I don't need it at the moment. I hope it helps. Have fun!

I’ve been testing Armbian on an Amlogic-based TV box, and wanted to share a short user experience. The device originally runs Android, but thanks to the Amlogic S9xx platform, it can boot Armbian from an SD card without touching the internal firmware. In my case, the system booted reliably and was usable for basic tasks like SSH access, light services, and general Linux testing. Ethernet and USB worked out of the box, while Wi-Fi and power management still required some manual tweaks, which seems common for community-supported TV boxes. For reference, the hardware I used belongs to the category of Amlogic TV boxes that are widely available on the market. These devices are not officially supported by Armbian, but they can still be interesting low-cost platforms for learning, testing, or small home projects. I’m curious if others here have experience with Armbian on similar Amlogic TV boxes, and which SoCs or configurations worked best for you.

I see. Is this a hardware enforced security feature of sort? Because according to: https://docs.u-boot.org/en/latest/board/amlogic/boot-flow.html, the s905x2 can read the bootloader from sd card no matter the configuration. Only the order differs. I'm now trying to compile u-boot down from BL2 up to BL33 using this closest match of a board. It has a ddr4 memory while mine is ddr3l, but as shown in the doc it also includes ddr3 firmwares so I *hope* this will work. https://docs.u-boot.org/en/latest/board/amlogic/sei510.html However, if I'm talkin nonsense please let me know. This is my first dive into u-boot or bootloaders in general.

Wow, thank you for this comprehensive answer. It will probably take me about as much time as until 6.19 is released to try and understand it 😂 Why does this say archlinux? And also, where to get these "idbloader.img" and "u-boot.itb" files from? The console is ttyS0, it works.

@Lesano https://linux-sunxi.org/Tanix_TX1 shouldn’t be hard to make a armbian config for this board since it's mainlined. You probably want this patch to add wifi and hdmi. https://gitlab.manjaro.org/iuncuim/linux/-/blob/eccecabc2ca2d6efb463edc94aa0ef383d8ae200/0650-arm64-dts-allwinner-h313-Tanix-TX1-TVbox.patch You would need to boot over USB cable. I never booted over USB so I can't help with that. https://linux-sunxi.org/FEL/USBBoot

I couldn't find this documented specifically, but I confirmed this was the case via testing. Google also provided an AI summary which also stated that this was the case. I enabled `iptables-legacy` in the Armbian kernel builder which then resolved the errors I was getting. I also eventually realized through further research that `nftables` were also supported and available as a module out of the box. I wound up changing my Microk8s config to use `nftables`, which also worked out and is where I left my config today. Hopefully this is helpful for someone else in the future. Somewhat relevant articles: https://github.com/canonical/microk8s/issues/2180 https://github.com/canonical/microk8s/issues/4387 https://hub.libre.computer/t/missing-iptables-kernel-configs-for-microk8s-calico/3717

i also tried installing network manager separately, however it is not able to override the wifi configurations. It was allowing in image files few months ago. But now it does not allow.

In the past (2019) there was no chance to use the A64-CPU Jide Remix Mini with armbian, because of a blocked -u-boot But today I found a site (from February 2025 on github) https://github.com/r4nd3l/revived_remix_mini_pc?tab=readme-ov-file which can make the Closed Jide Remix Mini to boot from SDCard with a modified u-boot There at the github page is a modified u-boot and a modified A64 armbian for the Jide Remix Mini. Jide did leave us with a closed/blocked device AT this time the 16GB emmc isnt useable, but using SDCard is a start for upcycling the Jide Remix Mini

This suggests it is 5V only and also no USB-C PD. You should power a ROCK5 with higher voltage, then no issues, at least that is my experience and is also what you can see if you look at schematics. You can also read the end-user docs/wiki. ROCK3A, ROCK5B, NanoPi-R6C all have own step-down DC/DC converter on the board itself. The latter one for example has an 8A component for it. So it can make enough power from 20 or 15 Volt input at a perfect 5V internally for USB devices on its type-A ports, and also easily maintain its 3.3V and lower voltages for CPU etc. OrangePi is cheap, same as RaspberryPi. Those shift the powering (issues) to the end-user, meaning you need a stable enough 5V on the USB power input connector. A slight voltagedrop can lead to problems. But board itself is cheap. RPi5 requires a quite rare 5A capable 5V USB-C PD (RPI5), where the ROCK3A/5B can just be fed from any voltage between 9 and 20 Volt (see docs/wiki). If you use 5V, the on-board DC/DC step-down cannot do its work of course, so essentially bypassed. Why did you buy a ROCK5 then. Same as buying a car with combustion engine with empty fuel tank, instead put a horse in front to pull you forward from A to B. (Or get a bicycle). The (extra) horse is the 27W Pi5 PSU here, costed me 18 Euros, half the price of the ROCK3A. I put a fixed 12V on a USB-C connector, from an old card battery, that by itself is kept at about 12V by a 12V/10A generic powerbrick. Is also UPS then is no 230VAC mains. The Nanpi-R6C with latest U-Boot and latest mainline kernel does also do USB-C PD, so with a generic 45W USB-C PD PSU, is flips automatically to 15V on its USB-C input. With another 60W USB-C PD PSU it was 20V. ROCK5B should be able to do the same, but haven't tried as run 24/7 for months as home/house server.

Hi guys and Happy Christmas. I found something that could be useful. I had trouble due to fake sd card that report fake capacity. Capacity declared 64 Gb real capacity 3.7 GB. H2testw (windows) will show you the real capacity. Don't trust if it is a known brand because there are companies with machine to fake SD card. After another problem that I found is not to see the boot partition after imaging SD card. I don't know why but you must be sure that your imaging program (balena etcher o pi imager or rufus) are run in admin mode. after that in any case if it doesn't appear you have to assign a letter drive (sometimes it is not assigned) I used aomei partition manager)

I've used an encrypted root in my configuration. I've found earlier versions of the vendor kernel to not include dm_crypt, so I've always used the edge kernel. That one's been quite reliable with encryption. If you're using serpent encryption, that's one that's more likely missing than the others. Run this to see if serpent's missing (from your (vendor) kernel): cryptsetup benchmark If serpent is missing, it will report N/A instead of a speed for that one. If you really want to use a vendor kernel, you can build it yourself... being sure to include dm_crypt, and if necessary, a serpent encryption module.

I was rechecked that openvfd works and get its config openvfd dtbo overlay fragment (decompiled on running system) It works, driver loaded and userspace software shows me current time on LED (some segments shows wrong, i think it result of wrong chars config) tm16xx: I've tried many values for GPIO line config, GPIO_ACTIVE_LOW (1), GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN (6), GPIO_ACTIVE_HIGH (0), GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN (7). It was no result at all, driver still says that cannot init controller. Also i was tried drivers fd6551, fd655 with different GPIO lines config. No success. I was rechecked LED controller chip on board, it is really FD6551. tm16xx dtbo overlay fragment (decompiled on running system) I have no ideas what goes wrong. When i was configure openvfd device tree, pointing gpio chip as &gpio was not works. Only pointing as "0300b000.pinctrl" was successful. Maybe, its important... Maybe, some features/conflicts at controller init needs debugging

@robertoj I apologize, perhaps you missed the message.

Today investigated, why BCM Bluetooth was not working with my image. What a rabbit hole 🙄 Also added OrangePi R2S board. Smaller brother of RV2 (I have no board but it's probably working). For the Bluetooth: everyone is obviously happy to hack the BCM firmware file instead of implementing bcm init into hciattach. The brcm_patchram_plus firmware hacking tool was added for this arch and that arch as a binary under BSP for different boards. Not very Debian-style. I grabbed the working source, compared to the one avail in Android AOSP and added it to my branch, added lib6-dev-riscv64-cross to the Docker image and now have a working image with BT. LG && HTH // Sven-Ola

http://blog.armbian.com/content/images/2025/12/holiday1-1.pngFrom major kernel milestones to expanding our support for the latest ARM and RISC-V hardware, 2025 has been a year of growth and grit for Armbian. As we wrap up the final commits of the year, we’re looking back with gratitude at how far this project has come. The holiday season is our favorite time to reflect on the power of open source - where a global community comes together to make hardware work better for everyone. Thank you for being part of our story this year. Happy Holiday Hacking! Public beta: new Armbian OS image flasher. Clean, simple, open-source tool for flashing Armbian or any other disk image to your single board computer. Download for Linux / Window / MacOS Nanopi R76SThe ultimate travel router and secure hotspot Forget insecure hotel Wi-Fi. The NanoPi R76S, powered by the performance-optimized Armbian OS, is your ticket to a truly secure, high-speed mobile network. This pocket-sized device is built around the powerful Octa-core Rockchip RK3576 SoC and supports up to 16GB of LPDDR5 RAM,http://blog.armbian.com/content/images/icon/favicon-35.icoArmbian blogIgor Pecovnikhttp://blog.armbian.com/content/images/thumbnail/r67-1.jpgSponsored Post Armbian flashing toolWe’ve added a powerful new Image Flashing Tool to Armbian! You can now browse, download, and flash Armbian images directly to your device’s internal storage or boot media - no external tools required. Everything happens seamlessly inside armbian-config, making installation and re-installation faster, safer, and easier than ever.http://blog.armbian.com/content/images/icon/favicon-32.icoArmbian blogIgor Pecovnikhttp://blog.armbian.com/content/images/thumbnail/ChatGPT-Image-Dec-8--2025--11_11_38-PM.pngGithub HighlightsThis week in Armbian development saw significant progress across board support, kernel updates, and codebase improvements. Notable additions include support for the SpacemiT MusePi Pro and Friendlyelec NanoPi Zero2, alongside expanded compatibility for TI AM62x SoC boards. Multiple platforms, such as Rockchip, Meson64, and Sunxi, received kernel bumpst to newhttp://blog.armbian.com/content/images/icon/favicon-34.icoArmbian blogMichael Robinsonhttp://blog.armbian.com/content/images/thumbnail/highligts-2.pngView the full article

The ultimate travel router and secure hotspothttp://blog.armbian.com/content/images/2025/12/r67.jpgForget insecure hotel Wi-Fi. The NanoPi R76S, powered by the performance-optimized Armbian OS, is your ticket to a truly secure, high-speed mobile network. This pocket-sized device is built around the powerful Octa-core Rockchip RK3576 SoC and supports up to 16GB of LPDDR5 RAM, giving it the muscle to handle demanding, encrypted traffic effortlessly. 💡This device is officially supported by Armbian at the Platinum level, providing long-term maintenance, high reliability, and priority software support.Its core hardware is ideal for the road. The dual 2.5GbE Ethernet ports ensure you can maximize the speed of any high-bandwidth wired connection, while the M.2 E-Key slot allows for adding an optional Wi-Fi card to create a high-speed, personalized hotspot. More importantly, the powerful CPU is a VPN champion. With Armbian, setting up an encrypted connection is simple and utilizes the device's full potential. To create a persistent, secure tunnel for all your devices, just launch the terminal and run: sudo armbian-config. Navigate to Software and select the pre-packaged WireGuard install. This single step leverages the RK3576’s processing power for blazing-fast encryption and decryption, eliminating the speed slowdowns common with weaker travel routers. Finally, the USB 3.2 is perfect for attaching a portable SSD, instantly turning R76S into a secure, mobile NAS for backing up your files. This is just one example of usage. It can be served as a compact home or office server, Home Assistant hub, a high-performance network gateway with advanced firewalling and VPN termination, or a lightweight virtualization host for containers. Thanks to its dual 2.5 GbE interfaces, the R76S excels in scenarios where fast, reliable networking is essential. From segmented home labs and development environments to branch-office routing and monitoring. Combined with low power consumption and solid software support, it offers an impressive balance between performance, flexibility, and efficiency in a remarkably small form factor. Hardware specifications SoCRockchip RK3576 CPUOcta-core ARM (4× Cortex-A72 + 4× Cortex-A53) GPUARM Mali-G52 MC3 OpenGL ES 1.1 / 2.0 / 3.2, Vulkan 1.2, OpenCL 2.0 VPU8K@30fps H.265 / VP9 decoder 4K@60fps encoder NPU6 TOPS (INT8) Supports INT4, INT8, INT16, FP16, BF16, TF32 Memory2 GB / 4 GB LPDDR5 Storage32 GB eMMC microSD (UHS-I) Ethernet2 × PCIe-based 2.5 GbE WirelessOptional M.2 SDIO Wi-Fi USB1 × USB 3.2 Gen 1 Type-A HDMI HDMI 1.4 / 2.0 Up to 10-bit Deep Color Up to 1080p@120Hz or 4096×2304@60Hz 3D video support DebugUART (3-pin 2.54 mm, 3.3 V, up to 1.5 Mbps) GPIO1 × 8-pin GPIO connector Indicators3 × GPIO-controlled LEDs (SYS, LED1, LED2) ButtonsPower, User, MASK (eMMC update) RTC2-pin RTC battery connector (HYM8563TS) Power InputUSB-C, 5 V PCB8-layer PCB, 58 × 58 × 1.6 mm Operating Temperature0 °C to 70 °C View the full article

http://blog.armbian.com/content/images/2025/12/highligts-2.pngThis week in Armbian development saw significant progress across board support, kernel updates, and codebase improvements. Notable additions include support for the SpacemiT MusePi Pro and Friendlyelec NanoPi Zero2, alongside expanded compatibility for TI AM62x SoC boards. Multiple platforms, such as Rockchip, Meson64, and Sunxi, received kernel bumpst to new LTS 6.18.y and patch refinements, enhancing stability and hardware support. The team also improved consistency in function naming, streamlined vendor relations, and addressed driver issues for Rockchip64. Workflow enhancements were made to enforce image availability for new boards and reduce review noise. Additionally, legacy UEFI images for WSL2 were removed, and documentation output processes were refined. These updates reflect Armbian’s ongoing commitment to robust hardware support and development efficiency. Add board SpacemiT MusePi Pro and update linux patching. by @pyavitz in armbian/build#9058Add support for Friendlyelec NanoPi Zero2. by @sapphic-kitten in armbian/build#8886adjust function names for the sake of consistency. by @EvilOlaf in armbian/build#9108Board vendors adjustements for generic targets. by @igorpecovnik in armbian/build#9109Bump Rockchip edge to 6.18.y. by @igorpecovnik in armbian/build#9104CodeRabbit review noise reduction. by @igorpecovnik in armbian/build#9074compress-checksum: introduce COMPRESS_OUTPUTIMAGE=zst. by @rpardini in armbian/build#9101DevTree overlays to enable RK3308 UARTS. by @brentr in armbian/build#9072extensions/gen-sample-extension-docs: output Markdown to userpatches/extensions. by @rpardini in armbian/build#9075Fix missing board vendor relations. by @igorpecovnik in armbian/build#9110Fix PR comments for forked submissions. by @igorpecovnik in armbian/build#9089GHA: Enforce board and vendor image availability for newly added boards. by @igorpecovnik in armbian/build#9087meson64: 6.18: drop cacheref S922X fix patch as it landed on 6.18.2. by @rpardini in armbian/build#9100Meson64: linux-6.18.y: Improve 6.18.y support for G12/SM1. by @pyavitz in armbian/build#9070radxa-e24c: enable edge branch by picking from Kwiboo's WiP tree. by @rpardini in armbian/build#9102rockchip64: Fix IEP driver. by @fwolter in armbian/build#9107rpi4b: bump legacy, current and edge to new major version. by @EvilOlaf in armbian/build#9097rpi4b: enable EXTRAWIFI again for edge. by @EvilOlaf in armbian/build#9073sunxi: adjust patch for H616 overlays. by @EvilOlaf in armbian/build#9096sunxi: bump current and edge to latest minor, rewrite patches. by @EvilOlaf in armbian/build#9103sunxi: bump edge to 6.18. by @EvilOlaf in armbian/build#9049sunxi: fix missing dt overlays. by @EvilOlaf in armbian/build#9094TI SK-AM62-SIP Remove Edge Target. by @Grippy98 in armbian/build#9105ti: configs: boards: Add additional AM62x SoC board support. by @jonaswood01 in armbian/build#9081ti: configs: family: k3: Update baseline to 11.02.08. by @jonaswood01 in armbian/build#9091Update odroidxu4-current to 6.6.119. by @belegdol in armbian/build#9037WSL2: Drop UEFI images designed specially for WSL2. by @igorpecovnik in armbian/build#9098View the full article

See here, HW description bulletpoint 17 https://www.hardkernel.com/shop/odroid-m1s-with-4gbyte-ram/ Maybe it is also available on the 40-pins or 14-pins I/O headers, so a simple generic USB serial cable with jumper wires can be connected.