Search the Community

Early May brought another round of steady advancements to the Armbian project, with progress in U-Boot updates, board enablement, firmware fixes, and notable improvements to Armbian’s growing catalog of self-hosted applications. Bootloader and Firmware Enhancements Several platforms saw significant U-Boot improvements. The Cherryba-M1 now benefits from an upgraded U-Boot and reorganized patch structure, thanks to Igor‘s work on upgrading Cherryba-M1 to latest u-boot and moving patch to new folder. Andy bumped U-Boot to v2025.04 for the Lubancat2, keeping the board current. The Radxa Rock 4 SE also migrated to this version, where Niklas refined its configuration and boot behavior. Meanwhile, the Khadas VIM3 received a broader bootloader overhaul led by Ricardo, introducing SD-first boot order, squashfs and fileenv support, and enhanced compatibility with Home Assistant OS in a comprehensive update to U-Boot for Khadas VIM3. Older configurations didn’t go unnoticed: Igor removed deprecated ATF tags for sun50iw9 / H61x, while Olaf pushed the sunxi64 platform to the latest LTS version of ATF. Expanding Device Support Armbian continues to grow its ecosystem. Rolf introduced official support for the Banana Pi M2+, making it easier for users to deploy on this compact board. On the RISC-V side, libiunc brought the kernel for the StarFive2 platform up to v6.6, ensuring ongoing support and compatibility. Installer Improvements and Runtime Fixes Improving install experience, Igor Velkov added Btrfs root subvolume support when installing to NVMe, paving the way for better snapshot and maintenance workflows. Igor also corrected missing Broadcom firmware for Raspberry Pi boards to fix wireless support and suppressed firmware warnings related to built-in Realtek USB network drivers, helping clean up logs and reduce confusion. Self-Hosted App Catalog Grows The list of installable apps during Armbian setup has expanded. Two powerful platforms are now just a selection away: Immich, a self-hosted photo and video backup system, was added with the introduction of Immich to configNG. NetBox, a leading infrastructure resource management solution, joined the roster in the addition of NetBox to Armbian configNG. Both are available via the configNG provisioning interface. Deprecations and Housekeeping Support for legacy distributions has now ended: Debian Bullseye and Ubuntu Focal and Jammy will no longer receive repository updates, as noted in the userspace status change to EOS. Elsewhere, dependency and CI maintenance continued. Automated tools like Dependabot bumped packages such as setuptools and GitHub actions for changed-files, while amazingfate restored support for the AIC8800 Wi-Fi driver by reverting a mistaken disable. Further Reading Explore the full range of updates in the official Armbian snapshot. The post Armbian Development Highlights – Early May 2025 first appeared on Armbian. View the full article

DKMS is 'quite complicated' , in an attempt to understand all that 'cryptic' stuff, I went googling around https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support https://www.linuxjournal.com/article/6896 https://github.com/dell/dkms https://wiki.gentoo.org/wiki/DKMS https://www.collabora.com/news-and-blog/blog/2021/05/05/quick-hack-patching-kernel-module-using-dkms/ https://www.baeldung.com/linux/dynamic-kernel-module-support https://nilrt-docs.ni.com/opkg/dkms_opkg.html ^ surprisingly I found this guide/tutorial from national instruments 'quite intuitive' and I dug further into how to make a kernel module, well at least a 'hello world' https://tldp.org/LDP/lkmpg/2.6/html/ https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman --- ok I actually tried building that 'hello world' kernel module and *it works*, for practically 'ancient' 2001 instructions. so it turns out that to compile a kernel module, you do not need to build it in the kernel source tree itself and that is *without* DKMS, read that last 2 tldp guides: The Linux Kernel Module Programming Guide you can try building and inserting the 'hello world' module into your kernel, no DKMS, whatever, after you build your module ! in short is it not necessary to build a kernel module within the kernel source tree itself, but that there are some procedures as spelled out in that 2 tldp docs. (but fast forward to today, this same instruction may not work if you are using secure boot, then a lot more complicated things like module signing gets involved, review that dkms link from dell) ------- now back to DKMS , where does that fit in? so it turns out that DKMS is a utility / tool / system / automation tool, to help you *rebuild the kernel module* - out of linux kernel source tree (i.e. as like the hello world module above), *without building the kernel from source itself* ! but that you need to ***rebuild the kernel module from source***(e.g. using DKMS), then all the other links above are guides that may be relevant ---- now add more complications / complexities, normally what you wanted is a *driver* , not simply a kernel module the driver often has several parts - the kernel module itself (this is the 'easy' part, you need to build it - from source), and that does not mean having to build the kernel itself from source, but you need to build the *kernel *** module *** *. after you build the kernel module successfully, say, then there are more blows and pitfall these days wifi and many network hardware requires *firmware files* , these *firmware files* can consist of 'bin' (firmware binary) and configuration (some of them text files) some of these firmware stuff lives in /lib/firmware. then that you need your kernel module, you can deem that the 'driver core' that interface the OS and interface those firmware. those firmware do not necessary run on the (host) cpu (i.e. your pc) but instead in the wifi chip itself. this is the part that is *highly opaque*, there are so many wifi chips that are *undocumented*, the firmware is *undocumented* and if you do not have any source for your kernel module which interface the firmware to the os, you are out-of-luck. ----- to summarise - normally, one cannot hope to take a binary kernel module install it in your current kernel and hope it 'just works'. if that works, a lot of things such as module versions and various constraints imposed by the kernel matches that in the kernel module itself, i.e. that module is compiled specifically for that specific kernel itself ! DKMS do not solve this, DKMS only *helps you rebuild the (kernel) module *** from source *** *, (and install it optionally). the idea is this, you have the *source* to your out of kernel source *kernel modules*, when you upgrade the kernel, e.g. such as an apt-upgrade etc, DKMS can be triggered to *rebuild the kernel module from source* (and install it) in the new kernel (binary) tree e.g. copy that into /lib/modules/{kernel version}/xxx --- if the kernel module is part of the kernel source tree itself, it actually do not need DKMS. But that if the errors occurs after building that *kernel module* (i.e. driver) , then congrats - you found a 'bug' in the *kernel module (driver)*, and that is true even if it is out of kernel source as a DKMS build. i.e. the driver sources need to be patched to work in the new kernel.

You could try to create chromium.conf yourself. Here's what I have here: cat /etc/armbian/chromium.conf # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=$(grep -c processor /proc/cpuinfo) \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disk-cache-dir=/tmp/${USER}-cache \ --disk-cache-size=$(findmnt --target /tmp -n -o AVAIL -b | awk '{printf ("%0.0f",$1*0.3); }') \ --no-sandbox \ --test-type"

Hi. For my application it would be very advantageous to speed up the boot time of the device as much as possible. The application depends on the network, and unfortunately it seems it takes a while for the interface to establish a connection. After plugging in the device, I count that it takes about 25-30 seconds until my application starts (which is set to start on reboot by cron). However, at that time, the network is still not up, so it matters little that the application has started. It takes another 20 seconds or so until the device is reachable by the network. So total 45-50 seconds from boot. Why is this? I see in systemd-analyze that NetworkManager.service starts at around 30 seconds, same as cron. So what is the holdup? The IP is static and it is plugged in with Ethernet, so I don't understand what takes time when it comes to connecting to the network, after the network manager has started. How can I troubleshoot this or make it connect faster? Bonus question. Another thing that takes a lot of time in the boot is armbian-ramlog.service, at nearly 8 seconds long. See attachment for full boot chart. Is there a way to shorten this too, without disabling ram logging entirely? bootanalyze.svg

does anyone know how to get maskrom and uart on this rk3228a board from mxq pro 4k 5G since pushing the little button shows up as armlogic devices on device manager but the actual chip is rockchip and sorry for bad quality images

Armbian 24.2 is broken on Orange PI PC2 (Debian Bookworm CLI) Latest stable community release: https://github.com/armbian/community/releases/download/24.5.0-trunk.123/Armbian_community_24.5.0-trunk.123_Orangepipc2_bookworm_current_6.6.20_minimal.img.xz With update 23.11 -> 24.2 the orange pi pc2 no longer starts. I tried a new sd installation and it too does not appear on the network. Right now I don't have a serial cable to check but it is possible that the network driver is missing or not working. SD, SBC and PSU are 100% working: a revert to 23.11.2 makes it work perfectly.

@Igor Armbian_25.5.1_Orangepizero3_bookworm_current_6.12.23_mi nimal.img.xz below is transcript from the 'debug uart (serial)' console, via a usb-uart dongle, it is the only way to boot up with a console , if network etc is not available. U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... .... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxx (WAN) xxxx Performance: Load: 18% Up time: 2 min Memory usage: 9% of 1.44G CPU temp: 50°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.250.4.138) 56(84) bytes of data. 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=1 ttl=100 time=2.77 ms 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=2 ttl=100 time=2.79 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxx freq: 24xx signal: -77 dBm ^ wifi works, at least for scanning for stations, connect and AP not yet tested ^ the above is booted up on a 'rare' 1.5GB board. repeat using the same uSD card on a 4 GB board, initially the debug usb-uart console is garbled, it seemed to be a baud rate mismatch, I'm not sure why, but after a few retry it works. Perhaps it is due to bad wires. U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 4 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... ... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxxxxx (WAN) xxxxxxxx Performance: Load: 12% Up time: 1 min Memory usage: 3% of 3.83G CPU temp: 46°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.251.12.139) 56(84) bytes of data. 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=1 ttl=103 time=2.69 ms 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=2 ttl=103 time=2.99 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxxx(on wlan0) freq: 24xx signal: -78.00 dBm ^ wifi works for scan, connect and AP not tested I'm not too sure what is the difference between v25.5.1 vs that on the boards page? https://www.armbian.com/orange-pi-zero-3/ from those links 'current' seemed to be linked to: as of current 28 May 2025 Armbian_community_25.8.0-trunk.8_Orangepizero3_bookworm_current_6.12.23_minimal.img.xz btw thanks much (to all contributors) for updating Armbian to 25.x for OrangePi Zero 3 (and likely means works for Zero 2W) as well. oh frequency scaling works as well, this is on the 4GB board root@orangepizero3:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 01:43:36 1416 MHz 0.00 1% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:41 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:46 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.4 °C 0/7 01:43:51 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.0 °C 0/7 'everyone' should just get the 4GB board, make it a 'standard' lol @TRay It is a good idea to try U-Boot v2025.04 I've got a python script which can patch u-boot binary into an Armbian .img or practically any other image file (though i've only tested this in *unofficial* armbian builds) https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/tools https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3 i created it back then while researching solutions for the '1.5GB' problem back then. Do you have the 'bin' file for u-boot that you could share say in a zip file attached here? you can extract that 'bin' file using the 'backup' procedure documented here: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3?tab=readme-ov-file#how-to-use sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 But that the appropriate way would be to build the full armbian image from source including u-boot etc. Nevertheless, having the 'patched' u-boot binary would enable most here to test that by patching a distributed image file e.g. from the boards page, or from the 'test images' link as Igor has provided.

I apologize if this is a basic question. I'm trying to make a minimal Orange Pi Zero 3 Trixie image with a btrfs file system and NetworkManager for the networking stack using Docker without having to compile a new kernel (i.e., I just want to use the precompiled kernel found in the CSC version). I created a `config-myimage.conf` file under `build/userpatches`: BOARD=orangepizero3 BRANCH=current RELEASE=trixie CLEAN_LEVEL=cache KERNEL_CONFIGURE=no BUILD_KSRC=no BUILD_MINIMAL=yes NETWORKING_STACK=network-manager DOCKER_ARMBIAN_BASE_IMAGE=ubuntu:jammy ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zlib CONSOLE_AUTOLOGIN=yes #BOOTSIZE=96 # need larger boot size to prevent 'disk out of space' # on kernel upgrade BOOTSIZE=256 COMPRESS_OUTPUTIMAGE='sha,xz' EXTRAWIFI=yes function user_config__010_modify_package_list() { # adds additional packages to the package cache add_packages_to_rootfs btrfs-progs neovim pmount nmap tmux # edit this list to remove packages from cache remove_packages nano } I then ran `./compile.sh myimage`, but it launches into kernel compilation. I did this once before uisng bookworm, but I can't remember how....

To troubleshoot that you could boot off a fresh Armbian 24.11.1 Bookworm image (6.6.62) and add rtl_nic firmware, replace dtb, setup rc.local. If transfer rates are still low something may be wrong with your client or with your helios64 or with the network itself. Did you launch 'htop' so that you can see what is going on during the data transfer? Are there any cores fully utilized ? Is nic offloading enabled ? etc. 'systemctl disable armbian-hardware-optimize.service' I am automatically calling that shell script while mounting helios64 as a remote drive on macOS clients (using netatalk). The names of the processes (afpd|cnid|iperf3|netatalk) need to be replaced by the processes involved in the data transfer on your helios (iperf3, smb? etc. ). root@grid:~# chmod +x /usr/local/bin/make_nas_processes_faster.sh root@grid:~# sh /usr/local/bin/make_nas_processes_faster.sh pid 21358's current affinity list: 4 pid 21358's new affinity list: 4 pid 21359's current affinity list: 4 pid 21359's new affinity list: 4 pid 21360's current affinity list: 4 pid 21360's new affinity list: 4 pid 21367's current affinity list: 4 pid 21367's new affinity list: 4 pid 21368's current affinity list: 4 pid 21368's new affinity list: 4 pid 21700's current affinity list: 4 pid 21700's new affinity list: 4

I confirm that the current version of Armbian, as downloaded, is completely useless unless you have a serial console, because it doesn't do DHCP successfully on either interface, so you can't SSH into it to fix the network problems. And I can see errors in the logs that you can click to view to see that the release was "tested". A loopback test needs to be part of the standard test. Turn on both NICs, give them IP addresses, and verify that they can communicate with each other. As it currently stands, Armbian is shipping releases that claim to be "tested", but in practice, can't be used by the vast majority of people who will download them, and that's a rather serious quality control fail. Additionally, Armbian should do something like what the OctoPrint firmware does — have a small FAT32 volume that contains wpa_supplicant. That way, you could at least bring up the Wi-Fi network if Ethernet doesn't work. Without any USB or HDMI output, the Ethernet drivers are effectively a single point of failure in this distro, and that's a bad situation to be in, particularly when there's apparently zero testing of that critical driver before shipping a build. I'd file a bug, but the bug reporting form won't let me unless I have serial console hardware, even though the problem is entirely obvious without it. 🙄 Downloading an older build now. Ugh.

It looks like the problem is Ubuntu 25.04. I thought it would work if I used Docker instead of native OS build support. steven@nuc14e:~/build$ sudo ./compile.sh requirements [🌱] Extension manager [ processed 4 Extension Methods calls and 12 Extension Method implementations ] [🌱] Build host OS release [ plucky ] [🌱] Build host architecture [ amd64 ] [💥] error! [ Unsupported build system: 'plucky' ] [💥] Exiting with error 43 [ at /home/steven/build/lib/functions/logging/traps.sh:1 exit_with_error() --> lib/functions/logging/traps.sh:1 obtain_and_check_host_release_and_arch() --> lib/functions/host/host-release.sh:41 cli_requirements_run() --> lib/functions/cli/cli-requirements.sh:30 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> ./compile.sh:50 ] [💥] Cleaning up [ please wait for cleanups to finish ]

Armbian v25.5: Expanding Horizons, Honoring Community, and Powering the ARM Ecosystem The Armbian team is proud to announce the release of Armbian v25.5—a significant update that reinforces the project’s commitment to delivering a reliable, high-performance Linux experience for ARM-based devices. This release highlights continued progress across the system, including deeper hardware support, enhanced tooling, and growing application modularity through armbian-config. In addition to the technical achievements, the community has received international recognition for its leadership and innovation in open-source infrastructure: Armbian has been awarded the 2025 NetBox Hero Award by NetBox Labs, joining a prestigious list of projects that have demonstrated meaningful impact in automation and open infrastructure practices. What’s New in v25.5 This release brings dozens of contributions from across the Armbian community, targeting system performance, configuration management, and hardware enablement. Noteworthy improvements include: Extended board support: The release introduces or improves compatibility for several boards including the TI SK-AM69 (PR #7885), Banana Pi M2+ (PR #8127), BeagleBone AI-64 (PR #7918), BeaglePlay (PR #7917), and PocketBeagle2 (PR #7897). These additions reflect Armbian’s growing footprint across both legacy and cutting-edge single-board computers (SBCs). Upstream firmware integration: Rockchip devices like the Rock 5B and Youyeetoo R1 now enjoy better audio and HDMI support (PR #7925, PR #7934). U-Boot versions were bumped for key platforms to align with upstream. Kernel upgrades: Devices based on Rockchip64 now run on Linux kernel 6.14 (edge branch), bringing better performance and peripheral support. Additionally, kernel patching logic is now configurable (PR #8149), allowing developers to build plain mainline kernel. Filesystem and boot enhancements: Improvements to EFI partition alignment (PR #8053) and BTRFS subvolume support further refine system boot behavior and make image generation more flexible for custom installations. Stability and quality improvements: Updates include boot script fixes, enhanced serial console support, and a simplified logging framework, all designed to improve diagnostics and system reliability during early boot and provisioning phases. armbian-config: Simplifying Post-Install System Management One of the biggest areas of growth in Armbian v25.5 is the continued evolution of armbian-config—a system utility for configuring Armbian images after installation. Whether setting up a home automation server or managing Docker containers at the edge, armbian-config now offers an impressive set of tools in a modular and approachable interface. Application library: Users can now deploy popular self-hosted applications directly from armbian-config, including Home Assistant (PR #235), Stirling PDF (PR #295), Navidrome (PR #367), Grafana (PR #351), NetData (PR #289), and Immich (PR #575). These modules are installed in isolated environments, making them easy to deploy, manage, and remove. Network and system settings: A more robust Wi-Fi station detection system improves wireless setup reliability (PR #286). New schematics and better documentation provide helpful context during network interface configuration (PR #278, PR #280). Overlay and BSP switching: Logic for board-specific overlays is now dynamically loaded, ensuring options are shown only where supported (PR #285). The BSP switching tool has been patched to correctly detect the branch being used (PR #281), and header installation logic was refactored to reduce redundancy (PR #277). These improvements reinforce armbian-config as a trusted utility for both new users and experienced developers building production or custom systems. NetBox Hero Award: Community Excellence Recognized Armbian’s impact reaches beyond code. In this release cycle, the project was selected as one of the winners of the 2025 NetBox Hero Awards by NetBox Labs. This award celebrates the community’s dedication to infrastructure innovation, automation, and transparency. Armbian was recognized specifically for its “elegant and extensible use of NetBox in support of a broad set of infrastructure needs.” This acknowledgment affirms the project’s alignment with modern infrastructure tooling and its unique role at the intersection of embedded systems and open infrastructure platforms. Read more: https://netboxlabs.com/blog/announcing-the-netbox-hero-award-winners-for-2025/ Recognized Contributors This release wouldn’t be possible without the contributors who authored the pull requests featured in v25.5. We thank: @amazingfate • @anarsoul • @andyshrk • @ArendJan • @Ayush1325 • @belegdol • @benhoff • @chainsx • @CodeChenL • @dependabot • @djurny • @efectn • @EvilOlaf • @FantasyGmm • @glneo • @Grippy98 • @HeyMeco • @iav • @ig3 • @igorpecovnik • @JohnTheCoolingFan • @juanesf • @kageurufu • @KubaTaba1uga • @lanefu • @leggewie • @libiunc • @mickeprag • @mlegenovic • @palachzzz • @paolosabatino • @plumbeo • @pyavitz • @q4a • @qbisi • @rpardini • @schmiedelm • @SeeleVolleri • @squassina • @ssp97 • @SuperKali • @The-going • @TheSnowfield • @timsurber • @torte71 • @trappiz • @useful64 • @retro98boy We also extend our appreciation to those who helped through bug reporting, testing, translations, documentation, and community moderation. Get Involved Armbian is open to all. Whether you want to contribute code, write documentation, test releases, or just ask questions—there’s a place for you. Download images: https://www.armbian.com/download Join discussions: https://forum.armbian.com Report issues or contribute PRs: https://github.com/armbian/build Read developer guides: https://docs.armbian.com Looking Ahead Armbian v25.5 is not just a technical milestone—it’s a testament to the collaborative power of open source. With a stronger foundation, broader hardware support, and a growing ecosystem of modular tools, Armbian is well-positioned to lead the future of ARM-based Linux computing. Full change logs: build framework, armbian-config The post Armbian 25.5 first appeared on Armbian. View the full article

More attempts: As suggested by DeepSeek (ChatGPT was less helpful), I also tried changing the bluetooth service script to ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=a2dp --noplugin=avrcp --noplugin=player and then restarting systemd itself and the bluetooth service, but no luck. I tried adding monitor.bluez.properties = { bluez5.roles = [ ] } to /usr/share/pipewire/pipewire.conf and restarting wireplumber, but no luck. I tried menu advertise uuids 0x1200 0x1800 0x1801 0x180a in bluetoothctl, to disable advertising the audio profiles, but no luck. But when in bluetoothctl, it really shows the audio connection being made when the phone connects.

Hello… Jayson here ...and I have installed the image of Armbian Gnome Desktop for RPI5. Next I get up to par with this command: sudo apt install linux-headers-edge-bcm2711 alsa* pavucontrol pithos vulkan-tools mesa-vulkan-drivers xdg-desktop-portal-gnome gnome-remote-desktop libspa-0.2-bluetooth qv4l2 obs-plugins obs-studio pipewire-alsa pipewire-audio pipewire-audio-client-libraries pipewire-bin pipewire-pulse gnome-shell gnome-shell-common gnome-shell-extensions gnome-shell-extension-manager libpipewire-0.3-* gnome-remote-desktop gnome-settings-daemon* x11* git qgnomeplatform-qt5 qt5-image-formats-plugins qt5-qmltooling-plugins qtvirtualkeyboard-plugin qttranslations5-l10n libqt5svg5 qt5-gtk-platformtheme qtwayland5 xdg-desktop-portal-gnome qv4l2 rpi-imager gnome-tweaks snap && sudo snap install chromium && sudo apt install inux-headers-current-arm64 linux-headers-current-bcm2711 linux-headers-current-bcm2712 && sudo apt install v4l2loopback-dkms Then obs will work with: MESA_GL_VERSION_OVERRIDE=4.2 obs More soon!!!

If I transfer from Helios64 2.5Gbit Port to a client 2.5Gbit port I'll got a very slow transfer rate (Helios -> client around 200Mbit/s), vice versa full speed, switch is 2.5Gbit (Rj45 ethernet Cat7 cable).Testet with iperf. The switch monitoring indicates always 2 errors. I know about the Hardware issue of Lan-Port2, but it only effect 1Gbit transfer. Nevertheless in the Network are also mixed with 1Gbit clients. Is there anything I'll can try to get full 2.5Gbit speed?

hey, @cmuki! Using the dts from the rk3576-evb1-v10 / rk3576-armsom-sige5 / rk3576-rock-4d in the https://github.com/radxa/kernel/arch/arm64/boot/dts/rockchip/ directory After modification, they can all boot the Armbian version h96-m9s Note: The rk3576-linux.dtsi file forcibly specifies the UUID of the rootfs device partition, which may cause system boot failure. Adjustments might be needed. The basic modification method is simple: disable the PCIe and GMAC1 configurations, modify the reset_pin configuration of GMAC0 to gpio2 and PB3 to enter the system. I used rock-4d as the template for modification. Other modifications have not been thoroughly studied yet.

I installed armbian with a vendor kernel 6.1.75-vendor-rk35xx. I want to be sure the kernel is not updated. I used armbian-config and selected "SY203 - Disable Armbian kernel upgrades" Disable Armbian kernel/firmware upgrades Would you like to continue? after selecting "Yes", the menu shows "SY202 - Enable Armbian firmware upgrades" so I check with apt-mark showhold and it returned only "armbian-firmware" Do I have to put my kernel packages on hold? linux-dtb-vendor-rk35xx linux-headers-vendor-rk35xx linux-image-vendor-rk35xx I find misleading the change in the description from SY203 to SY202: kernel -> firmware

@Nick A I’m using the MiniArch image that was shared here on the forum. From it, I extracted the DTBs, Image, and other boot files, and replaced them in the Armbian image. I also took the bootloader from the MiniArch image and replaced the one in Armbian. With that, I managed to boot into Armbian, but unfortunately, no network adapters were detected.

Hi, I am currently using rock-5-itx to setup a NAS. Everything is working fine. uname -a: Linux amberbyte 6.1.75-vendor-rk35xx #1 SMP Thu Nov 28 03:16:11 UTC 2024 aarch64 GNU/Linux Now, I wanted to update RKNPU version from 0.9.7 to 0.9.8. So, again I recompiled the image with the updated drivers. Using Pi-imager flashed it onto an SD card. When I tried to boot I am getting the following error message from the serial output: ./compile.sh build BOARD=rock-5-itx BRANCH=vendor BUILD_DESKTOP=no BUILD_MINIMAL=yes EXPERT=yes KERNEL_CONFIGURE=yes RELEASE=bookworm DDR 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB Manufacturer ID:CH0 RX Vref:26.3%, TX Vref:21.0%,21.0% CH1 RX Vref:27.1%, TX Vref:22.0%,22.0% CH2 RX Vref:27.1%, TX Vref:24.0%,21.0% CH3 RX Vref:27.5%, TX Vref:21.0%,20.0% change to F1: 534MHz change to F2: 1320MHz change to F3: 1968MHz change to F0: 2400MHz out U-Boot SPL board init U-Boot SPL 2017.09-armbian-2017.09-S2284-P8c48-Hfac6-Ve5ad-Bda0a-R448a (Nov 20 2024 - 17:06:35) Trying to boot from MMC2 spl: partition error Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking uboot 0x00200000 ... sha256(af1962bdff...) + OK ## Checking fdt 0x00324010 ... sha256(e3b0c44298...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-2 0xff100000 ... sha256(70505bb764...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC ## Checking atf-3 0x000f0000 ... sha256(b2af21b504...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 813.644/1063.106 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2400MHz INFO: dfs DDR fsp_params[1].freq_mhz= 534MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1320MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1968MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb> initcall sequence 00000000002b8500 failed at call 00000000002aaf6c (err=-1) ### ERROR ### Please RESET the board ### I get the same error when I use the desktop image too: ./compile.sh build BOARD=rock-5-itx BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers desktop_tools internet programming' DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base EXPERT=yes KERNEL_CONFIGURE=yes RELEASE=bookworm But when I use the image downloaded from the armbian website is getting booted up without any issue and it has updated RKNPU drivers. But I have to build a kernel because I want the LSI MEGARAID drivers enabled. Also when I want to make RKNPU driver modular <M> it is unable to finish building the image with an error saying it is unable to find rknpu.ko. So, why is this happenning and is there a way to update the drivers without going through building the kernel? Thank you in advance and any help will be helpful.

and I must say that not only your passion, but also your dedication and commitment are truly inspiring for the whole community! One just cannot thank you guys for everything you have done! @fabiobassa @jock @ilmich Since @jock provided the experimental image on May 12th, i've been playing non-stop with this device, doing numerous flashing attempts and testing things out, just for fun... I must have spent 30+ hours on this ever since, mostly trying to compile things myself to run in the box, playing with the different overlays to test what works and what doesn't and learning about Tee, trust, op-tee,... You know those kids that when get their toys, they tear it apart instead? well... same feeling... the discovery passion thing... I'm preparing a report on my findings for my specific "MXQ-EP-2-V1.0" MoBo model, specially around on the working overlays, perhaps I can post it in the weekend.... And responding to my own question earlier about armbian minimal, in the armbian-config tool from the experimental image, there is an option to disable desktop... it gives you a system with only 25 tasks running and lower RAM usage than a DietPi. Now I begin to become interested on (re)assembling ROM images... I've been trying to replace some internet roms with the Trust Partitions and u-boot from the ROM I know it works... No successful test yet, but not sure if I'm repacking them correctly... Anyway, I'm learning a lot and that's great thanks to this community!

Good day JOCK. Thank you so much for linking to the latest armbian releases. I installed 25.5.0-trunk.444 and brought it to 25.8.0-trunk.26 by several updates. The system is loaded and steadily updated. Managed to configure ethernet and wifi with static addresses. The network works well. The question is that I can't figure out how to start bluetooth. At first, the system worked without overlays and tried to load BCM43342 when I connected overlay 6330 using armbian-config, nothing changed. I don't have too much experience in unix. What am I doing wrong? PS I attach a photo of the board and armmonitor -u)

I'm new to boards with linux and this is my very first attempt to install linux systems on board so there might be something that I cannot be aware of. I tried to install armbian v6.12 on the SD card but after I finish configureing the setup, the wifi doesn't work. Unfortunately I have no wires to connet to the board so now it is unable for me to connect the board to the internet. The problem is exactly the same as the post Wifi module AX210 - Orange Pi 5 Plus - Armbian Community Forums. I can see the network controller through `lspci -v`: And the dmesg shows that iwlwifi cannot find suitable version to use: And I indeed have the firmware I need under /usr/lib/firmware: (the one ended with 59) Unfortunately I have no wires to connet to the board so now I cannot use apt to update and upgrade the system and the firmware in it and cannot use Armbianmonitor.

How Has This Been Tested? build the armbian.img, flash to eMMC/USB drive，then boot and use it Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings Hardware Cainiao Logistics Terminal A311D Edition, detachable into two parts: the main unit and the base. Main Unit Amlogic A311D SoC, 2 GB DDR, 16 GB eMMC No SD card slot, so the A311D can only load FIP from eMMC. Gigabit Ethernet port and RTL8822CS WiFi/BT. One USB Type-C port for power and data transfer in USB download mode. When the main unit is used with the base, it is unclear if this Type-C can function as a Host under Linux, as it is obstructed by the base, making it difficult to plug in devices for testing. Base The base comes in different models, but the software should be universal. Equipped with a USB HUB, display (HDMI or VGA), and power supply (USB Type-C or DC). Debug Points Debug UART eMMC Shorting Point Armbian Peripheral Status Component Status GBE Working WiFi Working BT Working PWM Fan Working eMMC Working USB Working HDMI Display Working HDMI Audio Working Internal Speaker Not Working Power Button Working ADC Key Working Side Lights? Not Working Four Dots on Side Not Working (USB? SPI?) Installing Armbian The Amlogic USB Burning Tool uses a proprietary firmware format. Although the firmware extension is .img, it is not a disk image file. There are tools available for unpacking/repacking it: Amlogic binary only executable hzyitc/AmlImg 7Ji/ampack Repacking all system image .img files into USB flashing packages is not cost-effective. You can pack an FIP with mainline U-Boot into a USB flashing package to restore the device to a state with mainline U-Boot. Mainline U-Boot includes drivers for Ethernet, USB, and eMMC, which is sufficient for many tasks. An FIP with mainline U-Boot is available here. Flashing Mainline U-Boot Using dd Command If the device has a working system like Android or Linux with root access, you can simply write fip-with-mainline-uboot.bin to the eMMC: dd if=path-to-fip-with-mainline-uboot.bin of=/dev/mmcblk1 bs=512 seek=1 It is also recommended to flash the FIP to the eMMC boot area, as the A311D will try to load the FIP from the eMMC boot area if it cannot find it in the user area. On Linux, you can: # Check if write access to boot area is available blockdev --getro /dev/mmcblk1boot0 blockdev --getro /dev/mmcblk1boot1 # Unlock write access to boot area echo 0 | sudo tee /sys/block/mmcblk1boot0/force_ro echo 0 | sudo tee /sys/block/mmcblk1boot1/force_ro dd if=path-to-fip-with-mainline-uboot.bin of=/dev/mmcblk1boot0 bs=512 seek=1 dd if=path-to-fip-with-mainline-uboot.bin of=/dev/mmcblk1boot1 bs=512 seek=1 Using USB Download Mode If you cannot gain root access to the existing system on the device, you can use the Amlogic USB Burning Tool with the prepared USB flashing package fip-with-mainline-uboot.burn.img to directly flash mainline U-Boot to the eMMC. See Flashing eMMC in USB Download Mode for the USB download process. The Amlogic USB Burning Tool will write the FIP to the eMMC boot area. Flashing Armbian Image Flashing Armbian Image to USB Drive If you frequently test different systems, considering the lifespan of eMMC and convenience, you may prefer booting from a USB drive. Simply flash the .img file to a USB drive, insert it into the device, and power on. The mainline U-Boot on the eMMC will automatically scan devices like eMMC, USB, and Ethernet in sequence to find a suitable boot environment, such as a U-Boot script, extlinux, or TFTP. If the A311D still boots from eMMC, it means there is a bootable system on the eMMC. To force booting from USB, you need to destroy the system on the eMMC, such as by deleting the MBR partition table. Alternatively, in the U-Boot command line, enter setenv boot_targets usb0 && boot if you have a UART cable connected. Flashing Armbian Image to eMMC Method 1 This method requires a USB drive and network access for the device. First, flash the Armbian system image to a USB drive and boot the device from it. Then, transfer the system image to be installed to the USB drive via the network, and use the dd command to flash it to the eMMC: dd if=path-to-your-os-img of=/dev/mmcblk1 status=progress Alternatively, use a trick to avoid transferring the system image to the USB drive. On the Armbian system booted from the USB drive, install Netcat and run: nc -l -p 1234 > /dev/mmcblk1 On a Linux PC, install Netcat and run: nc -w 3 your-cainiao-cniot-core-ip 1234 < path-to-your-os-img Netcat has two variants: GNU and OpenBSD. If you have GNU Netcat installed on the PC, the command should be: nc -w 3 -c your-cainiao-cniot-core-ip 1234 < path-to-your-os-img To install OpenBSD Netcat: # ArchLinux sudo pacman -S openbsd-netcat # Ubuntu/Debian apt install netcat-openbsd To install GNU Netcat: # ArchLinux sudo pacman -S gnu-netcat # Ubuntu/Debian sudo apt install netcat-traditional Method 2 This method requires connecting the device's UART to a PC and ensuring both the device and PC are on the same LAN via Ethernet. First, place the system image to be installed on the Linux PC and rename it, e.g., armbian.img. Split the image on the Linux PC, as the device's memory cannot hold the entire image at once: split -b 512M armbian.img armbian.img. # Assume armbian.img is split into armbian.img.aa, armbian.img.ab, armbian.img.ac; note the filenames. Set up a TFTP server on the PC. Windows users can use Tftpd64. On Linux, use a similar tool like puhitaku/tftp-now. Download the binary from Releases, install it to PATH, and run sudo tftp-now serve -root dir-to-armbian.img.aX. When powering on the device, press the spacebar in the UART session to enter the U-Boot command line. Configure the device's network: setenv ipaddr 172.24.0.241 setenv netmask 255.255.252.0 setenv gatewayip 172.24.0.1 setenv serverip 172.24.0.248 The IP 172.24.0.248 is the PC's IP. Set the RAM address for temporarily storing the image: setenv loadaddr 0x20000000 Start downloading the image from the PC's TFTP server and write it to the eMMC: setenv mmcscript 'setenv files "armbian.img.aa armbian.img.ab armbian.img.ac"; setenv offset 0x0; for file in ${files}; do tftpboot ${loadaddr} ${file}; setexpr nblk ${filesize} / 0x200; mmc write ${loadaddr} ${offset} ${nblk}; setexpr offset ${offset} + ${nblk}; done' mmc dev 1 && run mmcscript Finally, reboot the device. Flashing eMMC in USB Download Mode The USB Type-C port on the main unit is the USB download port. Shorting the eMMC shorting point and powering on will put the device into USB download mode. Alternatively, while the device is running, you can erase the header of the eMMC user/boot area and reboot to enter USB download mode. Example commands: # Under Linux sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1MiB count=4 status=progress echo 0 | sudo tee /sys/block/mmcblk1boot0/force_ro echo 0 | sudo tee /sys/block/mmcblk1boot1/force_ro sudo dd if=/dev/zero of=/dev/mmcblk1boot0 bs=1MiB count=4 status=progress sudo dd if=/dev/zero of=/dev/mmcblk1boot1 bs=1MiB count=4 status=progress # Under U-Boot command line mmc dev 1 mmc erase 0 8192 mmc partconf 1 1 1 1 mmc erase 0 8192 mmc partconf 1 1 2 2 mmc erase 0 8192 Finally, use Amlogic USB Burning Tool v2.x.x to flash the image. View the full article

My ROCK5B is still at customs or package handling company, but I just did a quick test on my ROCK3A w.r.t. 3.5mm audio. It is headless running multi-user.target (NAS/server), Armbian Bookworm with beta repo. But it has KDE installed, so if I would do 'sudo systemctl isolate graphical.target', it flips to KDE Plasma5 GUI (that is what I do on NanoPi-R6C currently, it is cloned from there). I did manually put Radxa 2017 dated U-Boot blob in SPI-flash, so bootfs+rootfs from NVMe and also has native SATA on M.2 E-key slot. I full-upgrade every now and then (via ssh). Via ssh as normal user, I started playing some opus file with mpv, then plugged in my good old Sennheiser headset and simply good audio. See commands below. alsamixer shows a lot of I/O hardware, like I2S etc, but also some port that is or must be the 3.5mm (HP is that I think). I did not change settings. In pulsemixer I saw 2 stereo output devices, it should be HDMI and the audio chip RK809. I did disable one to 'off', (random guess, maybe not needed, hdmi off is what I aimed for) Also good to know that I removed/disabled pipewire, I still get a warning from mpv, something with 'pw.conf', but pulseaudio is used (forced that once in the past actually). user@rock3a:~$ uptime 09:45:33 up 18 days, 17:23, 2 users, load average: 0.66, 0.49, 0.46 user@rock3a:~$ uname -a Linux rock3a 6.1.115-vendor-rk35xx #1 SMP Thu Apr 24 23:11:15 UTC 2025 aarch64 GNU/Linux user@rock3a:~$ alsamixer user@rock3a:~$ pulsemixer The OPi5Max might have completely different audio chip and/or bindings, then of course the test with ROCK3A is maybe irrelevant. But anyway, I want to know if I can use 3.5mm audio or not. I use(d) it on RPI4B with does not even have a proper audio chip. I have some background pulseaudio user .service started, that works great as audio sink on other computers.

Guys, does anyone know how to enable the TV Box's wifi with the ik316 process? I downloaded armbian, the only thing missing is wifi. Data transmission works with a network cable, only the wifi is having problems. The iso I downloaded was Armbian-unofficial_25.05.0-trunk_X96q-lpddr3_bookworm_edge_6.12.11_xfce_desktop.img.xz