All Activity

I compiled Linux from hardkernel--it works with the devicetree from petitboot firmware. There's a emmc-data-4b node (not in their source code) which does: &emmc_conf_pull_up { mux { drive-strength = <3>; groups = "emmc_nand_d0", "emmc_nand_d1", "emmc_nand_d2", "emmc_nand_d3"; function = "emmc"; input-enable; bias-pull-up; }; }; Doing this with mainline e.g. overlay=g12b-odroid-n2-spi didn't work here. No option to wakeup (ir, lan, keyboard) is another reason to stick with 4.9.

Subject: Bluetooth: Unknown BR/EDR signaling command 0x16 / Wrong link type (-22) on meson-gx / Banana Pi M2 Pro Description: When connecting modern Android (POCO F7) and Windows/Linux devices (Lenovo Legion) via Bluetooth to Banana Pi M2 Pro, the dmesg log gets flooded with BR/EDR signaling errors during connection/disconnection phases. Steps taken: - Forced 'ControllerMode = bredr' in /etc/bluetooth/main.conf - Disabled USB autosuspend for the BT controller (set to -1) Logs: [ 345.122975] Bluetooth: Unknown BR/EDR signaling command 0x16 [ 345.123005] Bluetooth: Wrong link type (-22) Environment: - Board: Banana Pi M2 Pro (Amlogic S905X3) - Kernel version: 6.18.34-current-meson64 nano armbianEnv.txt extraargs=usbcore.autosuspend=-1 The problem with Bluetooth on bananapim2pro is that I constantly have trouble connecting. My tweaks to the settings fixed it somewhat, but not 100%... Finally, if all else fails, I use this method: sudo rmmod btusb sudo modprobe btusb sudo systemctl restart bluetooth sudo systemctl restart bluealsa But I have a question: are there any kernel/driver fixes or updates for this Bluetooth model?

Hello guys, i got 2 old fullbox rikomagic mk802 stick android mini pc. Variant Allwinner A10,Ram 512Mb. I tested armbian 26.05 via 4 config : limea1000 boot ok pcduino1 ok cubieboard ok olimex a10 lime stuck at boot os stage, same with official debian 3.4 kernel images of olimex enabled video output for desktop environment. It boot but will take a lot of time to finish

Hello, I believe @m1zfs's work on the DKMS modules is available here: https://github.com/vitalijborissow/rk3568-npu-ODROID-M1 I have spent many hours trying to get the NPU working on my ODROID-M1 (8 GB) running Armbian 26.5.1 with current kernel 6.18.x as well as edge kernels 6.19 and 7.1. I also tried building the latest Armbian image from source (July 19 build including U-Boot 2026.07), but so far I have not been able to get the device tree / overlay and DKMS modules from the repository working on any of these combinations. The system always fails to boot. Fortunately, I can capture the boot process through the serial console and see where it fails. The log shows a kernel exception related to enabling the RK3568 NPU power domain: rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', val=0x1ee platform fde40000.npu: Adding to iommu group 3 Internal error: synchronous external abort ... Workqueue: pm genpd_power_off_work_fn ... rockchip_pd_power From the log it appears that the crash occurs before rknpu.ko is loaded. This makes me believe the issue is more likely related to the device tree, overlay, power-domain, regulator, or clock configuration rather than to the DKMS module itself. Has anyone seen a similar issue on recent Armbian kernels, or can suggest a direction for further troubleshooting? I am still willing to spend some time investigating this and would appreciate any ideas or hints.

OK great that you got it working now! 2GB RAM works fine for HA, at least when running Supervised. I am not sure if Armbian can improve more when Supervised, as this is not supported anymore from the providers/developers of Home Assistant. I think a reason people go from SBC to Intel NUC is because there are things like VMware that IT pros might know from their profession/company. And RPL very long by default had/advised to use 32-bit also on more capable devices like RPi4 with 2GB RAM or even more. And also running from SD-card, and those wear out under high load and many writes. The whole problem with 'traditional RPi' is that it is unusual 32-bit ARMv6 build and not the standard 32-bit ARMv7 which is the minimum for support from Debian and most other distros. And in addition, 32-bit builds do not support the standard Linux Kernel Virtual Machine HW, standard in all 64-bit capable CPU's. Intel/AMD CPU's have support for HW virtualization also for 32-bit and much more known and commercial (also closed-source) hypervisors like VMware are pushed a lot more then the standard Linux build-in QEMU/libvirtd/KVM. So with 64-bit Linux, especially also on ARM, you get it by 'apt install virt-manager' and then you can run other OSses/images at full HW speed and is separated from the host OS, e.g. Armbian. Because images, many files or bigger databases are a burden for simple SD-card. Also because multiple OSses at the same time, it easily needs more RAM than the usual 1GB on SBC's like RPI3. Via virt-manager GUI and also CLI tool virsh, you can then run the generic UEFI bootable HAOS. For long-term and decent 24/7 operation, you will need SSD for storage. RPi's don't have that, you need adapters and HATs etc. But many other SBC's do have, so if you have an unused NVME for example, it fits perfectly in RK388 boards like ROCK5B for example. It is 4-lane PCI-E v3, so similar speed as Intel miniPC's. And most important, lower power consumption for similar total system price, at least before the RAM+storage prices went sky high. I measured my NanoPi-R6C with Samsung 970 NVME and Armbian Trixie (6.1.115 kernel) and is about 1.5 Watt when idle or doing some light tasks like running simple initial HAOS as Virtual Machine. See also:

You are not the 1st to do this: Let me explain the problem first. The CPU itself, without any storage attached, has a built-in U-Boot. However, this U-Boot does not initialize video output, so you won't be able to see it on an HDMI screen. (The good news is that it usually initializes the serial port.) This U-Boot reads environmental data from a data blob on the MMC (usually within the first 10 MB of the disk). This environmental data tells the U-Boot the sequence of commands needed for the MMC/USB U-Boot to boot. Once the MMC/USB U-Boot boots, you get video output. The problem is that you deleted the data blob containing the environmental data from the MMC, so the CPU's U-Boot does nothing. It just loops, saying that it found no device to boot. If you have a serial adapter, it is possible to interact with this CPU U-Boot. Pressing Ctrl+C (in a terminal that does not intercept Ctrl+C—my advice is to use PuTTY, even on Linux) should stop whatever it is doing. By interacting with this CPU U-Boot, you can instruct it how to boot your MMC or USB U-Boot. However, you will have to do this manually every time you boot. To fix the issue, you need to restore that data blob containing the properties to its specific location on the MMC. I don't know where it starts or what format it uses, so I was unable to recreate one from scratch. My way of fixing this was to find a backup of the original MMC and restore the first GB. So, did you make a backup? If yes, you can restore it with some serial magic. If you did not make a backup, you can search for one or ask someone who has one. (check that this thread for the other guy's solution)

wifi works fine on our rock 5B+ board with the 6.18 Gnome build...

Yes. commit 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 Author: EvilOlaf <werner@armbian.com> Date: Thu Feb 26 18:09:38 2026 +0000 rockchip64: 7.0: Rebase on top of main diff --git a/patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml b/patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml rename to patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml diff --git a/patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch b/patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch rename to patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch :

Hi domillo, If the green light has started flashing, it may indicate that the system has been started, but at this point, we cannot determine the IP address of the Cubie a5e. Once you have a UART adapter, please try to capture the DRAM parameters of the Cubie a5e according to this document: radxa-cubie-a5e-u-boot/README.md Guation

WOL might work on a newer 6.18 release of the kernel. Btw do I have it right that you're using Armbian without OMV?

Thank you for the information mmgen, One thing you missed is the ffmpeg compilation information. Run: $ ffmpeg It will print out the ffmpeg version and all the libraries that were enabled, and all the libav* libraries it has compiled along with ffmpeg (libav* are parts of the ffmpeg project). The interesting information is whether it uses the "v4l2-request" library, which lets ffmpeg control a part of the kernel that controls the hardware decoder. When you run mpv -v yourvideo.mp4 you could also see v4l2request, or some other message about the hardware acceleration (at this point I doubt that v4l2request is used, because it works better in newer kernels)

Small update: the patch series on GitHub is now up to date with what I actually run on the board. It went from 106 to 129 patches, all on vanilla 6.18.38. https://github.com/ut-slayer/orangepi-4a-mainline What's new since the last drop: The GPU was running at the wrong frequencies (and now it isn't). This is the interesting one. The A523 GPU clock is not a linear divider — it's a cycle-masking one: rate = source * (16 - M) / 16. Everyone modelled it as linear, including the vendor BSP. The practical effect: what the kernel labelled "150/200/300/400/600 MHz" was really running at 487/648/560/750/599 MHz. So the GPU was faster than advertised, and thermal throttling to "400 MHz" actually raised the clock to 750. To be clear: nothing was ever unsafe. It ran like that for weeks, stable, at 920 mV, with temperatures in the normal range — the chip simply tolerates it. But the labels were wrong, throttling did the opposite of what it should, and you cannot tune power/performance on numbers that aren't real. Now the five operating points measure 149/199/300/399/597 MHz with the Mali cycle counter, from the intended parents. Credit where it's due: Chen-Yu Tsai spotted the fractional divider while reviewing a patch I sent upstream. That review also produced a Reviewed-by for the generic clk fix, which is now on the lists. PCIe / M.2. The controller and the Innosilicon combo PHY now probe, link training runs and the root port enumerates. I want to be honest about the limit of that statement: I don't own an NVMe drive, so I have only tested it with an empty slot. The bus comes up and behaves; whether a real drive negotiates, enumerates and performs is something I genuinely cannot confirm. If anyone here has an M.2 NVMe in this board, that report would be very welcome — including a failure report, which is just as useful. (Kernel side comes from Marvin Wewer's Armbian series, authorship preserved, plus a 1-lane fix from the BSP and the device-tree wiring for this board.) Hardware video decode works for H.264/H.265. With the cedar-ve shim in this tree plus the Allwinner userspace (libcedarc + gstreamer1.0-omx), YouTube plays smoothly in a WebKit browser (I use Cog). VP8/VP9 do not — that engine never raises its interrupt — so those codecs are capped and YouTube negotiates H.264 instead. Note the userspace half is not in the patch series and not in the published images yet. Also in: a display fix for a frame that could get stuck after direct-scanout transitions, and JOYDEV/UINPUT enabled (analog sticks were dead in software that opens /dev/input/jsN first). Images: the published v0.2 images are now well behind this. Refreshed Debian images (Desktop and CLI) built on this kernel are in preparation. No date promised — they go up when they're tested. Thanks again to everyone testing and reporting here; the eMMC and 4 GB confirmations came from this thread, and the PCIe work started because someone took the trouble to diagnose why NVMe didn't show up.

Uhm... What repository is that commit hash for? I tried armbian/build and armbian/linux and a couple of others but it doesn't seem to belong there. I don't expect this to be a single-day task. I'm OK to invest the time in finding out what happened and run a bunch of bisections, even if that needs to include both Armbian tool repos and the Linux kernel repo. I just need some pointers to what the right approach is here and what kind of scripts/setup I should be running for each iteration. I would expect having this procedure documented can help other people too, so I'd be happy to do some write up for it. I can think that: Maybe there's a way to provide a kernel repo commit to check out to the build infrastructure and get kernel packages built from that. I should be able to just sync the build scripts to whatever was current when 6.19 was released. Maybe there's some way to just "compile and install the kernel the old way" and ignore the packages part of it. But I'm not familiar with the uboot specific formats for images and initial ram disks and I fear the result of doing that might be missing patches or some other things and not be comparable to the package-based experience. And, yes, 6.19 might be some time ago, but AFAIU -current is still based on 6.18... next time that gets bumped up breakage will stop being "optional" for me.

It'll have kernel 6.18 on edge soon with working fans.

Good Morning together, I tried installing the image from here radxa-cubie-a5e-armbian-build@202f1bf. Unfortunately for me booting my 1gb Cubie a5e failed. The green flashlight is blinking (first a bit slower than a bit faster) which seems an improvement to the version before (static green light, no blinking) As soon as I'm getting a UART Adapter, I'll hopefully get some more insights about whats going wrong cheers.

It should be / it was reported fixed a week ago, but you need to make image on your own or use nightly automated builds.

Maybe not the right place but the same happened on my OP5Ultra. The latest kernel stopped the internal WiFi module. Falling back to again 6.1.115 did the trick. So both Radxa 5B plus and OP5 ultra suffer the same problem when installing the latest Armbian Ubuntu. I assume other boards have similar problems... Ernst-Jan

This week's updates center on new hardware enablement, a broad U-Boot v2026.07 modernization, and build system hardening for toolchain and infrastructure changes. Board support expanded across multiple SoC families, including the X88 PRO RK3566 TV box, Avnet MaaXBoard 8ULP (i.MX8ULP), EASY EAI Nano (RV1126), and the AYN Odin3. The Youyeetoo R1 v3 was promoted to standard support with named audio outputs, while the Radxa Dragon Q8B gained an edge kernel (7.1) target. Rockchip work included RK3588 CAN support for kernels 6.18/7.1/7.2, HDMI-RX fixes on the OrangePi 5 Ultra, and Mixtile Blade3 refinements on the 7.2 bleeding edge. A coordinated U-Boot bump to v2026.07 landed across Helios4, Odroid HC4/M1, Turing RK1, Radxa E52C, Qidi X6, Mekotronics R58X-Pro, and the Espressobin/Macchiatobin (paired with TF-A 2.14.0). This surfaced toolchain issues on Trixie, addressed through SWIG 4.3 pylibfdt compatibility, demotion of gcc 14 int-conversion and implicit-declaration errors to warnings, and related pin cleanups. Infrastructure work strengthened build reliability and CI. The rootfs stage gained DNS fallback and apt retry hardening for chroot operations, armbian-firstlogin received power-loss recovery with atomic writes, and armbian-install now reports bootloader write failures explicitly. Docker framework updates enable native riscv64 image generation on trixie and noble runners, while new extensions introduce sysrq serial trigger, kernel-debug tiers, ram-boot via rkusbboot, and generic SATA park-on-shutdown enabled by default on the Odroid HC4. #Armbian #EmbeddedLinux #UBoot #Rockchip #RISCV ChangesAdd support for X88 PRO RK3566 TV box. by @Ovaday in armbian/linux-rockchip#500Add AI-driven README updater (central, cross-repo). by @igorpecovnik in armbian/armbian.github.io#359Add Avnet MaaXBoard 8ULP (i.MX8ULP) support. by @govindsi in armbian/build#9991Add AYN Odin3 firmware. by @kasimling in armbian/firmware#136Add ayn-odin3 board image. by @kasimling in armbian/armbian.github.io#358Add board: EASY EAI Nano RV1126. by @hqnicolas in armbian/build#10154Add minimal SWT6621S firmware support for KICKPI K3B. by @retro98boy in armbian/firmware#134armbian-firstlogin: power-loss recovery and atomic writes. by @mingzhangqun in armbian/build#9954armbian-install: report bootloader write failures instead of "Done.". by @iav in armbian/build#10204artifact-rootfs: surface git-log failure when computing configng hash. by @igorpecovnik in armbian/build#9849board: aml-c400-plus: Fix eMMC boot format and partition layout. by @jomadeto in armbian/build#9911boards/easy-eai-nano: enable usb and brcm wifi. by @hqnicolas in armbian/build#10177brcm: add brcmfmac firmware aliases for easy-eai nano (rv1126). by @igorpecovnik in armbian/firmware#133bsp: generic SATA park-on-shutdown (HDD_PARK_ON_SHUTDOWN), enable on Odroid HC4. by @igorpecovnik in armbian/build#10191bsp: use kernel version argument in ABL postinst scripts (fixes #10108). by @rorystandley in armbian/build#10109can: rockchip: add RK3588 CAN support (for kernel v6.18 / v7.1 / v7.2). by @lch08 in armbian/build#10184ci(board-assets): don't check out fork head under pull_request_target. by @igorpecovnik in armbian/build#10194cix-acpi: bump edge to 7.1.y. by @EvilOlaf in armbian/build#10167Cleanup patches. by @EvilOlaf in armbian/build#10174csc board: NORCO EMB-3531: Do not reset LTE moden. by @retro98boy in armbian/build#10222docker/framework: build riscv64 images on native runners (trixie, noble). by @igorpecovnik in armbian/docker-armbian-build#34docker/framework: generate riscv64 images (trixie, noble, resolute). by @igorpecovnik in armbian/docker-armbian-build#33docker/riscv64: fix cross-compiler availability for generate-dockerfile. by @igorpecovnik in armbian/build#9589docker: allow overriding host_arch for foreign-arch Dockerfile generation. by @igorpecovnik in armbian/build#10211docs: refresh README (AI-assisted). by @igorpecovnik in armbian/ci#29Enable memory compaction and RK630 PHY on Rockchip vendor kernels . by @lukaszsobala in armbian/build#10175Enable pwm gpio. by @frank-f in armbian/build#10238extensions/nvidia: per-distro version detection + runtime auto-disable on no-GPU hosts. by @igorpecovnik in armbian/build#9845extensions/radxa-aic8800: use local dir as download cache. by @rpardini in armbian/build#10156extensions/rkusbboot: easy ramboot mainline u-boot on Rockchip devices. by @rpardini in armbian/build#10158feat(extensions): sysrq-serial-trigger + kernel-debug-tiers (on-device kernel debugging via serial console). by @iav in armbian/build#9776feat(flash): keep the success screen when verification is cancelled. by @SuperKali in armbian/imager#166Fix build for Linux 7.1. by @EvilOlaf in armbian/bcmdhd-dkms#7fix hdmi rx on orangepi5 ultra by adding hpd-gpios. by @pdapandapda in armbian/build#10172fix Radxa U-Boot ITB dependency. by @yisding in armbian/build#10196Fix sata2 target-supply for Orange Pi 3B and Station M2. by @dust-7 in armbian/build#10137fix the hdmirx HPD patch against kernel6.18 & kernel 7.1. by @pdapandapda in armbian/build#10180fix(offline): honor OFFLINE_WORK in git-ref2info and memoize TTL. by @iav in armbian/build#9797gha: disable build cronjobs (moved to armbian/ci). by @igorpecovnik in armbian/os#482git: match safe.directory literally, not as a regex. by @igorpecovnik in armbian/build#10223git: silence spurious SUBSHELL error annotation from safe.directory check. by @igorpecovnik in armbian/build#10225helios4: bump u-boot to v2026.07. by @iav in armbian/build#10183helios4: drop stale u-boot patch dir v2025.10/board_helios4. by @iav in armbian/build#10189input: remotectl: rockchip-pwm: prefer dedicated channel-3 IRQ. by @rpardini in armbian/linux-rockchip#503k3: sk-am62-lp: shrink R5 SPL to fit SRAM + silence k3 cp noise. by @igorpecovnik in armbian/build#10230luckfox-lyra-ultra-w: Add spidev overlay with 2 CS. by @vidplace7 in armbian/linux-rockchip#505mainline: bump bleedingedge to v7.2-rc3. by @EvilOlaf in armbian/build#10181mekotronics-r58x-pro: u-boot: bump to v2026.07. by @rpardini in armbian/build#10232mixtile-blade3: edge: u-boot: fancy it up (lwIP, mbedTLS, efi, btrfs, etc). by @rpardini in armbian/build#10234mvebu64: modernize EspressoBin/MacchiatoBin firmware (u-boot 2026.07 + TF-A 2.14.0 + A3720 fixes). by @igorpecovnik in armbian/build#10213odroidhc4: u-boot: bump to v2026.07, drop upstreamed patch. by @rpardini in armbian/build#10233odroidm1: bump u-boot to v2026.07. by @iav in armbian/build#10201Qidi X6: update to u-boot 2026.07. by @Shadowrom2020 in armbian/build#10228radxa-dragon-q8b: add edge kernel (7.1) target. by @SuperKali in armbian/build#10215radxa-e52c: bump uboot to v2026.07. by @okrc in armbian/build#10135Rk3588 es8388 codec silence log. by @CT1IQI in armbian/build#10198rockchip64-6.18: rework rk3588-0010-fix-clk-divisions to avoid patching include/linux/math.h. by @rpardini in armbian/build#10207rockchip64-7.2: bleedingedge: enable REALTEK_PHY_HWMON. by @rpardini in armbian/build#10206rockchip64-7.2: rk3588-mixtile-blade3, many fixes and additions. by @rpardini in armbian/build#10203rootfs-image: move pre_install_distribution_specific inside install_distribution_specific(). by @rpardini in armbian/build#10157rootfs: DNS fallback for build-time chroot resolv.conf. by @igorpecovnik in armbian/build#10205rootfs: harden chroot apt against transient fetch failures (retries + fail-fast update). by @igorpecovnik in armbian/build#10202rootfs: pin tar for resolute kernel deb install (all families). by @igorpecovnik in armbian/build#10187rootfs: revert resolute tar pin (#10187) — fixed upstream. by @igorpecovnik in armbian/build#10209runner-clean: drop stale amlogic FIP source caches. by @igorpecovnik in armbian/actions#28runner-clean: ensure tree is installed on the host. by @igorpecovnik in armbian/actions#27runner-clean: register qemu binfmt handlers on the host. by @igorpecovnik in armbian/actions#26sc8280xp: fix wrong LINUXCONFIG name for the sc8280xp branch. by @igorpecovnik in armbian/build#10227SpacemiT: Defconfig: Enable CONFIG_PWM_PXA. by @fkpwolf in armbian/build#10182sun55iw3-syterkit: skip TF-A build (SyterKit is self-contained). by @igorpecovnik in armbian/build#10214targets: drop resolute from riscv64 userspace builds (RVA23 vs RV64GC). by @igorpecovnik in armbian/ci#27turing-rk1: bump u-boot v2024.04 → v2026.07 (fix SWIG 4.3 build break on trixie). by @igorpecovnik in armbian/build#10216u-boot: bump 2026.07-rc4/rc5 pins to final v2026.07. by @igorpecovnik in armbian/build#10186u-boot: don't error on implicit declarations (gcc ≥ 14 / trixie). by @igorpecovnik in armbian/build#10221u-boot: fix old pylibfdt build against SWIG ≥ 4.3 (trixie). by @igorpecovnik in armbian/build#10217u-boot: sync btrfs zstd short-extent fix into shadowed board/pool copies. by @iav in armbian/build#10208uboot: demote int-conversion & incompatible-pointer-types to warnings (gcc 14). by @igorpecovnik in armbian/build#10224Up rtw8822b to v30.20.0. by @farwayer in armbian/firmware#135update Helios4 BSP postinst. by @leggewie in armbian/build#9065workflows: add Delete Old Releases (copied from os). by @igorpecovnik in armbian/ci#26workflows: enable build cronjobs (taking over from armbian/os). by @igorpecovnik in armbian/ci#25youyeetoo-r1-v3: bump mainline u-boot to v2026.04. by @SuperKali in armbian/build#10219youyeetoo-r1-v3: promote to standard support and name audio outputs. by @SuperKali in armbian/build#10220View the full article

This week's updates center on new hardware enablement, a broad U-Boot v2026.07 modernization, and build system hardening for toolchain and infrastructure changes. Board support expanded across multiple SoC families, including the X88 PRO RK3566 TV box, Avnet MaaXBoard 8ULP (i.MX8ULP), EASY EAI Nano (RV1126), and the AYN Odin3. The Youyeetoo R1 v3 was promoted to standard support with named audio outputs, while the Radxa Dragon Q8B gained an edge kernel (7.1) target. Rockchip work included RK3588 CAN support for kernels 6.18/7.1/7.2, HDMI-RX fixes on the OrangePi 5 Ultra, and Mixtile Blade3 refinements on the 7.2 bleeding edge. A coordinated U-Boot bump to v2026.07 landed across Helios4, Odroid HC4/M1, Turing RK1, Radxa E52C, Qidi X6, Mekotronics R58X-Pro, and the Espressobin/Macchiatobin (paired with TF-A 2.14.0). This surfaced toolchain issues on Trixie, addressed through SWIG 4.3 pylibfdt compatibility, demotion of gcc 14 int-conversion and implicit-declaration errors to warnings, and related pin cleanups. Infrastructure work strengthened build reliability and CI. The rootfs stage gained DNS fallback and apt retry hardening for chroot operations, armbian-firstlogin received power-loss recovery with atomic writes, and armbian-install now reports bootloader write failures explicitly. Docker framework updates enable native riscv64 image generation on trixie and noble runners, while new extensions introduce sysrq serial trigger, kernel-debug tiers, ram-boot via rkusbboot, and generic SATA park-on-shutdown enabled by default on the Odroid HC4. #Armbian #EmbeddedLinux #UBoot #Rockchip #RISCV ChangesAdd support for X88 PRO RK3566 TV box. by @Ovaday in armbian/linux-rockchip#500Add AI-driven README updater (central, cross-repo). by @igorpecovnik in armbian/armbian.github.io#359Add Avnet MaaXBoard 8ULP (i.MX8ULP) support. by @govindsi in armbian/build#9991Add AYN Odin3 firmware. by @kasimling in armbian/firmware#136Add ayn-odin3 board image. by @kasimling in armbian/armbian.github.io#358Add board: EASY EAI Nano RV1126. by @hqnicolas in armbian/build#10154Add minimal SWT6621S firmware support for KICKPI K3B. by @retro98boy in armbian/firmware#134armbian-firstlogin: power-loss recovery and atomic writes. by @mingzhangqun in armbian/build#9954armbian-install: report bootloader write failures instead of "Done.". by @iav in armbian/build#10204artifact-rootfs: surface git-log failure when computing configng hash. by @igorpecovnik in armbian/build#9849board: aml-c400-plus: Fix eMMC boot format and partition layout. by @jomadeto in armbian/build#9911boards/easy-eai-nano: enable usb and brcm wifi. by @hqnicolas in armbian/build#10177brcm: add brcmfmac firmware aliases for easy-eai nano (rv1126). by @igorpecovnik in armbian/firmware#133bsp: generic SATA park-on-shutdown (HDD_PARK_ON_SHUTDOWN), enable on Odroid HC4. by @igorpecovnik in armbian/build#10191bsp: use kernel version argument in ABL postinst scripts (fixes #10108). by @rorystandley in armbian/build#10109can: rockchip: add RK3588 CAN support (for kernel v6.18 / v7.1 / v7.2). by @lch08 in armbian/build#10184ci(board-assets): don't check out fork head under pull_request_target. by @igorpecovnik in armbian/build#10194cix-acpi: bump edge to 7.1.y. by @EvilOlaf in armbian/build#10167Cleanup patches. by @EvilOlaf in armbian/build#10174csc board: NORCO EMB-3531: Do not reset LTE moden. by @retro98boy in armbian/build#10222docker/framework: build riscv64 images on native runners (trixie, noble). by @igorpecovnik in armbian/docker-armbian-build#34docker/framework: generate riscv64 images (trixie, noble, resolute). by @igorpecovnik in armbian/docker-armbian-build#33docker/riscv64: fix cross-compiler availability for generate-dockerfile. by @igorpecovnik in armbian/build#9589docker: allow overriding host_arch for foreign-arch Dockerfile generation. by @igorpecovnik in armbian/build#10211docs: refresh README (AI-assisted). by @igorpecovnik in armbian/ci#29Enable memory compaction and RK630 PHY on Rockchip vendor kernels . by @lukaszsobala in armbian/build#10175Enable pwm gpio. by @frank-f in armbian/build#10238extensions/nvidia: per-distro version detection + runtime auto-disable on no-GPU hosts. by @igorpecovnik in armbian/build#9845extensions/radxa-aic8800: use local dir as download cache. by @rpardini in armbian/build#10156extensions/rkusbboot: easy ramboot mainline u-boot on Rockchip devices. by @rpardini in armbian/build#10158feat(extensions): sysrq-serial-trigger + kernel-debug-tiers (on-device kernel debugging via serial console). by @iav in armbian/build#9776feat(flash): keep the success screen when verification is cancelled. by @SuperKali in armbian/imager#166Fix build for Linux 7.1. by @EvilOlaf in armbian/bcmdhd-dkms#7fix hdmi rx on orangepi5 ultra by adding hpd-gpios. by @pdapandapda in armbian/build#10172fix Radxa U-Boot ITB dependency. by @yisding in armbian/build#10196Fix sata2 target-supply for Orange Pi 3B and Station M2. by @dust-7 in armbian/build#10137fix the hdmirx HPD patch against kernel6.18 & kernel 7.1. by @pdapandapda in armbian/build#10180fix(offline): honor OFFLINE_WORK in git-ref2info and memoize TTL. by @iav in armbian/build#9797gha: disable build cronjobs (moved to armbian/ci). by @igorpecovnik in armbian/os#482git: match safe.directory literally, not as a regex. by @igorpecovnik in armbian/build#10223git: silence spurious SUBSHELL error annotation from safe.directory check. by @igorpecovnik in armbian/build#10225helios4: bump u-boot to v2026.07. by @iav in armbian/build#10183helios4: drop stale u-boot patch dir v2025.10/board_helios4. by @iav in armbian/build#10189input: remotectl: rockchip-pwm: prefer dedicated channel-3 IRQ. by @rpardini in armbian/linux-rockchip#503k3: sk-am62-lp: shrink R5 SPL to fit SRAM + silence k3 cp noise. by @igorpecovnik in armbian/build#10230luckfox-lyra-ultra-w: Add spidev overlay with 2 CS. by @vidplace7 in armbian/linux-rockchip#505mainline: bump bleedingedge to v7.2-rc3. by @EvilOlaf in armbian/build#10181mekotronics-r58x-pro: u-boot: bump to v2026.07. by @rpardini in armbian/build#10232mixtile-blade3: edge: u-boot: fancy it up (lwIP, mbedTLS, efi, btrfs, etc). by @rpardini in armbian/build#10234mvebu64: modernize EspressoBin/MacchiatoBin firmware (u-boot 2026.07 + TF-A 2.14.0 + A3720 fixes). by @igorpecovnik in armbian/build#10213odroidhc4: u-boot: bump to v2026.07, drop upstreamed patch. by @rpardini in armbian/build#10233odroidm1: bump u-boot to v2026.07. by @iav in armbian/build#10201Qidi X6: update to u-boot 2026.07. by @Shadowrom2020 in armbian/build#10228radxa-dragon-q8b: add edge kernel (7.1) target. by @SuperKali in armbian/build#10215radxa-e52c: bump uboot to v2026.07. by @okrc in armbian/build#10135Rk3588 es8388 codec silence log. by @CT1IQI in armbian/build#10198rockchip64-6.18: rework rk3588-0010-fix-clk-divisions to avoid patching include/linux/math.h. by @rpardini in armbian/build#10207rockchip64-7.2: bleedingedge: enable REALTEK_PHY_HWMON. by @rpardini in armbian/build#10206rockchip64-7.2: rk3588-mixtile-blade3, many fixes and additions. by @rpardini in armbian/build#10203rootfs-image: move pre_install_distribution_specific inside install_distribution_specific(). by @rpardini in armbian/build#10157rootfs: DNS fallback for build-time chroot resolv.conf. by @igorpecovnik in armbian/build#10205rootfs: harden chroot apt against transient fetch failures (retries + fail-fast update). by @igorpecovnik in armbian/build#10202rootfs: pin tar for resolute kernel deb install (all families). by @igorpecovnik in armbian/build#10187rootfs: revert resolute tar pin (#10187) — fixed upstream. by @igorpecovnik in armbian/build#10209runner-clean: drop stale amlogic FIP source caches. by @igorpecovnik in armbian/actions#28runner-clean: ensure tree is installed on the host. by @igorpecovnik in armbian/actions#27runner-clean: register qemu binfmt handlers on the host. by @igorpecovnik in armbian/actions#26sc8280xp: fix wrong LINUXCONFIG name for the sc8280xp branch. by @igorpecovnik in armbian/build#10227SpacemiT: Defconfig: Enable CONFIG_PWM_PXA. by @fkpwolf in armbian/build#10182sun55iw3-syterkit: skip TF-A build (SyterKit is self-contained). by @igorpecovnik in armbian/build#10214targets: drop resolute from riscv64 userspace builds (RVA23 vs RV64GC). by @igorpecovnik in armbian/ci#27turing-rk1: bump u-boot v2024.04 → v2026.07 (fix SWIG 4.3 build break on trixie). by @igorpecovnik in armbian/build#10216u-boot: bump 2026.07-rc4/rc5 pins to final v2026.07. by @igorpecovnik in armbian/build#10186u-boot: don't error on implicit declarations (gcc ≥ 14 / trixie). by @igorpecovnik in armbian/build#10221u-boot: fix old pylibfdt build against SWIG ≥ 4.3 (trixie). by @igorpecovnik in armbian/build#10217u-boot: sync btrfs zstd short-extent fix into shadowed board/pool copies. by @iav in armbian/build#10208uboot: demote int-conversion & incompatible-pointer-types to warnings (gcc 14). by @igorpecovnik in armbian/build#10224Up rtw8822b to v30.20.0. by @farwayer in armbian/firmware#135update Helios4 BSP postinst. by @leggewie in armbian/build#9065workflows: add Delete Old Releases (copied from os). by @igorpecovnik in armbian/ci#26workflows: enable build cronjobs (taking over from armbian/os). by @igorpecovnik in armbian/ci#25youyeetoo-r1-v3: bump mainline u-boot to v2026.04. by @SuperKali in armbian/build#10219youyeetoo-r1-v3: promote to standard support and name audio outputs. by @SuperKali in armbian/build#10220View the full article

@eselarm: First off, thanks for your extensive answer and the effort you've put to read and answer to my question. I'm by far not such an expert like you yet, but to start with, I can tell you the following: I had two Le Potato SBC laying around doing nothing and I wanted to give them some work to do. I was already looking for a while to start with HA (I have currently an own written home automation system that works together with openHAB through MQTT). The Le Potato has (at least mine) 2GB of RAM on board, twice as much as all of my Raspberry Pi's I currently have or in use, or laying around doing nothing. So I think that should be sufficient to do what I want to do with HA. Le Potato is not a racing car, but I don't think this is necessary for me. Unless you have so many add-ons like you have. That's another story. I want to use Zigbee as a protocol for my sensors. I bought recently a whole bunch of them: presence detection, door and room sensors, temperature sensors. All of them from Aqara. I also bought a Sonoff Zigbee 3.0 USB Dongle P (later on, I read that I should have taken the E version but yeah, that's the "learning price" you pay if you step into an unknown world...) Next to that, I also bought presence detectors from another brand (HOBEIAN, model ZB-PL/ZB-p: this seems to be a Tuya clone), just to see how HA can cope with all those different brands. Finally, I also bought 4x 2PM GEN4 Shelly boxes to contol roller shutters later on. The nice thing about those is that they "understand" quite a few protocols, among others, Zigbee I also want to be able to "listen" to what the Zigbee components are sending to HA. Therefore, I want to use Zigbee2MQTT in HA instead of Zigbee Home Assistant itself. It's for Zigbee2MQTT that I really wanted a HA version with supervisor capabilities to be able to add Zigbee2MQTT through the Add-ons feature. Alas... that's not seem to work... So, my Le Potato should only be able to run HA in combination with MQTT and Zigbee2MQTT. The specs of Le Potato should be sufficient to cope with this I guess (I hope). And if the future demands me to add more features, well, then we'll see. But my first goal is to learn HA and its surroundings. And since I anyhow had those SBCs doing nothing.... So, since the "official" Armbian Home Assistant image didn't have the Add-ons feature, I took a brave and daring move: I went the HA docker way... Therefore, I took another SD card and flashed Armbian 26.2.1 Minimal to it. Just to have a very bare bone Linux distro (I have to admit that I do know something about Linux, I'm just not a HA expert yet...). After installing the distro on the SD card and doing the necessary "Armbian onboarding" stuff (create root password, create new user, and so on), I first installed Docker. Again: I have no experience yet with Docker, so again another big gamble. But I like challenges, so I don't mind. After installing Docker, I installed the HA docker image. I then opened the HA web UI and could also start creating a "first user" (which is apparently given administrator rights). But of course, again not the Add-ons feature in the Service section. But this time I could understand; this is normal since I didn't use the real, official HA repo. I could install ZHA, however, which I did. Just to see if my Sonoff dongle was detected and used by HA. After installing ZHA, I activated some of my devices and yes, they were detected! But that only proved my Zigbee dongle was working fine. Nothing more, nothing less. Still, very important! Then I installed Zigbee2MQTT "the Docker way". This was absolutely not a walk in the park, but in the end I got it up and running. My devices are getting detected, I know now how to change topics. I can receive MQTT topics on my MQTT broker running on another Raspberry Pi, I can filter the MQTT JSON objects so that I only receive what I would like to receive (by default, the JSON object exposes all entities of a device, but I'm not interested in all of them), I can convert the standard MQTT topic "prefix" used by Zigbee2MQTT on the fly and so on. Overall, I'm very satisfied with what I currently have and I will continue to follow that road. Maybe until Armbian has a fully supported HA image for Le Potato that contains the Add-ons section. Maybe I will switch to a more powerfull server too in the future. I read on the inet that a lot of people are switching from a RPi4 to a so-called Intel NUC server (whatever that is, no experience with it, no idea about its specs) for performance reasons and they're very satisfied. Maybe I'll do that too in the future, only God knows... We'll see, but still lots to learn about HA and its overall environment for the moment. Thanks again! Best, --Geert

@himigs stupid question, but I'm a total noob in hardware tinkering. On the 4th pic, you have the attached header with pins to UART. Please, tell me, was it necessary to solder it or there are means to connect it without soldering.

hate to bump this thread, but anyone have any luck with hardware decoding in latest Armbian? Tried with 26.5.1 vendor kernel with both gnome and kde. None of the guides seem to work with hardware decoding. Tried the above posted fork as well, but seems 26.6.1 doesn't ship with g610-g24p0-wayland-gbm. Installing it from here just gave me a black screen at boot. Not sure what else to try, I had moonlight working with hardware decoding in 24.8.1 a couple years ago here.

A difference between FriendlyElec image and Armbian image is U-Boot ( bootloader/firmware ) variant I think. For my NanoPi-R6C, HDMI audio does not work if I boot from SD-card where an image with a U-Boot from 2026 is written in the boot area (between main GPT and 1st partition). If I wipe that U-Boot by zeroing that area, the OS will take EDK2 UEFI v1.1 that I have written to eMMC. Then there is HDMI sound, on Armbian and Opensuse Tumbleweed. I need to check if I run it in hybrid ACPI+DeviceTree mode or just DeviceTree mode. The setting is anyway 'mainline kernel' DT, which should be about 6.10 or later. If I select 'vendor kernel', it can only run Armbian 6.1.115, but I don't remember if KDE6 Wayland does work then. I only did that to check if I idle power consumption was still < 1.5 Watt, which was the case. Else it is 3 Watt and min clock is 1GHz instead of 480MHz and more differences. I remember I saw some U-Boot version scrolling by when I messed up partitions on eMMC (might just be corrupt 2nd backup GPT), I think the UEFI code did fall back to some build-in U-Boot. Now I did check certain things: # gunzip < rk3588-sd-debian-trixie-gnome-wayland-desktop-6.1-arm64-20260629.img.gz | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g50821b3c8bd-241113 #fa (Jan 02 2025 - 16:53:42) # cat nanopi-r6c_UEFI_Release_v1.1.img | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g5f53abfa1e-221223 #zzz (Dec 26 2022 - 09:10:09) So the EDK2 seems to contain some old base U-Boot and also the FriendlyElec image same U-Boot base, however, it can be different and certainly is incompatible with mainline recent year U-Boot and also likely the vendor tagged one from Armbian. FriendlyElec could do various HW initialization in a different way and on top of that or mixed with it, EDK2 again does things. It needs rebuild EDK2 from source or so in order to gain more know-how and check. I also see the kernel version string in the FriendlyElec image is '6.1.141' (Armbian is '6.1.115-vendor-rk35xx' ), what that means I don't know, kernel.org is at 6.1.177 (2026-07-04). I am using 7.1.3+deb14-arm64-16k #1 SMP PREEMPT Debian 7.1.3-1 (2026-07-04) from Debian Sid repo, userspace is Armbian Trixie. So no HW accel, at least not in KDE6 with FireFox. The added RKMPP libs are 1 thing, the DMA devices are another. Names like 'uncached' and 'dma32' are important hints on how and what is implemented, wrapping tactics etc. The whole issue with those FriendlyElec images is, at a Debian minor update for example, those libav* files get overwritten. In addition, kernel sources w.r.t RKMPP are banned from github. So those images from FriendlyElec are a 1-time shot, works as longs as you don't update. I spent a lot of time to build RPI kernels and their ffmpeg/libav variant. It changed several times, now I don't use it anymore in a generic way, mainly because the HW encoder is fairly limited and does also not work anymore with Jellyfin ffmpeg build (for transcoding on-the-fly). Same for OpenSuse, they are strict on MPEG licensing/royalties, so no MPEG2,H264,HEVC etc, you extra need other repo to make it work. To come back to OP topic title, LibreElec (so dedicated Kodi) worked fine HW accel for HEVC, H264, H265, AV1 and partly for VP9. Was about 9 months ago I ran that dedicated from separate SD-card, so LE's own U-Boot and kernel etc, all mainline based. But is only decoders, so playing video on a usually larger HDMI monitor. So the kernel can do it, it is just many different API's and protocols. FireFox focuses on VAAPI AFAIK, so known to work fine on Intel HW, but needs then tweaks to work with v4l2_m2m AFAIK. Maybe look at RPi's FireFox patches, although I think it is proprietary for their Broadcom tailored kernel, so won't work with mainline Linux nor Rockchips stuff on RK3588.

Hello, I make two away with both kernel version. With officiel 6.18.35 and a build by me 6.18.37 with armbian build framework. see here: For the moment, i freeze to version kernel 6.18.10 and DTB file patch and all is Okok. Have a good day.

Should work on all devices