SBC News Latest Topicshttps://testforum.armbian.com/forum/95-sbc-news/SBC News Latest Topicsen[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62455-news-from-armbian-github-highlights/

This week's development centers on expanded board support and vendor kernel work, mainline kernel progression to 7.3 with CI resilience improvements, and a substantial refresh of the Armbian Imager.

New hardware enablement spans multiple SoC families, including the Boardcon SBC3568 (RK3568), ELTAY RM66 (RK3566) with vendor HDMI and power-domain workarounds, the Anbernic RG Rotate on the new Unisoc UMS512 family, and the NanoPi M6 V2. The NanoPi R6S, R6C, M6/M6V2, and NanoPC T6/T6-LTS have been unified under a single image with shared aliases, reducing duplication across the FriendlyELEC RK3588 lineup. On the vendor side, an initial rk35xx-vendor-next branch based on 6.12-rkr1 consolidates Rockchip vendor families, while fixes land for Orange Pi CM5 boot, Orange Pi 3B U-Boot unification, and RS485 support in the 8250 serial driver.

Mainline moves to 7.3-rc7 across rockchip64, meson64, and uefi targets, with SpacemiT K1 edge migrating from 7.2.y to 7.3.y and an RK3568 PCIe Root Port reset loop fix. Build infrastructure gains a GitHub mirror fallback for mainline kernel fetches, longer git proxy timeouts, overflow of arm64 image jobs to X64 runners, and ccache refactored into a swappable extension. The Armbian Imager received broad investment: full-page Settings with board-scoped first-boot profiles, a critical fix preventing the ext4 writer from corrupting the rootfs, hardened disk target validation before flashing, cache correctness fixes on Windows, and expanded CI coverage including Rust linting on Windows and functional test builds for fork PRs.

#Armbian #EmbeddedLinux #Rockchip #MainlineKernel #SBC

Changes

View the full article

]]>62455Tue, 13 Oct 2026 01:35:39 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62454-armbian-newsletter-github-highlights/

This week's development centers on expanded board support and vendor kernel work, mainline kernel progression to 7.3 with CI resilience improvements, and a substantial refresh of the Armbian Imager.

New hardware enablement spans multiple SoC families, including the Boardcon SBC3568 (RK3568), ELTAY RM66 (RK3566) with vendor HDMI and power-domain workarounds, the Anbernic RG Rotate on the new Unisoc UMS512 family, and the NanoPi M6 V2. The NanoPi R6S, R6C, M6/M6V2, and NanoPC T6/T6-LTS have been unified under a single image with shared aliases, reducing duplication across the FriendlyELEC RK3588 lineup. On the vendor side, an initial rk35xx-vendor-next branch based on 6.12-rkr1 consolidates Rockchip vendor families, while fixes land for Orange Pi CM5 boot, Orange Pi 3B U-Boot unification, and RS485 support in the 8250 serial driver.

Mainline moves to 7.3-rc7 across rockchip64, meson64, and uefi targets, with SpacemiT K1 edge migrating from 7.2.y to 7.3.y and an RK3568 PCIe Root Port reset loop fix. Build infrastructure gains a GitHub mirror fallback for mainline kernel fetches, longer git proxy timeouts, overflow of arm64 image jobs to X64 runners, and ccache refactored into a swappable extension. The Armbian Imager received broad investment: full-page Settings with board-scoped first-boot profiles, a critical fix preventing the ext4 writer from corrupting the rootfs, hardened disk target validation before flashing, cache correctness fixes on Windows, and expanded CI coverage including Rust linting on Windows and functional test builds for fork PRs.

#Armbian #EmbeddedLinux #Rockchip #MainlineKernel #SBC

Changes

View the full article

]]>62454Tue, 13 Oct 2026 01:35:39 +0000[CNX-Software] - Wireless-Tag WT32P4C5-43S – A fully integrated 4.3-inch ESP32-P4 and ESP32-C5 touch display devkithttps://testforum.armbian.com/topic/62434-cnx-software-wireless-tag-wt32p4c5-43s-a-fully-integrated-43-inch-esp32-p4-and-esp32-c5-touch-display-devkit/4.3 inch dual chip ESP32 P4 and ESP32 C5 Wi Fi6 integrated touch display

Wireless-Tag WT32P4C5-43S (ZX4D30CE405-V1.3)  is a fully integrated 4.3-inch touch display development board that combines an ESP32-P4 MCU with an ESP32-C5 wireless module supporting dual-band WiFi 6 (2.4/5 GHz), Bluetooth LE, and 802.15.4 connectivity. Unlike previous ESP32-P4 + ESP32-C5 solutions, this one comes with a built-in touchscreen, so you don’t need to connect a separate display. Designed for industrial automation, smart control panels, and edge AI vision terminals, the board also integrates a 15-pin MIPI CSI camera interface, a microSD card slot, two USB Type-C ports (USB 2.0 High-Speed and Debug/JTAG), and a 14-pin GPIO expansion header. Wireless-Tag WT32P4C5-43S (ZX4D30CE405-V1.3) specifications: Core module – Wireless Tag WT0132P4-A1-N16R32 SoC – Espressif Systems ESP32-P4 CPU Dual-core 32-bit RISC-V HP (High-performance) CPU @ up to 400 MHz with AI instructions extension and single-precision FPU Single-RISC-V LP (Low-power) MCU core @ up to 40 MHz with 8KB of zero-wait TCM RAM Memory 768 KB HP [...]

The post Wireless-Tag WT32P4C5-43S – A fully integrated 4.3-inch ESP32-P4 and ESP32-C5 touch display devkit appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62434Sun, 11 Oct 2026 11:36:22 +0000[CNX-Software] - M5Stack ToughC5 weatherproof ESP32-C5 IoT controller offers dual-band Wi-Fi 6, BLE 5, and Zigbee/Threadhttps://testforum.armbian.com/topic/62435-cnx-software-m5stack-toughc5-weatherproof-esp32-c5-iot-controller-offers-dual-band-wi-fi-6-ble-5-and-zigbeethread/M5Stack ToughC5 IoT Dev Kit with ESP32 C5

M5Stack has just introduced the ToughC5, a rugged, weatherproof outdoor IoT controller built around the ESP32-C5. The device features a bright 2.0-inch capacitive touch IPS display and RS485 connectivity. The ToughC5 is an upgrade to the ESP32-base3d M5Stack TOUGH introduced in 2021, with the upgraded model featuring a more modern ESP32-C5 MCU with dual-band (2.4/5 GHz) Wi-Fi 6, Bluetooth 5 LE, and an IEEE 802.15.4 radio for Zigbee and Thread. Other changes include faster Octal PSRAM, an upgraded RTC chip with a dedicated coin cell backup battery, a passive buzzer replacing the previous 1W speaker, and a custom power management system (M5PM1 + M5IOE1) replacing the AXP192 PMU. These features make it suitable for industrial field control, outdoor edge data collection, and smart building applications. M5Stack ToughC5 specifications: Wireless SoC – Espressif Systems ESP32-C5HR8 CPU Single-core 32-bit RISC-V processor @ up to 240 MHz Low-power RISC-V core @ 40 MHz [...]

The post M5Stack ToughC5 weatherproof ESP32-C5 IoT controller offers dual-band Wi-Fi 6, BLE 5, and Zigbee/Thread appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62435Sat, 10 Oct 2026 07:00:45 +0000[CNX-Software] - Open-source ESP32-C3 DNS ad blocker supports up to over 500,000 domains without PSRAMhttps://testforum.armbian.com/topic/62436-cnx-software-open-source-esp32-c3-dns-ad-blocker-supports-up-to-over-500000-domains-without-psram/ESP32 C3 SuperMini DNS ad blocker in a 3D printed enclosure with a USB A adapter for direct connection to a router

Developed by Zed (M-Abozaid), the esp32-c3-adblock is an open-source, Pi-hole-style DNS ad blocker that runs on a $2 ESP32-C3 microcontroller board/module without requiring PSRAM. It blocks ads and tracking domains across devices on a home or small office network by filtering DNS requests. Instead of storing domain strings in RAM, the project stores them as sorted 40-bit FNV-1a hashes in flash memory and uses binary search to check DNS requests. When a UDP DNS query comes in, the C++ firmware extracts the domain, hashes it (including parent suffixes), and performs a binary search against the flash hash table. If the domain is on the blocklist, the ESP32-C3 returns 0.0.0.0 to block the request. Otherwise, it forwards the query to an upstream DNS server and returns the response to the client. This method fits over 140,000 domains into ~0.7 MB of flash memory while using only ~50 KB of RAM. A [...]

The post Open-source ESP32-C3 DNS ad blocker supports up to over 500,000 domains without PSRAM appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62436Fri, 09 Oct 2026 12:00:44 +0000[CNX-Software] - Sipeed SLogic32U3 – A high-speed 10 Gbps USB 3.2 logic analyzer (Crowdfunding)https://testforum.armbian.com/topic/62437-cnx-software-sipeed-slogic32u3-a-high-speed-10-gbps-usb-32-logic-analyzer-crowdfunding/Sipeed SLogic32U3

Sipeed has just launched what they claim is the world’s first 10 Gbps USB 3.2 logic analyzer. The SLogic32U3 is the successor to the SLogic16U3 3.2 Gbps logic analyzer launched in 2025. The SLogic32U3 USB-C logic analyzer supports up to 32 channels via four mini HDMI connectors, 350 MHz signal bandwidth, up to 1400 MS/s per channel with four channels, or 200 MS/s per channel with 32 channels, and is offered with an optional ADC module. SLogic32U3 specifications: FPGA – Not mentioned (potentially from GOWIN) Input channels – 32 digital channels via 4x mini HDMI ports, each with 8 channels Sample rates 1400MS/s @ 4 channels 800MS/s @ 8 channels 400MS/s @ 16 channels 200MS/s @ 32 channels Digital signal bandwidth – 350 MHz Stream FIFO buffer – 2 Gbit DDR3 Capture mode – Stream (real-time readback); depth limited by PC memory/disk Signal input voltage – 0–10 V Adjustable threshold [...]

The post Sipeed SLogic32U3 – A high-speed 10 Gbps USB 3.2 logic analyzer (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62437Thu, 08 Oct 2026 17:01:38 +0000[CNX-Software] - Q8botOne – A palm-sized open-source quadruped robot with ESP32-C3, DYNAMIXEL smart actuators (Crowdfunding)https://testforum.armbian.com/topic/62438-cnx-software-q8botone-a-palm-sized-open-source-quadruped-robot-with-esp32-c3-dynamixel-smart-actuators-crowdfunding/Q8botOne A Serious Quadruped That Fits in Your Hand

ZeroWire Robotics Q8botOne is an open-source, palm-sized quadruped robot built around an ESP32-C3 MCU and ROBOTIS DYNAMIXEL smart actuators. Designed with a unique wire-free architecture, the robot integrates all components onto a central printed circuit board also used as the structural chassis. The robot is roughly the size of a smartphone and can jog, jump, and carry up to twice its 250-gram weight. The main PCB uses a dedicated 6V/16A step-down converter for motor power and includes a battery management system for two 14500 Li-ion cells. For control, the kit includes a separate ESP32-C3 controller PCB with an Adafruit Mini I2C Gamepad. Q8botOne specifications: Wireless module – Espressif Systems ESP32-C3-MINI-1-N4 module with: ESP32-C3 (ESP32-C3FN4) SoC CPU – 32-bit RISC-V single-core processor up to 160 MHz Memory – 400 KB SRAM (16 KB for cache), 8 KB SRAM in RTC Storage – 4 MB embedded flash, 384 KB ROM Connectivity – [...]

The post Q8botOne – A palm-sized open-source quadruped robot with ESP32-C3, DYNAMIXEL smart actuators (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62438Thu, 08 Oct 2026 09:00:08 +0000[CNX-Software] - Efinix Sapphire RV64 SoC – Configurable RISC-V soft-cores with DDR3, LPDDR4x, and HyperRAM for Efinix FPGAshttps://testforum.armbian.com/topic/62439-cnx-software-efinix-sapphire-rv64-soc-configurable-risc-v-soft-cores-with-ddr3-lpddr4x-and-hyperram-for-efinix-fpgas/Sapphire RV64 SoC block diagram. The VexiiRiscv cores, caches, and peripherals are built in the FPGA

Efinix has introduced the Sapphire RV64 SoC, a configurable 64-bit RISC-V soft-core processor designed for its Titanium and Trion FPGAs. It is based on the VexiiRiscv core and can be configured with one to four RISC-V cores running at up to 400 MHz. The Sapphire RV64 has a seven-stage pipeline, configurable L1 caches, optional 64–512 KB L2 cache, and 4–512 KB of on-chip RAM. It supports DDR3, LPDDR4x, and HyperRAM with up to 512-bit AXI interfaces and external memory from 4 MB to 8 GB. Other features include an optional FPU, branch predictor, prefetchers, SV39 MMU, up to 32 GPIOs, five I²C, three SPI, three UARTs, timers, watchdog, and up to eight user interrupts. Efinix Sapphire RV64 SoC specifications: CPU 1 to 4x VexiiRiscv 64-bit cores with a 7-stage pipeline (fetch, align-decompress, decode, issue, execute, memory, and writeback) Configurable system clock frequency from 20 MHz to 400 MHz Supports RV64IMACFD_Zba_Zbc_Zbs extensions [...]

The post Efinix Sapphire RV64 SoC – Configurable RISC-V soft-cores with DDR3, LPDDR4x, and HyperRAM for Efinix FPGAs appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62439Thu, 08 Oct 2026 00:00:32 +0000[CNX-Software] - DSPi firmware turns Raspberry Pi RP2040/RP2350 into a USB sound card with an onboard DSP enginehttps://testforum.armbian.com/topic/62440-cnx-software-dspi-firmware-turns-raspberry-pi-rp2040rp2350-into-a-usb-sound-card-with-an-onboard-dsp-engine/Raspberry Pi Pico configuration in DSPi Console

DSPi is a full-featured audio DSP firmware for the Raspberry Pi Pico, Pico 2, and other Raspberry Pi RP2040/RP2350 boards, which turns them into a USB sound card with an integrated DSP. It allows users to make use of essential tools like room correction, active crossovers, parametric EQ, time alignment, and more, and essentially works as a regular sound card on your computer. DSPi firmware’s capabilities: Dual-Core DSP – EQ processing is split across both cores on both RP2040 and RP2350. USB Audio Interface – Supports 16-bit and 24-bit PCM input at 44.1, 48, and 96 kHz, working on macOS, Windows, Linux, and iOS. S/PDIF Input – 24-bit PCM stereo audio at 44.1 or 48kHz. 24-bit S/PDIF or I2S Outputs – Up to 4x independent stereo output slots (8x channels on RP2350, 4x channels on RP2040). Subwoofer Output – Dedicated mono PDM output channel with a high-performance 2nd-order delta-sigma modulator, [...]

The post DSPi firmware turns Raspberry Pi RP2040/RP2350 into a USB sound card with an onboard DSP engine appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62440Wed, 07 Oct 2026 09:00:08 +0000[CNX-Software] - NuMaker-IoT-MA35D0-A2 (Chili Pro) ultra-compact evaluation board features MA35D0K Cortex-A35/M4 MPUhttps://testforum.armbian.com/topic/62441-cnx-software-numaker-iot-ma35d0-a2-chili-pro-ultra-compact-evaluation-board-features-ma35d0k-cortex-a35m4-mpu/NuMaker IoT MA35H0 A2 evaluation board

Nuvoton has added MA35D05KH67C, MA35D05KI67C, and MA35D05KJ67C, three new LQFP128 MPUs, to the NuMicro MA35D0 series, along with the NuMaker-IoT-MA35D0-A2 (Chili Pro) evaluation board. Designed for industrial AI, smart gateways, and renewable energy systems, this heterogeneous MPU has two 64-bit Arm Cortex-A35 cores at up to 650 MHz, plus a dedicated 180 MHz Arm Cortex-M4 for real-time work. Nuvoton’s press release calls Chili Pro the “industry’s smallest Linux platform,” but the board is 45 × 45 mm, which is bigger than other boards we wrote about previously, like the VoCore2 (25.4 × 25.4 × 2.8 mm), the Milk-V Duo 256M (51 × 21 mm), NanoPi NEO (40 × 40 mm), and even the Raspberry Pi Zero 2 W (65 × 30 mm). Still, considering that it fits full-sized RJ45 and USB ports along with the other interfaces, it is a pretty compact and capable board. Nuvoton NuMaker-IoT-MA35D0-A2 evaluation board specifications: [...]

The post NuMaker-IoT-MA35D0-A2 (Chili Pro) ultra-compact evaluation board features MA35D0K Cortex-A35/M4 MPU appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62441Wed, 07 Oct 2026 00:00:19 +0000[Collabora] - USB-C DisplayPort Alt Mode on Rockchip RK3588 and RK3576, starting with the Flipper Onehttps://testforum.armbian.com/topic/62406-collabora-usb-c-displayport-alt-mode-on-rockchip-rk3588-and-rk3576-starting-with-the-flipper-one/View the full article

]]>62406Tue, 06 Oct 2026 20:32:03 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62403-news-from-armbian-github-highlights/

This week's work centers on expanded board and SoC support, build and repository infrastructure modernization, and refinements to user-facing tooling and documentation.

On the hardware side, mainline support arrived for the Radxa Rock 2A/2F and the Toradex Verdin iMX8M Mini, while the KickPi K2B V2.2 DDR3 gained a full board definition including a new Maxio MAE0621 PHY driver. The Allwinner sun60iw2 platform saw substantial advancement on the Orange Pi 4 Pro with GPU, desktop, and hardware video decode enablement, alongside kernel configuration refinements. The Amlogic C400-plus received U-Boot repacking and Mali-T820 stabilization, the Rockchip armhf edge kernel was bumped to 7.3, and smaller fixes landed for the BPI-M4-Zero, Allwinner D1 RISC-V, MangoPi MQ, and Anbernic handhelds.

The build framework received a significant repository management overhaul, adopting the production singlemode repo.sh into main and publishing with Acquire-By-Hash for integrity. OCI storage became configurable with a read-only OCI_PROXY, propagated through CI chunk workflows and runner cleanup. NXP and Trusted Firmware sources were migrated to Armbian-hosted GitHub mirrors, user patches can now override same-named core patches, and USERPATCHES_PATH was restored to working order.

For end users, armbianmonitor received a full refactor, armbian-firstlogin gained unattended-preset safety and broader username validation, and the APT lock handling was hardened against stale cache locks. The configng project introduced a read-only registry-cache for ghcr.io, fixed static IP cancellation handling, and corrected tuning-profile swappiness regressions. Documentation expanded to cover OCI storage, unattended first login, and application installation workflows.

#Armbian #EmbeddedLinux #SBC #Rockchip #Allwinner #UBoot

Changes

View the full article

]]>62403Tue, 06 Oct 2026 12:59:29 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62402-armbian-newsletter-github-highlights/

This week's work centers on expanded board and SoC support, build and repository infrastructure modernization, and refinements to user-facing tooling and documentation.

On the hardware side, mainline support arrived for the Radxa Rock 2A/2F and the Toradex Verdin iMX8M Mini, while the KickPi K2B V2.2 DDR3 gained a full board definition including a new Maxio MAE0621 PHY driver. The Allwinner sun60iw2 platform saw substantial advancement on the Orange Pi 4 Pro with GPU, desktop, and hardware video decode enablement, alongside kernel configuration refinements. The Amlogic C400-plus received U-Boot repacking and Mali-T820 stabilization, the Rockchip armhf edge kernel was bumped to 7.3, and smaller fixes landed for the BPI-M4-Zero, Allwinner D1 RISC-V, MangoPi MQ, and Anbernic handhelds.

The build framework received a significant repository management overhaul, adopting the production singlemode repo.sh into main and publishing with Acquire-By-Hash for integrity. OCI storage became configurable with a read-only OCI_PROXY, propagated through CI chunk workflows and runner cleanup. NXP and Trusted Firmware sources were migrated to Armbian-hosted GitHub mirrors, user patches can now override same-named core patches, and USERPATCHES_PATH was restored to working order.

For end users, armbianmonitor received a full refactor, armbian-firstlogin gained unattended-preset safety and broader username validation, and the APT lock handling was hardened against stale cache locks. The configng project introduced a read-only registry-cache for ghcr.io, fixed static IP cancellation handling, and corrected tuning-profile swappiness regressions. Documentation expanded to cover OCI storage, unattended first login, and application installation workflows.

#Armbian #EmbeddedLinux #SBC #Rockchip #Allwinner #UBoot

Changes

View the full article

]]>62402Tue, 06 Oct 2026 12:59:29 +0000[CNX-Software] - XIMEA MU003TG-SY-UC – A miniature, modular 0.3MP USB 3.0 ToF Sensor based on Sony IMX556https://testforum.armbian.com/topic/62442-cnx-software-ximea-mu003tg-sy-uc-a-miniature-modular-03mp-usb-30-tof-sensor-based-on-sony-imx556/XIMEA MU003TG SY UC A miniature 0.3MP Sony IMX556 ToF Sensor with USB 3.0 interface

The XIMEA MU003TG-SY-UC is a miniature industrial Time-of-Flight (ToF) camera with a 0.3MP Sony IMX556 CMOS sensor, global shutter, 640 × 480 resolution, and a 60 FPS frame rate. Its compact 26.4 × 26.4 × 28.67 mm enclosure and 31-gram weight make it suitable for space-limited embedded vision systems, robotics, UAVs, kiosks, 3D scanning, face recognition, and other machine-vision applications. The module uses a USB 3.2 Gen 1 interface through a 14-pin I-PEX Cabline SS connector for data, power, and control. A separate 10-pin Cabline V connector provides synchronization with external VCSEL illumination. The camera does not include an illumination source or optical band-pass filter, so these components must be provided separately for depth sensing. XIMEA MU003TG-SY-UC specifications: Sensor – Sony IMX556 CMOS Time-of-Flight sensor, global shutter, no on-sensor filter Resolution – 0.3 megapixels (640 × 480); active area 6.4 × 4.8 mm Pixel Size – 10 µm x 10 [...]

The post XIMEA MU003TG-SY-UC – A miniature, modular 0.3MP USB 3.0 ToF Sensor based on Sony IMX556 appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62442Tue, 06 Oct 2026 09:00:22 +0000[CNX-Software] - Save $70 on GEEKOM A5 Pro 2026 Edition mini PC during Prime Day Sale (Sponsored)https://testforum.armbian.com/topic/62443-cnx-software-save-70-on-geekom-a5-pro-2026-edition-mini-pc-during-prime-day-sale-sponsored/GEEKOM mini PC Prime Day 2026 deals

The GEEKOM A5 Pro 2026 Edition is a pocket-sized 0.47L mini PC available at a $70 discount for the company’s Prime Day Sale until October 7. Powered by the 6-core Ryzen 5 7530U (up to 4.5GHz), it handles browsing, documents, video calls, and AI-agent tasks such as drafting, summarizing, and planning with ease. Dual HDMI 2.0 and dual USB-C ports support up to four displays (or one 8K display), enabling efficient multi-window workflows. Meanwhile, dual SO-DIMM slots (up to 64GB) and dual M.2 slots (up to 5TB total) provide plenty of room for future upgrades. With 2.5GbE, Wi-Fi 6E, six USB ports, an SD card reader, and VESA mounting support, along with an aluminum body that has passed 339 reliability tests, the A5 Pro is a quiet, clutter-free desktop companion for offices and home workspaces running Windows 11 Pro or Linux. Backed by GEEKOM’s 3-year warranty, the A5 Pro is [...]

The post Save $70 on GEEKOM A5 Pro 2026 Edition mini PC during Prime Day Sale (Sponsored) appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62443Tue, 06 Oct 2026 01:00:26 +0000[CNX-Software] - DEBIX M8391-01 industrial SBC features MediaTek Genio 720 SoC with 9 TOPS NPU, dual-display supporthttps://testforum.armbian.com/topic/62444-cnx-software-debix-m8391-01-industrial-sbc-features-mediatek-genio-720-soc-with-9-tops-npu-dual-display-support/DEBIX M8391 01 SBC with MediaTek Genio 720 SoCjpg

The DEBIX M8391-01 is a compact industrial SBC built around the MediaTek MT8391 (Genio 720) processor, designed for edge AI, computer vision, robotics, and intelligent IoT applications. The SoC’s 9-TOPS NPU enables local AI inference without relying on cloud processing. The board features up to 16GB LPDDR4 memory and up to 64GB eMMC storage, with M.2 PCIe 2.0 NVMe SSD and MicroSD card expansion. It also offers a 4-lane MIPI CSI camera input, MIPI DSI up to 2.5K and eDP 1.4 display interfaces, Gigabit Ethernet with PoE, Wi-Fi 6, Bluetooth 5.4, five USB ports, and a 40-pin expansion header. With an industrial operating temperature range (-40°C to 85°C), this credit card-sized, Raspberry Pi-inspired SBC can be used for edge AI vision, robotics, industrial IoT, and other embedded systems. DEBIX M8391-01 specifications: MediaTeck Genio 720 (MT8391) CPU Commercial-grade (default) – 2x Arm Cortex-A78 cores @ up to 2.6 GHz, 6x Arm [...]

The post DEBIX M8391-01 industrial SBC features MediaTek Genio 720 SoC with 9 TOPS NPU, dual-display support appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62444Mon, 05 Oct 2026 09:00:49 +0000[CNX-Software] - Geekworm UPS Scap 5V5A – A supercapacitor UPS HAT for Raspberry Pi 5https://testforum.armbian.com/topic/62445-cnx-software-geekworm-ups-scap-5v5a-a-supercapacitor-ups-hat-for-raspberry-pi-5/Geekworm’s Raspberry Pi 5 supercapacitor UPS HAT

Geekworm, in collaboration with Mcuzone, has launched the UPS Scap 5V5A, a new supercapacitor UPS HAT for the Raspberry Pi 5 designed to keep the Raspberry Pi running long enough (a few seconds to a few minutes) to save data and shut down safely, rather than provide hours of backup power. Available in 100F, 60F, and 22F versions, the HAT has a built-in PD chip that negotiates a true 5V/5A output. This gives the Raspberry Pi 5 enough power to run properly without triggering the low-voltage warnings that can happen with some power supplies. The module connects to the Raspberry Pi 5 through pogo pins to detect power loss and supports I2C for checking voltage and current in real time. It also features dual independent power inputs, so you can power it with either a wide-voltage DC barrel jack or a standard USB-C PD charger. Geekworm UPS Scap 5V5A supercapacitor [...]

The post Geekworm UPS Scap 5V5A – A supercapacitor UPS HAT for Raspberry Pi 5 appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62445Mon, 05 Oct 2026 00:00:22 +0000[CNX-Software] - ESP-SDR firmware turns ESP32 into a 2.4/5 GHz Software-Defined Radio (SDR)https://testforum.armbian.com/topic/62446-cnx-software-esp-sdr-firmware-turns-esp32-into-a-245-ghz-software-defined-radio-sdr/ESP WebSDR showing the live 2.4 GHz spectrum and waterfall using raw I Q data captured from an ESP32 S3

We have seen ESP32s used for everything from simple IoT devices to AI, audio, and vision projects. But while looking for a new project, I found out about ESP-SDR firmware, which turns the ESP32 into a native Software-Defined Radio (SDR) without additional hardware. This open-source firmware bypasses the ESP32’s fixed-function Wi-Fi and Bluetooth modems and taps directly into the internal ADC signal chain to capture raw I/Q baseband samples. It then sends these samples to a computer over USB or UART, where they can be processed and viewed as a radio spectrum or waterfall display, turning supported ESP32 chips into low-cost software-defined radio receivers without requiring additional SDR hardware. Key features and supported hardware: Supported chips – ESP32, ESP32-C3, ESP32-C5 (dual-band 2.4/5 GHz), ESP32-C6, ESP32-C61, ESP32-S2, ESP32-S3, and the preview ESP32-S31 Tuning range – Nominally 2.4 GHz ISM (2.2–2.7 GHz on some chips) and 5 GHz (4.8–6.0 GHz on ESP32-C5); The [...]

The post ESP-SDR firmware turns ESP32 into a 2.4/5 GHz Software-Defined Radio (SDR) appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62446Sun, 04 Oct 2026 03:00:42 +0000[CNX-Software] - UUNA TEK iAuto review – A professional handwriting and drawing machinehttps://testforum.armbian.com/topic/62447-cnx-software-uuna-tek-iauto-review-a-professional-handwriting-and-drawing-machine/uuna tek iauto review

Hello, today I am going to review the UUNA TEK iAuto, an automatic handwriting machine designed to reproduce physical handwriting using a real pen on real paper. It also supports wireless connectivity, spreadsheet-based mail merge, custom fonts, and font variation features that can make the writing look more natural. The machine can handle paper sizes up to A3 and supports pens with a diameter of up to 18 mm. The UUNA TEK iAuto works with the manufacturer’s free iAuto software, which is available for Windows on both x64 and Arm-based systems, as well as for macOS on Apple M1, M2, M3, and Intel-based Macs. Most of the following review focuses on the machine’s writing capabilities, including tests with text, SVG graphics, different writing speeds, various pens, and different paper types. Unboxing The parcel was shipped from China by land transportation and took around six days to arrive at my office [...]

The post UUNA TEK iAuto review – A professional handwriting and drawing machine appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62447Sat, 03 Oct 2026 03:00:36 +0000[Collabora] - Open Source in Prague: A week of talks, hands-on demos, and community!https://testforum.armbian.com/topic/62361-collabora-open-source-in-prague-a-week-of-talks-hands-on-demos-and-community/View the full article

]]>62361Fri, 02 Oct 2026 21:01:33 +0000[CNX-Software] - UP Xtreme PTL Edge Air Panther Lake Mini PC gets AirJet solid-state active cooling solutionhttps://testforum.armbian.com/topic/62448-cnx-software-up-xtreme-ptl-edge-air-panther-lake-mini-pc-gets-airjet-solid-state-active-cooling-solution/UP Xtreme PTL Edge Air

AAEON has introduced a new version of its UP Xtreme PTL Edge Panther Lake mini PC with the “Air” variant featuring Frore Systems AirJet solid-state active cooling solution. The company says the AirJet passive cooling technology makes the Panther Lake mini PC 35% thinner, 43% lighter, and capable of operating silently at under 21 dBA. This is mostly achieved by removing the thick (and heavy) heatsink found on the original design. The mini PC still benefits from up to an Intel Core Ultra X7 358H with 180 TOPS of AI performance, a 40-pin GPIO header, two RS-232/422/485 COM ports, and a wide 19 to 36V DC input range. UP Xtreme PTL Edge Air specifications: Intel Core Ultra Series 3 Panther Lake SoC (one or the other) Intel Core Ultra X7 Processor 358H CPU – 16-core (4P + 8E + 4LPE) @ 1.9/1.5/1.5 GHz Base frequency, 4.8/3.5/3.5 GHz Turbo frequency Cache [...]

The post UP Xtreme PTL Edge Air Panther Lake Mini PC gets AirJet solid-state active cooling solution appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62448Fri, 02 Oct 2026 09:00:53 +0000[CNX-Software] - Avaota F2 – Allwinner V861 RISC-V SBC targets AI cameras with PTZ and audio supporthttps://testforum.armbian.com/topic/62449-cnx-software-avaota-f2-allwinner-v861-risc-v-sbc-targets-ai-cameras-with-ptz-and-audio-support/Avaota F2 SBC

Avaota F2 is the first SBC based on an Allwinner V861 dual-core 64-bit RISC-V SoC with 128MB on-chip DDR3 memory, support for 4K cameras, H.265 video codec, and a 1 TOPS AI accelerator. It’s an update to the earlier Avaota F1 camera board based on an Allwinner V821 SoC. The new open-source hardware F2 SBC offers several benefits, including support for both Full HD and 4K camera sensors, motor control for the PTZ (Pan-Tilt-Zoom) feature, and improved audio support through speaker (one) and microphone (two) connectors. However, the F1 also included WiFi, which the Avaota F2 lacks. Avaota F2 specifications: SoC – Allwinner V861M2-XXX CPU Dual-Core RISC-V XuanTie C907 (RV64GCBV/RV32GGCBV) clocked up to 1.4GHz with RVV 1.0 extensions Single-core RISC-V XuanTie E907 (RV32IMAFC) clocked up to 800MHz VPU Video Encoder H.264/H.265 up to  4K @ 25fps (M)JPEG up to 8192×8192 Video Decoder – (M)JPEG up to 1080p60 AI accelerator – [...]

The post Avaota F2 – Allwinner V861 RISC-V SBC targets AI cameras with PTZ and audio support appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62449Fri, 02 Oct 2026 02:00:37 +0000[CNX-Software] - ASRock Industrial NUC 300 series – Intel Core 3 304/Core 5 320 mini PCs and motherboardshttps://testforum.armbian.com/topic/62450-cnx-software-asrock-industrial-nuc-300-series-intel-core-3-304core-5-320-mini-pcs-and-motherboards/ASRock NUC 320 motherboard alongside the NUC BOX 320 mini PC

ASRock Industrial has introduced the NUC Core 300 BOX series of mini PCs and the NUC Core 300 motherboards built around Intel Core Series 3 Wildcat Lake-U processors. The lineup includes the NUC BOX-320, with the Intel Core 5 320 SoC, and the NUC BOX-304, which uses the Core 3 304 SoC. The company also offers the NUC-320 and NUC-304 as standalone motherboards for custom systems. The systems support up to 64GB DDR5-6400 with In-Band ECC, dual M.2 PCIe Gen4 storage, dual 2.5GbE, Wi-Fi 6E, Bluetooth 5.3, triple-display output, USB 3.2 connectivity, and 12–24V DC input. These features make them suitable for industrial PCs, edge computing systems, and other embedded applications. ASRock NUC Core 300 series specifications: Wildcat Lake SoC Intel Core 3 304 (NUC BOX-304, NUC-304) 5-core CPU – 1x P-cores @ 1.5/4.3 GHz (Turbo) + 4x LPE-cores @ 1.4/3.3 GHz (Turbo) GPU – 1-core Intel Xe3 Graphics @ [...]

The post ASRock Industrial NUC 300 series – Intel Core 3 304/Core 5 320 mini PCs and motherboards appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62450Fri, 02 Oct 2026 00:00:32 +0000[CNX-Software] - LakeShark firmware turns LilyGO T-Display P4 into a handheld ESP32-P4 SDR scannerhttps://testforum.armbian.com/topic/62451-cnx-software-lakeshark-firmware-turns-lilygo-t-display-p4-into-a-handheld-esp32-p4-sdr-scanner/LilyGO T Display P4 running LakeShark open source firmware

LakeShark is open-source firmware by Samuel Reynolds (SAMS0N1TE) that turns the ESP32-P4-based LilyGO T-Display P4 into a handheld SDR scanner. Paired with an RTL-SDR Blog V3 or V4 dongle, it supports P25 Phase I trunking, analog FM/AM, POCSAG pager decoding, and 1090 MHz ADS-B reception directly on the ESP32-P4, without a PC, Raspberry Pi, or smartphone. It also includes an onboard SX1262 that supports LoRa and MeshCore applications. SDR devices like LimeSDR Micro, xSDR, UUGear’s VU GPSDR, and many others usually rely on a PC, Raspberry Pi, or smartphone for processing, but LakeShark shows that a powerful microcontroller can also handle many SDR tasks. We previously covered the LilyGO T-Display P4 in March 2026, and LakeShark makes good use of its built-in hardware, including the SX1262 for LoRa and MeshCore applications, L76K GPS receiver for location tracking and offline maps, and ESP32-C6 for Wi-Fi and Bluetooth connectivity. LakeShark hardware requirements: Primary [...]

The post LakeShark firmware turns LilyGO T-Display P4 into a handheld ESP32-P4 SDR scanner appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62451Thu, 01 Oct 2026 09:00:28 +0000[CNX-Software] - $30 Raspberry Pi Smart Display Module for CM5 targets digital signage displays and kioskshttps://testforum.armbian.com/topic/62452-cnx-software-30-raspberry-pi-smart-display-module-for-cm5-targets-digital-signage-displays-and-kiosks/Raspberry Pi Smart Display Module

Raspberry Pi Smart Display Module is a CM5 carrier board compatible with the Intel Smart Display Module (SDM) specification, more specifically the SDM-L form factor (as opposed to the smaller SDM-S option). The Intel SDM standard has been around for years, and we first wrote it in 2018, covering the Axiomtek SDM300s (SDM-S) module. These cards are designed to be plugged into compatible digital signage displays, kiosks, point-of-sale systems, and so on. They feature a standard 98-pin PCIe edge connector with USB 3.0, HDMI 1.4/2.0, I2C/UART/SPI signalling, as well as Ethernet, HDMI, USB ports, and an M.2 expansion socket. Raspberry Pi Smart Display Module specifications: Compatible with Raspberry Pi Compute Module 5 Video Output – Full-size HDMI 2.0 port Camera – 22-way MIPI DSI/CSI-2 connector (internal) Networking Gigabit Ethernet RJ45 port WiFi 5 and Bluetooth 5.2 (on CM5) with U.FL antenna USB USB 3.0 Type-A port USB 2.0 Type-C port for programming [...]

The post $30 Raspberry Pi Smart Display Module for CM5 targets digital signage displays and kiosks appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62452Thu, 01 Oct 2026 00:00:53 +0000[News from Armbian] - Armbian Newsletter September 2026https://testforum.armbian.com/topic/62342-news-from-armbian-armbian-newsletter-september-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

Sponsored

View the full article

]]>62342Wed, 30 Sep 2026 18:40:54 +0000[Armbian newsletter] - Armbian Newsletter September 2026https://testforum.armbian.com/topic/62340-armbian-newsletter-armbian-newsletter-september-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

JetHome boosts Armbian CI
JetHome (Shenzhen JetHome Technology Co.) donated a build server for Armbian. The server compiles Armbian images, kernels and U-Boot packages. Thank you, JetHome. HW Specifications CPU 2 × Intel Xeon Gold 6148, 80 threads Memory 384 GB Storage 3.84 TB SSD, plus 20 TB of disk Network 2 × 1

Sponsored

Github Highlights
This week’s work centers on Rockchip platform maturation, kernel and toolchain modernization, and board-level enablement across vendors. Rockchip received the largest share of attention, with RK3528 gaining a thermal driver, cooling-map refinements, and cleanup of legacy PCIe and pmdomain workarounds. The Radxa E24C now stores its U-
Booting every board, every night
Armbian builds for hundreds of boards. A kernel bump that is clean on one SoC can leave another unbootable and no build log will tell you. So there is a rack, and the rack boots them. Compiling is not evidence. A kernel that builds, packages that install, an image that
Mali GPU with LiteRT-LM
Running Gemma 4 E2B on a Mali GPU with LiteRT-LM This guide should work on any armbian minimal/console (trixie) system with a working Mali-g610 GPU. DO NOT USE DESKTOP Verified on: Orange Pi 5 Max (Rockchip RK3588, Arm Mali-G610 MC4), Armbian/Debian 13 (trixie), aarch64, 8

View the full article

]]>62340Wed, 30 Sep 2026 18:40:54 +0000[News from Armbian] - Booting every board, every nighthttps://testforum.armbian.com/topic/62343-news-from-armbian-booting-every-board-every-night/

Armbian builds for hundreds of boards. A kernel bump that is clean on one SoC can leave another unbootable and no build log will tell you. So there is a rack, and the rack boots them.

Compiling is not evidence. A kernel that builds, packages that install, an image that flashes — none of it proves a board comes back after reboot. Armbian supports a very large number of boards across a dozen vendors and twenty SoC families, maintained largely by volunteers who each own one or two of them. The failure mode that hurts is not a broken build. It is a change that builds perfectly and quietly bricks the boot path on hardware nobody happened to have on their desk that week.

The automated test facility exists to close that gap. It is a rack of real boards, wired for remote power, that installs what Armbian published and then tries to use it: upgrade, switch kernel branches, reboot repeatedly, measure, report. What follows is what it does today, the hardware it takes to run, where AI fits into maintaining the stack around it, and the change we want to make next: moving hardware validation from nightly builds to pull requests.

What is in the rack

Fleet composition, as recorded in inventory

65 Boards under test 62 Distinct models 22 Vendors 20 SoC families

The boards are the point, and the spread is deliberate. Rockchip, Amlogic, Allwinner, NXP, Marvell, Broadcom, TI, Samsung, Qualcomm, SpacemiT and x86 are all represented, because that is where the differences live; a change to a shared kernel config lands differently on rockchip64 than on meson64, and only one of them will tell you so.

Vendors currently on the bench include Radxa, FriendlyELEC, Khadas, Orange Pi, Banana Pi, Odroid, Raspberry Pi, Pine64, SolidRun, Mekotronics, Kobol, Cubietech, Udoo, Inovato and Arduino. Of the 65, 56 are active and 9 are in a failed state at the moment article was done boards that need a hand in the rack. That number is itself a signal: a board that has stopped answering is a board that stopped being able to report, which is usually more interesting than a test that merely failed.

Every board is registered in NetBox, which is the source of truth for the whole system. Not just an asset list the orchestrator reads it to decide what a board can be tested with. Power is derived from cabling topology rather than a field someone typed: a board's power port is cabled to an outlet on a controller device, and the controller carries the driver. If the cable is not in the model, the board is treated as having no managed power, and the tests that need a hard power cut are skipped rather than faked.

The hardware it takes

Per bench, and the shared infrastructure behind it

The cost of adding a board is not the board. It is the wiring around it. Each bench needs some subset of the following, and which subset a board has determines which tests it is eligible for.

Remote power Required

A way to cut and restore power without a human. Three backends are in use: PoE switch ports for anything powered over Ethernet, a switched rack PDU for mains devices, and a 24-channel relay board driven over GPIO for DC-barrel and USB-powered boards. Without this there is no cold-boot test, only a soft reboot which is exactly the case that tends to pass while the real one fails.

Network Required

Wired Ethernet on a managed switch. This is the control channel (the harness drives boards over SSH), the measurement channel for throughput tests, and on PoE benches, the power channel too. A board that only has Wi-Fi is testable but much harder to recover.

Power metering Strongly recommended

PoE ports meter per-port draw, so the harness samples watts throughout a run. This is how you tell a board that genuinely rebooted from one whose SoC never stopped executing the power trace is flat across what was supposed to be a power cycle.

Serial console Recommended

USB-to-TTL adapters on a powered hub, exposed over the network as named consoles. Without one, a board that fails to boot tells you nothing at all: you get silence and have to guess. Several boards in the rack currently lack one, and every hang on those is an investigation that stalls at "it does not come back".

Clean-flash path Not yet wired

An SD-card switcher that presents the card to a flasher host or to the board, or USB access for vendor recovery modes. This is what makes a board recoverable from software that does not boot. The framework supports it; no bench in the rack is currently wired for it, which is the single biggest constraint on what comes next.

Behind the benches sits the shared infrastructure, the part people underestimate when they picture "a few boards on a shelf":

  • Switching. Three core switches and four access switches, several of them PoE, which do double duty as the fleet's power controllers. Between them they carry the control network, the test traffic and the power for a large fraction of the boards. This is no longer just a 1 GbE network: newer boards increasingly come with 2.5 GbE, while the uplinks and core need 10 GbE to aggregate traffic from many boards running tests in parallel. Without that headroom, the lab network itself becomes the bottleneck and network-performance results stop measuring the board under test.
  • Power delivery. A switched rack PDU, multi-channel DC supplies, multiple 16-way USB supply, switched power strips, and a UPS in front of all of it because a lab that loses power mid-write is a lab that corrupts SD cards.
  • Console and out-of-band. Dedicated console hosts, including a KVM device for the machines that need screen-level access.
  • Compute. Six servers in the same site, including two Ampere-class ARM machines, running the CI runners that execute the build and test jobs and the services the fleet depends on.

All of it is scripted. Each class of hardware has a small command-line tool with the same shape — status, on, off, powercycle so the harness does not care whether a board is switched by a PoE port, a PDU outlet or a relay channel. It resolves the path from the inventory model and calls whichever tool matches.

What a nightly run does

The cycle, end to end

The fleet does not stay powered. A full cycle brings it up, tests it, and puts it back to sleep. The last step runs even when everything before it failed.

  1. Power on The fleet is brought up from the PDU and the boards are given several minutes to boot.
  2. Scan and reconcile Every board is probed and the inventory updated: what version it is running, what kernel, when it was last seen. Drift between the model and reality is recorded rather than assumed away.
  3. Sync maintainer keys Board maintainers' SSH keys are pushed to the boards they own, so the person responsible for a board can log into the actual unit that failed.
  4. Run the board pipeline A matrix job per board, in parallel across the runners. This is the part below.
  5. Scan again Post-test state is captured; what the run left behind, not just what it reported.
  6. Power off Always, including after a failure. A rack left powered on a failed run is a rack that cooks.

Inside step four, each board runs the same pipeline. It upgrades to the nightly repository, reboots, and then walks every kernel branch that board is configured to test:

StepWhat it does
upgradePoint at the nightly repository and install what is currently published.
rebootVerify that the board comes back with what it already had installed.
For each branchRepeat the steps below for each kernel branch (current, edge, …).
↳ kernel-switchInstall that branch's kernel and verify that it is fully configured.
↳ rebootPerform warm reboots, followed by a cold power cycle where switched power is available.
↳ hw-performanceTest CPU, memory, disk and temperature.
↳ dvfsVerify that the governor actually reaches the frequencies it claims.
↳ network-iperfMeasure throughput on each cabled network interface.
↳ store-versionsRecord exactly what is installed and running.
restore-stablePut the board back the way it was found.

Two details in there carry more weight than they look. The reboot module does warm reboots followed by a cold power cycle, because those fail differently: a board can survive reboot indefinitely and still not come back from a real power cut. Testing both is the only way to catch both failure modes. And kernel-switch verifies that the package is genuinely configured rather than trusting an exit code, because the interesting failures can leave a kernel half-installed while every command reports success.

What the results look like

Booting every board, every night

Current results are published publicly at docs.armbian.com/status/board-tests, refreshed as runs complete.

What it actually catches

Here are few examples from recent runs.

Reboots that hang on both kernels

One board fails every reboot attempt on both of its kernel branches. The power trace shows the draw holding steady through what should have been a restart — the SoC never stopped executing.

That points at firmware rather than the kernel, but the issue remains unresolved. It is also a good example of the console gap: that bench has no serial console, so the investigation is relying on power measurements and inference instead of a boot log.

A test that was wrong about x86

The frequency-scaling check assumed that a governor under load should reach at least 95% of the maximum advertised frequency. That works for ARM cpufreq, but not for Intel and AMD, where the driver manages turbo behaviour itself and the advertised maximum is not a promise.

Every x86 board was therefore failing a test that was itself wrong. The test was fixed by detecting the driver and applying the check only where it makes sense.

Telling a broken board from a broken runner

Self-hosted runners occasionally drop mid-job: the test finishes green, then the job dies later and the run is marked failed. Retrying everything would be wrong. A board pipeline power-cycles hardware and takes about half an hour, so retrying a genuine failure wastes rack time and keeps cycling a board that may already be unwell.

The retry logic therefore re-runs only jobs whose test step did not fail. A real hardware or test failure stays red rather than being hidden by an automatic retry.

Where AI fits

And where it explicitly does not

A large share of the tooling described here — the test modules, hardware control scripts, inventory reconciliation and documentation — is now written and maintained with AI assistance. That is worth being plain about, including the parts that go wrong.

What AI is genuinely good at is shortening the distance from symptom to candidate explanation. A board fails; there is a transcript, a package state, a power trace, a kernel version and forty thousand lines of shell across several repositories. Correlating those quickly, proposing a mechanism and drafting a patch is work that used to take an evening and can now take a few minutes.

What it is bad at is knowing when it is wrong. In the course of this work, an analysis confidently concluded that a particular board had never appeared in the test results. The conclusion came from a sample that covered about three-quarters of the archive and happened to miss both of that board's records. The reasoning was sound; the evidence was partial; nothing in the output said so.

The point

AI shortens the distance from symptom to patch. It does not shorten the distance from patch to proof. Those are different problems, and only one of them has been made easier.

That is precisely why the rack matters more now, not less. If proposing changes gets cheaper while validating them does not, the amount of unverified change grows faster than our ability to verify it. And the most dangerous bugs here are exactly the ones that compile cleanly, install without error, and fail only when a specific board is asked to come back from a power cut.

A machine that is confidently wrong is a fine collaborator as long as something downstream can check it. Sixty-five boards that will actually try to boot are that something.

So the working rule is simple: AI is free to propose anything, but nothing reaches a board on its say-so. Hardware evidence is the gate, and every conclusion that matters is expected to point at a run, a trace or a package state rather than an argument.

What is next: validation at pull-request time

The change we want to make

Today the facility validates nightly builds. Whatever was published overnight gets installed on real hardware and exercised. That is genuinely useful, and it is how the bugs above were found, but it is validation after the fact. By the time a board fails, the change is already in the nightly repository and, depending on timing, already on users' machines.

The goal is to move that gate earlier: a pull request that touches a board family gets that family's boards booted before it merges. Not the whole rack for every PR, just the boards the change can actually reach.

Several things have to be true first, and they are worth stating honestly rather than as a roadmap of solved problems.

Selection

A diff has to map to boards. A change to a board configuration file implicates that board; a change to a kernel family implicates every board in it; a change to the packaging code implicates everything. Select too broadly and every PR occupies the entire rack for half an hour. Select too narrowly and the one board that would have caught the regression never gets tested.

Artifacts

A PR build currently proves a compile. Hardware testing needs installable packages the rack can pull and install exactly as a user would, which means PR builds must publish to an isolated repository the fleet can reach. Our current build machinery is already stretched by existing CI and release workloads. Making hardware testing part of routine PR validation will require additional build capacity, storage and package-publishing infrastructure.

Time budget

A full board pipeline takes around thirty minutes. That is acceptable overnight and much too slow as a merge gate, particularly when a nightly cycle already has the rack. This needs a short profile for PRs: install, switch kernel, reboot warm and cold, and confirm it is running what was installed. Performance and throughput work can stay in the nightly run. It also needs real contention handling, so a PR does not simply queue behind a fleet cycle.

Recovery

This is the hard one, and it is a hardware problem rather than a software one. Testing unmerged code means occasionally installing a kernel that does not boot. Right now every bench in the rack is tested in place; there is no remote path to reflash a board whose boot is broken. A board that a bad PR bricks is a board that stays bricked until somebody walks to the rack.

So PR-stage testing starts on benches that can be recovered remotely: SD-card switchers for boards that boot from removable media, and vendor recovery modes over USB for those that support it. Wiring that up across the fleet is the prerequisite that gates everything else, and it is where the next round of hardware effort goes. Boards that cannot be recovered remotely stay on nightly testing, where a failure is an inconvenience instead of a dead unit.

Signal quality

A merge gate that fails for reasons unrelated to the change is worse than no gate: it trains people to ignore it. The distinction between a board failure and a broken bench, already important for nightly runs, becomes critical the moment a red result blocks a merge.

Helping

Infrastructure, capacity, partnerships

There are three practical ways to move this forward.

Bench infrastructure. Remote recovery is the immediate blocker for PR-stage testing, particularly SD-card switchers and the wiring around them. The network also needs to grow with the hardware being tested: managed PoE switches with 2.5 GbE access ports and 10 GbE uplinks, plus PoE splitters for boards that cannot be powered directly over Ethernet. These are not just infrastructure upgrades; they expand what can be tested, measured and recovered without somebody standing in front of the rack.

Build capacity. PR-stage hardware testing needs PR builds, and build queue time is already a constraint on how quickly a fix reaches hardware. More build capacity, storage and package-publishing infrastructure are needed to move validation from nightly runs into the pull-request workflow. If you can host a build server, the requirements are documented, and the current fleet is listed on the build machinery page.

Hardware partnerships. For vendors, the facility provides a way to keep hardware under continuous validation rather than testing it once around release. Devices covered by support and maintenance agreements can become part of the permanent test fleet, where kernel updates, upgrades, reboots, networking and other regressions are exercised on real hardware as Armbian evolves. The value is not the board itself; it is keeping that board working over its supported lifetime.

View the full article

]]>62343Wed, 30 Sep 2026 18:29:14 +0000[Armbian newsletter] - Booting every board, every nighthttps://testforum.armbian.com/topic/62341-armbian-newsletter-booting-every-board-every-night/

Armbian builds for hundreds of boards. A kernel bump that is clean on one SoC can leave another unbootable and no build log will tell you. So there is a rack, and the rack boots them.

Compiling is not evidence. A kernel that builds, packages that install, an image that flashes — none of it proves a board comes back after reboot. Armbian supports a very large number of boards across a dozen vendors and twenty SoC families, maintained largely by volunteers who each own one or two of them. The failure mode that hurts is not a broken build. It is a change that builds perfectly and quietly bricks the boot path on hardware nobody happened to have on their desk that week.

The automated test facility exists to close that gap. It is a rack of real boards, wired for remote power, that installs what Armbian published and then tries to use it: upgrade, switch kernel branches, reboot repeatedly, measure, report. What follows is what it does today, the hardware it takes to run, where AI fits into maintaining the stack around it, and the change we want to make next: moving hardware validation from nightly builds to pull requests.

What is in the rack

Fleet composition, as recorded in inventory

65 Boards under test 62 Distinct models 22 Vendors 20 SoC families

The boards are the point, and the spread is deliberate. Rockchip, Amlogic, Allwinner, NXP, Marvell, Broadcom, TI, Samsung, Qualcomm, SpacemiT and x86 are all represented, because that is where the differences live; a change to a shared kernel config lands differently on rockchip64 than on meson64, and only one of them will tell you so.

Vendors currently on the bench include Radxa, FriendlyELEC, Khadas, Orange Pi, Banana Pi, Odroid, Raspberry Pi, Pine64, SolidRun, Mekotronics, Kobol, Cubietech, Udoo, Inovato and Arduino. Of the 65, 56 are active and 9 are in a failed state at the moment article was done boards that need a hand in the rack. That number is itself a signal: a board that has stopped answering is a board that stopped being able to report, which is usually more interesting than a test that merely failed.

Every board is registered in NetBox, which is the source of truth for the whole system. Not just an asset list the orchestrator reads it to decide what a board can be tested with. Power is derived from cabling topology rather than a field someone typed: a board's power port is cabled to an outlet on a controller device, and the controller carries the driver. If the cable is not in the model, the board is treated as having no managed power, and the tests that need a hard power cut are skipped rather than faked.

The hardware it takes

Per bench, and the shared infrastructure behind it

The cost of adding a board is not the board. It is the wiring around it. Each bench needs some subset of the following, and which subset a board has determines which tests it is eligible for.

Remote power Required

A way to cut and restore power without a human. Three backends are in use: PoE switch ports for anything powered over Ethernet, a switched rack PDU for mains devices, and a 24-channel relay board driven over GPIO for DC-barrel and USB-powered boards. Without this there is no cold-boot test, only a soft reboot which is exactly the case that tends to pass while the real one fails.

Network Required

Wired Ethernet on a managed switch. This is the control channel (the harness drives boards over SSH), the measurement channel for throughput tests, and on PoE benches, the power channel too. A board that only has Wi-Fi is testable but much harder to recover.

Power metering Strongly recommended

PoE ports meter per-port draw, so the harness samples watts throughout a run. This is how you tell a board that genuinely rebooted from one whose SoC never stopped executing the power trace is flat across what was supposed to be a power cycle.

Serial console Recommended

USB-to-TTL adapters on a powered hub, exposed over the network as named consoles. Without one, a board that fails to boot tells you nothing at all: you get silence and have to guess. Several boards in the rack currently lack one, and every hang on those is an investigation that stalls at "it does not come back".

Clean-flash path Not yet wired

An SD-card switcher that presents the card to a flasher host or to the board, or USB access for vendor recovery modes. This is what makes a board recoverable from software that does not boot. The framework supports it; no bench in the rack is currently wired for it, which is the single biggest constraint on what comes next.

Behind the benches sits the shared infrastructure, the part people underestimate when they picture "a few boards on a shelf":

  • Switching. Three core switches and four access switches, several of them PoE, which do double duty as the fleet's power controllers. Between them they carry the control network, the test traffic and the power for a large fraction of the boards. This is no longer just a 1 GbE network: newer boards increasingly come with 2.5 GbE, while the uplinks and core need 10 GbE to aggregate traffic from many boards running tests in parallel. Without that headroom, the lab network itself becomes the bottleneck and network-performance results stop measuring the board under test.
  • Power delivery. A switched rack PDU, multi-channel DC supplies, multiple 16-way USB supply, switched power strips, and a UPS in front of all of it because a lab that loses power mid-write is a lab that corrupts SD cards.
  • Console and out-of-band. Dedicated console hosts, including a KVM device for the machines that need screen-level access.
  • Compute. Six servers in the same site, including two Ampere-class ARM machines, running the CI runners that execute the build and test jobs and the services the fleet depends on.

All of it is scripted. Each class of hardware has a small command-line tool with the same shape — status, on, off, powercycle so the harness does not care whether a board is switched by a PoE port, a PDU outlet or a relay channel. It resolves the path from the inventory model and calls whichever tool matches.

What a nightly run does

The cycle, end to end

The fleet does not stay powered. A full cycle brings it up, tests it, and puts it back to sleep. The last step runs even when everything before it failed.

  1. Power on The fleet is brought up from the PDU and the boards are given several minutes to boot.
  2. Scan and reconcile Every board is probed and the inventory updated: what version it is running, what kernel, when it was last seen. Drift between the model and reality is recorded rather than assumed away.
  3. Sync maintainer keys Board maintainers' SSH keys are pushed to the boards they own, so the person responsible for a board can log into the actual unit that failed.
  4. Run the board pipeline A matrix job per board, in parallel across the runners. This is the part below.
  5. Scan again Post-test state is captured; what the run left behind, not just what it reported.
  6. Power off Always, including after a failure. A rack left powered on a failed run is a rack that cooks.

Inside step four, each board runs the same pipeline. It upgrades to the nightly repository, reboots, and then walks every kernel branch that board is configured to test:

StepWhat it does
upgradePoint at the nightly repository and install what is currently published.
rebootVerify that the board comes back with what it already had installed.
For each branchRepeat the steps below for each kernel branch (current, edge, …).
↳ kernel-switchInstall that branch's kernel and verify that it is fully configured.
↳ rebootPerform warm reboots, followed by a cold power cycle where switched power is available.
↳ hw-performanceTest CPU, memory, disk and temperature.
↳ dvfsVerify that the governor actually reaches the frequencies it claims.
↳ network-iperfMeasure throughput on each cabled network interface.
↳ store-versionsRecord exactly what is installed and running.
restore-stablePut the board back the way it was found.

Two details in there carry more weight than they look. The reboot module does warm reboots followed by a cold power cycle, because those fail differently: a board can survive reboot indefinitely and still not come back from a real power cut. Testing both is the only way to catch both failure modes. And kernel-switch verifies that the package is genuinely configured rather than trusting an exit code, because the interesting failures can leave a kernel half-installed while every command reports success.

What the results look like

Booting every board, every night

Current results are published publicly at docs.armbian.com/status/board-tests, refreshed as runs complete.

What it actually catches

Here are few examples from recent runs.

Reboots that hang on both kernels

One board fails every reboot attempt on both of its kernel branches. The power trace shows the draw holding steady through what should have been a restart — the SoC never stopped executing.

That points at firmware rather than the kernel, but the issue remains unresolved. It is also a good example of the console gap: that bench has no serial console, so the investigation is relying on power measurements and inference instead of a boot log.

A test that was wrong about x86

The frequency-scaling check assumed that a governor under load should reach at least 95% of the maximum advertised frequency. That works for ARM cpufreq, but not for Intel and AMD, where the driver manages turbo behaviour itself and the advertised maximum is not a promise.

Every x86 board was therefore failing a test that was itself wrong. The test was fixed by detecting the driver and applying the check only where it makes sense.

Telling a broken board from a broken runner

Self-hosted runners occasionally drop mid-job: the test finishes green, then the job dies later and the run is marked failed. Retrying everything would be wrong. A board pipeline power-cycles hardware and takes about half an hour, so retrying a genuine failure wastes rack time and keeps cycling a board that may already be unwell.

The retry logic therefore re-runs only jobs whose test step did not fail. A real hardware or test failure stays red rather than being hidden by an automatic retry.

Where AI fits

And where it explicitly does not

A large share of the tooling described here — the test modules, hardware control scripts, inventory reconciliation and documentation — is now written and maintained with AI assistance. That is worth being plain about, including the parts that go wrong.

What AI is genuinely good at is shortening the distance from symptom to candidate explanation. A board fails; there is a transcript, a package state, a power trace, a kernel version and forty thousand lines of shell across several repositories. Correlating those quickly, proposing a mechanism and drafting a patch is work that used to take an evening and can now take a few minutes.

What it is bad at is knowing when it is wrong. In the course of this work, an analysis confidently concluded that a particular board had never appeared in the test results. The conclusion came from a sample that covered about three-quarters of the archive and happened to miss both of that board's records. The reasoning was sound; the evidence was partial; nothing in the output said so.

The point

AI shortens the distance from symptom to patch. It does not shorten the distance from patch to proof. Those are different problems, and only one of them has been made easier.

That is precisely why the rack matters more now, not less. If proposing changes gets cheaper while validating them does not, the amount of unverified change grows faster than our ability to verify it. And the most dangerous bugs here are exactly the ones that compile cleanly, install without error, and fail only when a specific board is asked to come back from a power cut.

A machine that is confidently wrong is a fine collaborator as long as something downstream can check it. Sixty-five boards that will actually try to boot are that something.

So the working rule is simple: AI is free to propose anything, but nothing reaches a board on its say-so. Hardware evidence is the gate, and every conclusion that matters is expected to point at a run, a trace or a package state rather than an argument.

What is next: validation at pull-request time

The change we want to make

Today the facility validates nightly builds. Whatever was published overnight gets installed on real hardware and exercised. That is genuinely useful, and it is how the bugs above were found, but it is validation after the fact. By the time a board fails, the change is already in the nightly repository and, depending on timing, already on users' machines.

The goal is to move that gate earlier: a pull request that touches a board family gets that family's boards booted before it merges. Not the whole rack for every PR, just the boards the change can actually reach.

Several things have to be true first, and they are worth stating honestly rather than as a roadmap of solved problems.

Selection

A diff has to map to boards. A change to a board configuration file implicates that board; a change to a kernel family implicates every board in it; a change to the packaging code implicates everything. Select too broadly and every PR occupies the entire rack for half an hour. Select too narrowly and the one board that would have caught the regression never gets tested.

Artifacts

A PR build currently proves a compile. Hardware testing needs installable packages the rack can pull and install exactly as a user would, which means PR builds must publish to an isolated repository the fleet can reach. Our current build machinery is already stretched by existing CI and release workloads. Making hardware testing part of routine PR validation will require additional build capacity, storage and package-publishing infrastructure.

Time budget

A full board pipeline takes around thirty minutes. That is acceptable overnight and much too slow as a merge gate, particularly when a nightly cycle already has the rack. This needs a short profile for PRs: install, switch kernel, reboot warm and cold, and confirm it is running what was installed. Performance and throughput work can stay in the nightly run. It also needs real contention handling, so a PR does not simply queue behind a fleet cycle.

Recovery

This is the hard one, and it is a hardware problem rather than a software one. Testing unmerged code means occasionally installing a kernel that does not boot. Right now every bench in the rack is tested in place; there is no remote path to reflash a board whose boot is broken. A board that a bad PR bricks is a board that stays bricked until somebody walks to the rack.

So PR-stage testing starts on benches that can be recovered remotely: SD-card switchers for boards that boot from removable media, and vendor recovery modes over USB for those that support it. Wiring that up across the fleet is the prerequisite that gates everything else, and it is where the next round of hardware effort goes. Boards that cannot be recovered remotely stay on nightly testing, where a failure is an inconvenience instead of a dead unit.

Signal quality

A merge gate that fails for reasons unrelated to the change is worse than no gate: it trains people to ignore it. The distinction between a board failure and a broken bench, already important for nightly runs, becomes critical the moment a red result blocks a merge.

Helping

Infrastructure, capacity, partnerships

There are three practical ways to move this forward.

Bench infrastructure. Remote recovery is the immediate blocker for PR-stage testing, particularly SD-card switchers and the wiring around them. The network also needs to grow with the hardware being tested: managed PoE switches with 2.5 GbE access ports and 10 GbE uplinks, plus PoE splitters for boards that cannot be powered directly over Ethernet. These are not just infrastructure upgrades; they expand what can be tested, measured and recovered without somebody standing in front of the rack.

Build capacity. PR-stage hardware testing needs PR builds, and build queue time is already a constraint on how quickly a fix reaches hardware. More build capacity, storage and package-publishing infrastructure are needed to move validation from nightly runs into the pull-request workflow. If you can host a build server, the requirements are documented, and the current fleet is listed on the build machinery page.

Hardware partnerships. For vendors, the facility provides a way to keep hardware under continuous validation rather than testing it once around release. Devices covered by support and maintenance agreements can become part of the permanent test fleet, where kernel updates, upgrades, reboots, networking and other regressions are exercised on real hardware as Armbian evolves. The value is not the board itself; it is keeping that board working over its supported lifetime.

View the full article

]]>62341Wed, 30 Sep 2026 18:29:14 +0000[News from Armbian] - JetHome boosts Armbian CIhttps://testforum.armbian.com/topic/62336-news-from-armbian-jethome-boosts-armbian-ci/

JetHome (Shenzhen JetHome Technology Co.) donated a build server for Armbian. The server compiles Armbian images, kernels and U-Boot packages. Thank you, JetHome.

HW Specifications

CPU
2 × Intel Xeon Gold 6148, 80 threads
Memory
384 GB
Storage
3.84 TB SSD, plus 20 TB of disk
Network
2 × 1 Gbit/s, bonded
Build runners
40

That is about a tenth of the fleet's capacity, running up to 3 kernel or 40 full image builds at once.

The server also remembers work it has already done:

  • Compiled code is reused. A rebuild takes under a minute instead of three.
  • Software packages are downloaded once and shared by all 40 build jobs.
  • Source code and ready-made parts, such as kernels, are fetched once and kept on the server.

The fleet today

18 build servers · 774 CPU threads · 322 build runners

With 2371 GB of memory across x86-64 and ARM servers. Part of the fleet sleeps and powers up only when builds are waiting.

Current build servers are sponsored by JetHome, the OSU Open Source Lab and netcup. Armbian members sponsor all other servers.

See the live list on the build machinery page.

We need more build servers!

More servers mean more than more boards. We want faster CI, and more building and testing of every pull request, so community developers get feedback sooner and fixes reach users faster. Today the build queue is longer than it should be.

Minimum
Ideal
CPU
16 cores
32 cores
Memory
64 GB
128 GB
Storage (NVMe)
512 GB
1 TB
Upload
50 Mbit/s
1 Gbit/s

Both x86-64 and arm64 help. The server runs only Armbian builds, and we credit your hosting on the build machinery page.

Spare CPU cores and a fast uplink? Put them to work compiling Armbian for hundreds of boards.

Donate build capacity

View the full article

]]>62336Wed, 30 Sep 2026 15:26:59 +0000[Armbian newsletter] - JetHome boosts Armbian CIhttps://testforum.armbian.com/topic/62334-armbian-newsletter-jethome-boosts-armbian-ci/

JetHome (Shenzhen JetHome Technology Co.) donated a build server for Armbian. The server compiles Armbian images, kernels and U-Boot packages. Thank you, JetHome.

HW Specifications

CPU
2 × Intel Xeon Gold 6148, 80 threads
Memory
384 GB
Storage
3.84 TB SSD, plus 20 TB of disk
Network
2 × 1 Gbit/s, bonded
Build runners
40

That is about a tenth of the fleet's capacity, running up to 3 kernel or 40 full image builds at once.

The server also remembers work it has already done:

  • Compiled code is reused. A rebuild takes under a minute instead of three.
  • Software packages are downloaded once and shared by all 40 build jobs.
  • Source code and ready-made parts, such as kernels, are fetched once and kept on the server.

The fleet today

18 build servers · 774 CPU threads · 322 build runners

With 2371 GB of memory across x86-64 and ARM servers. Part of the fleet sleeps and powers up only when builds are waiting.

Current build servers are sponsored by JetHome, the OSU Open Source Lab and netcup. Armbian members sponsor all other servers.

See the live list on the build machinery page.

We need more build servers!

More servers mean more than more boards. We want faster CI, and more building and testing of every pull request, so community developers get feedback sooner and fixes reach users faster. Today the build queue is longer than it should be.

Minimum
Ideal
CPU
16 cores
32 cores
Memory
64 GB
128 GB
Storage (NVMe)
512 GB
1 TB
Upload
50 Mbit/s
1 Gbit/s

Both x86-64 and arm64 help. The server runs only Armbian builds, and we credit your hosting on the build machinery page.

Spare CPU cores and a fast uplink? Put them to work compiling Armbian for hundreds of boards.

Donate build capacity

View the full article

]]>62334Wed, 30 Sep 2026 15:26:59 +0000[News from Armbian] - Mali GPU with LiteRT-LMhttps://testforum.armbian.com/topic/62337-news-from-armbian-mali-gpu-with-litert-lm/Running Gemma 4 E2B on a Mali GPU with LiteRT-LMMali GPU with LiteRT-LM

This guide should work on any armbian minimal/console (trixie) system with a working Mali-g610 GPU.

DO NOT USE DESKTOP

Verified on: Orange Pi 5 Max (Rockchip RK3588, Arm Mali-G610 MC4), Armbian/Debian 13 (trixie), aarch64, 8 GB RAM.

Status summary: Both CPU (XNNPACK) and GPU (WebGPU/Dawn → Vulkan → panvk → panthor) work on the mainline panthor kernel — numbers below. The GPU path needed one line of local patching in
Mesa's panvk driver (raise maxImageDimension3D 512 → 2048 to meet the WebGPU minimums that LiteRT's Dawn library enforces; recipe in §5, rationale in §7.1). The model is multimodal (Text + Vision + Audio): the vision encoder runs on the same patched panvk via--vision-backend gpu (§5 "VL path" results). The vendor Rockchip libmali route and OpenCL remain unavailable on mainline panthor (§7.2, §7.3).

Stack (as shipped):

Gemma 4 E2B (.litertlm, int4)  →  LiteRT-LM CLI  →  LiteRT GPU accelerator (WebGPU/ML Drift)

Dawn (WebGPU impl) → Vulkan → panvk → panthor (kernel) → Mali-G610

1. Prerequisites

  • ARM (aarch64) Linux with a Mali GPU and at least 8 GB RAM.
  • Armbian/Debian 13 (trixie)
  • The panthor (or panfrost for older Mali) kernel driver active:
ls /dev/dri/renderD128          # render node must exist
lsmod | grep panthor            # or panfrost / lima

Full ARMv8.2-A dotprod support is required — LiteRT's ARM64 binaries are built with it and will SIGILL otherwise:lscpu | grep -w asimddp (both A55 and A76 cores list it here).

2. Install Mesa + Vulkan for Mali (needs root)

sudo apt update
# Prefer the newest Mesa (backports on Debian) for the best panvk coverage of Valhall CSF GPUs:
sudo apt install -y -t trixie-backports mesa-vulkan-drivers libvulkan1 vulkan-tools
# Optional (see §7 — currently yields NO usable OpenCL device on panthor):
sudo apt install -y -t trixie-backports mesa-opencl-icd clinfo

Verify the GPU is visible to Vulkan:

vulkaninfo --summary | grep -iE "deviceName|driverName"
# Expect: deviceName = Mali-G610 MC4   driverName = panvk

3. Install the LiteRT-LM CLI (user space, no root)

curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
uv tool install litert-lm        # current: v0.17.x; incl. CPU (XNNPACK/YNNPACK) + GPU (WebGPU/Vulkan) backends

4. Get the model (Gemma 4 E2B, int4 .litertlm, 2.58 GB)

mkdir -p ~/litert-lm-bench && cd ~/litert-lm-bench
curl -L -o gemma-4-E2B-it.litertlm \
  https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm
# or have the CLI fetch it for you:
#   litert-lm benchmark --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm gemma-4-E2B-it.litertlm

Other ready models: google/gemma-3n-E2B-it-litert-lm (gemma-3n-E2B-it-int4.litertlm),litert-community/gemma-4-E4B-it-litert-lm, ... (see litert-lm list / HF).

5. Benchmark

Lock the CPU governor to performance first (fair, repeatable numbers):

sudo sh -c 'for c in /sys/devices/system/cpu/cpu[0-7]/cpufreq/scaling_governor; do echo performance > $c; done'

CPU baseline (XNNPACK, 8 threads):

litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  -p 1024 -d 256 --backend cpu --cpu-thread-count 8 --cache disk --runs 2

GPU (patched panvk, §7.1). One-time local Mesa build — stays entirely in userland, the system Mesa is untouched:

# 1) Mesa source + one-line patch (26.1.2)
cd ~/litert-lm-bench
curl -L -o mesa.tar.xz https://archive.mesa3d.org/mesa-26.1.2.tar.xz
tar -xf mesa.tar.xz && cd mesa-26.1.2
python3 - <<'PY'
p = 'src/panfrost/vulkan/panvk_vX_physical_device.c'
s = open(p).read()
s = s.replace('.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),',
              '.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min */')
open(p, 'w').write(s)
PY

# 2) build deps (the LLVM/CLC chain is required — panvk bakes CLC-compiled SPIR-V for libpan)
sudo apt install -y --no-install-recommends meson ninja-build pkg-config gcc g++ python3-mako \
  python3-yaml python3-ply libdrm-dev llvm-19-dev libllvmspirvlib-19-dev spirv-tools \
  libclang-19-dev libclang-cpp19-dev

# 3) panvk-only build (~10–25 min on the 5 Max)
meson setup build-panvk -Dvulkan-drivers=panfrost -Dgallium-drivers= -Dbuildtype=release \
  -Dllvm=enabled -Dmesa-clc=auto -Dplatforms= -Degl=disabled -Dgbm=disabled -Dglx=disabled \
  -Dopengl=false -Dglvnd=disabled -Dtools= -Dbuild-tests=false
ninja -C build-panvk -j6

# 4) benchmark with the patched driver, process-scoped. First put the WebGPU prebuilts
#    (libLiteRtTopKWebGpuSampler.so + libwebgpu_dawn.so etc., litert-lm repo tag v0.17.1,
#    prebuilt/linux_arm64) in ~/litert-lm-bench/prebuilt_v0171/ — see Troubleshooting.
export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk
export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json"
export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171"
export PATH="$HOME/.local/bin:$PATH"            # uv-installed CLI
litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  -p 1024 -d 256 --backend gpu --cache disk --runs 2

First GPU run compiles the WebGPU/Vulkan shaders (one-time) and uploads GPU-rearranged weights (~0.8 GB weight cache); --cache disk persists both next to the model, so later loads start fast — the compile cost is NOT repaid on every run.

Results on this Orange Pi 5 Max (Mali-G610 MC4)

Backend Prefill (tk/s) Decode (tk/s) TTFT (s)
CPU (XNNPACK, 8 threads) 123.6 12.3 8.4
GPU (WebGPU/Dawn→Vulkan, patched panvk §5/§7.1) 374.0 8.7 2.9

Google's on-device-class references for Gemma 4 E2B: S26 Ultra GPU 3808/52 tk/s, Raspberry Pi 5 CPU 133/7.6 tk/s. On this board the GPU wins the prefill race by ~3.0× (374 vs 124 tk/s) and TTFT by ~2.9× (2.9 vs 8.4 s), while decode stays on the CPU's side (8.7 vs 12.3 tk/s) — as expected, decode is the bottleneck on Mali-class hardware; the Mali GPU is a prefill/TTFT accelerator here, not a decode accelerator.

GPU clock note (measured, no guesswork): the Mali-G610 is an integrated GPU sharing the board's DDR. The devfreq governor (simple_ondemand, stock) boosts it to 1 GHz under load and parks it at 200 MHz idle — confirmed by sampling cur_freq at 400 ms during the run (233/263 samples at 1000 MHz, temps 41→56 °C, no thermal trip). Leave the governor alone: forcingperformance/min/max via sysfs was counterproductive (idle readbacks that look like the clock collapsed, and it destabilized perfectly good runs). The numbers above are at the stock governor's real 1 GHz boost.

Results: Gemma 4 E4B (4B) — text GPU via the web flavor, vision GPU straight from stock

E4B (the 4B sibling) ships as three files in the HF repo: the stock gemma-4-E4B-it.litertlm (text+vision+audio, 3.66 GB) plus an -gpu and a -web (text-only, 2.97 GB) variant. On this 8 GB board the stock file cannot run on the GPU — two structural walls, both measured:

panthor job watchdog: a fixed one-shot pipeline dispatch (dmesg: job timeout ... seqno=144, same job on every E4B attempt) exceeds the driver's compiled-in 1 s job timeout even at the real 1 GHz boost (E2B's equivalent is seqno=77 and fits). The GPU is reset, Dawn reports VK_ERROR_DEVICE_LOST, generation aborts.

8 GB RAM ceiling: GPU buffers (pinned, unrescalable shmem) peak near 4–5 GB on top of the 3.66 GB model; every run ended in a global OOM-kill (EXIT=137) during iteration 2 even with a 2048-token KV cap + ringbuffers + disk cache.

The -web flavor dodges both — its finer op layout splits the killer dispatch under the 1 s bar and shrinks the GPU working set (peak 4.3 GB observed, holds 1 GHz the whole run):

Gemma 4 E4B lane Flavor Prefill (tk/s) Decode (tk/s) TTFT (s)
CPU (XNNPACK, 8 threads) stock 52.6 5.58 19.6
GPU (patched panvk) web (text-only) 75.1 4.54 13.9

(reproducible to the decimal across --runs 2; init 6.2 s; note --cache disk does not persist for the web flavor — expect a recompile each run. --speculative-decoding true gave no gain:4.37 vs 4.54 tok/s decode (this build ships no draft model).) Reference: Raspberry Pi 5 (16 GB, CPU) 51/3.2/20.5 — this board matches or beats it on every column. Same shape as E2B: GPU wins prefill +1.4× and TTFT 19.6→13.9 s, but decode stays CPU-favored (4.5 vs 5.6 tk/s).

E4B vision (VL) on GPU works — cpu text + gpu vision

The stock E4B's vision encoder is a separate 1477-op subgraph that fits under the panthor watchdog and inside 8 GB even though the full stock model's text lane does not. Drive it via the Engine API (this repo's vl_bench.py --model ...), LLM lane = CPU, vision encoder = GPU (patched panvk): the test image (resized to 912×672 → 2394 patches, near E4B's max_num_patches 2520) is encoded on the Mali.

E4B VL (LLM lane = cpu) vision cpu vision gpu (patched panvk)
TTFT (s) 12.3–12.5 9.6
Decode (tok/s) 7.33–7.37 7.28–7.39
Reply (same image) "coyote walking on a dirt path" identical

Text-only CPU control: TTFT ≈ 2.0 s (7-token prompt, decode ~7.8 tok/s). Isolated vision-encode cost: ~10.4 s CPU vs ~7.6 s GPU — the Mali cuts E4B vision latency by ~2.9 s/image (~27%). No watchdog hits, no OOM (peaks well below ceiling; vision weights are a fraction of a GB). Same conclusion as E2B: for vision work keep the LLM on CPU and let the GPU run the encoder.

# 1. SET ENVIRONMENT FOR GPU VISION DELEGATE
  export LITERT_VISION_DELEGATE=gpu

  # 2. RUN VL HARNESS FOR STOCK GEMMA-4-E4B
~/.local/share/uv/tools/litert-lm/bin/python vl_bench.py \
    --text cpu \
    --vision gpu \
    --image \
    --iters 3 \
    --model gemma-4-E4B-it.litertlm
# Ensure directory exists and download model
mkdir -p ~/litert-lm-bench
curl -L -o ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \
  https://huggingface.co/litert-community/gemma-4-E4B-it-litert-lm/resolve/main/gemma-4-E4B-it-web.litertlm

# Execute benchmark with standard LiteRT-LM flags
litert-lm benchmark ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \
  --backend=gpu \
  -p 1024 \
  -d 256 \
  --runs 2

Results: VL (vision) path

The benchmark sub-command only benches the text path. To time the vision encoder, drive the same engine via the Python API (vl_bench.py in this directory) — it loads the model, streams a real image (test_multi.jpg, httpbin.org/image/jpeg) + text through vision_backend=cpu|gpu and prints TTFT (vision encode + prefill + first token), per-chunk decode rate, and the reply. One sentence prompt, 13-token answer, ~290-token total prefill (280 vision + text), generations deterministic (temperature=0). Medians over 3+ runs after compile:

Combo (text / vision) VL TTFT (s) Decode (tok/s) Reply matches CPU?
cpu / cpu 8.93–9.40 17.4 baseline
cpu / gpu (patched panvk) 6.16–6.62 17.2 yes, identical
gpu / gpu (patched panvk) 5.62–6.16 9.8 yes, identical

Text-only controls (7-token prompt): CPU TTFT ≈ 0.8 s, GPU TTFT ≈ 0.57 s.

Isolating the vision cost (VL TTFT − text-only TTFT for the same text backend): ~8.1 s on a CPU vision encoder vs ~5.4 s GPU — the Mali GPU cuts vision-encoder latency by ~2.7–3 s per image (~30%), and the full-GPU combo is ~37% faster end-to-end (5.6 vs 8.9 s). The patched panvk covers the model's separate VISION_ENCODER subgraph too (no extra Dawn limits tripped).

Caveat: for short generations (< ~20 tokens) GPU decode is slower than CPU (9.8 vs 17.4 tok/s) — per-iteration GPU sync overhead — so for chatty/VL replies the CPU text lane with GPU vision is often the best mix (6.2 s TTFT, CPU-fast decode).

Benchmarking the VL path yourself

# 1. FETCH SAMPLE TEST IMAGE
  curl -sL -o ~/litert-lm-bench/test_multi.jpg https://httpbin.org/image/jpeg

  # 2. SET PYTHON INTERPRETER PATH
  VL_PY=~/.local/share/uv/tools/litert-lm/bin/python

  # 3. BASELINE: TEXT (CPU) + VISION (CPU)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision cpu --image --iters 3

  # 4. HYBRID: TEXT (CPU) + VISION (GPU) — EXPORT PANVK MESA ENVS FIRST
  export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk
  export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json"
  export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171"

  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision gpu --image --iters 3

  # 5. FULL ACCELERATION: TEXT (GPU) + VISION (GPU)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --vision gpu --image --iters 3

  # 6. TEXT-ONLY CONTROLS (ISOLATE VISION-ENCODER COST)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --iters 3
  $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --iters 3

Prints per-iteration TTFT / decode tok/s / reply. Run cases sequentially — parallel GPU runs contend for the Mali GPU and inflate the numbers (observed 2× TTFT when two ran at once).

6. Inference

# 1. DIRECT CLI EVALUATION 
  litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
    --cache disk --prompt "What is the capital of France?"

  # 2. INTERACTIVE REPL MODE
  litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm

  # 3. OPENAI-COMPATIBLE API SERVER
  litert-lm serve ~/litert-lm-bench/gemma-4-E2B-it.litertlm

Vision (and audio) input uses run with attachments — one per --attachment, placed before the first user text (images and audio can be mixed):

litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  --attachment ~/litert-lm-bench/test_multi.jpg \
  --prompt "What is in this image? Answer in one sentence." \
  --vision-backend cpu          
  # or gpu (patched panvk, §5) — ~2.7–3 s faster vision encode

--vision-backend/--audio-backend pick the encoder lane independently of --backend (which chooses the LLM lane). Like --backend gpu, --vision-backend gpu needs the §5 env (VK_ICD_FILENAMES + LD_LIBRARY_PATH) exported for that run.

Notes:

--cache disk persists compiled artifacts next to the model — the first GPU load compiles shaders, later loads start instantly. The load time is NOT paid on every run. Observed caches: <model>_*_mldrift_program_cache.bin (compiled kernels) and<model>_*_mldrift_weight_cache.bin (GPU-rearranged weights, ~0.8 GB). The vision encoder's kernels live in the same cache files — first GPU --vision-backend gpu run compiles, later
runs reuse.

GPU (patched panvk) is ~2.8× faster at prefill and ~2.7× on TTFT, but ~30% slower at decode — pick the lane by workload (§7.4).

Vision: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s per image; CPU text + GPU vision is the best blend for short/chatty replies (§5 VL results).

Speculative decoding (--speculative-decoding true) can lift decode on CPU+GPU for rewrite/summarize/coding style prompts (Gemma 4 E2B supports it).

7. GPU deep dive: the blocker and how it was unblocked here

Everything below was reproduced with LiteRT-LM v0.17.1 (CLI + litert-lm-api), Mesa 26.1.2 (trixie-backports), kernel 7.2.4-edge-rockchip64 (mainline panthor).

7.1 The panvk limit blocker — RESOLVED with a one-line local patch

LiteRT's WebGPU accelerator uses Dawn, which enforces the WebGPU spec minimums against the Vulkan driver and refuses to proceed when they are unmet. Stock panvk reports:

maxImageDimension3D = 512      # WebGPU spec requires ≥ 2048

Dawn logs exactly this (PhysicalDeviceVk.cpp:794: "Insufficient Vulkan limits for maxTextureDimension3D ... must be at least 2048"), and stock panvk then dies with a null-pointer dispatch (SIGSEGV, pc=0x0) inside the WebGPU path on the first real GPU execution. The root cause is the driver limit, not packaging: the crash is identical even with the WebGPU prebuilts (libLiteRtTopKWebGpuSampler.so + friends) fetched from the litert-lm repo prebuilt/linux_arm64 @ v0.17.1 on LD_LIBRARY_PATH.

The fix (validated on this board): panvk caps 3D textures at 512 for Valhall
(PAN_ARCH <= 10), but the Mali-G610 hardware handles 2048³ — raising the advertised limit to 2048 makes Dawn accept the adapter:

-.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),
+.maxImageDimension3D = (1 << 11),       /* 2048 — meets WebGPU min (was 512 on arch <= 10) */

Why it's safe: Dawn only validates the advertised limit against its spec minimum, and the value also caps future image allocations — so if a kernel ever genuinely requested a 2048³ 3D texture, panvk would fail cleanly at allocation instead of corrupting anything. LiteRT/ML-Drift's LLM and vision-encoder kernels allocate buffers and 2D textures only, so real GPU behaviour is unchanged; Dawn simply stops rejecting the adapter, the SIGSEGV disappears, and the full benchmark runs (§5). Confirmed via vulkaninfo on the patched build: maxImageDimension3D = 2048. All other WebGPU minimums (per-stage descriptors, workgroup sizes, buffer ranges) were already comfortably met.

The build is process-scoped (VK_ICD_FILENAMES + LD_LIBRARY_PATH per run), the system Mesa is never touched, and reverting is unsetting two variables. Unless/until Mesa raises this limit upstream for Valhall, keep this build around for LiteRT-LM GPU runs.

7.2 The vendor route (Rockchip libmali) — needs a different kernel

Rockchip's proprietary blob would satisfy Dawn (it exposes Vulkan 1.3 with full limits), but the blob's userspace talks to Rockchip's proprietary kbase kernel driver (/dev/mali) and cannot attach to the mainline panthor driver:

"libmali-valhall-g610-g13p0-gbm"      → loads, exports NO Vulkan ICD (0 vk_* symbols)
"libmali-valhall-g610-g24p0-gbm"
  libMaliVulkan.so.1 (api 1.3.276)    → loads, "No mali devices found" then SIGSEGV (no /dev/mali)

Installable packages exist (tsukumijima/libmali-rockchip releases, e.g.
v1.9-1-20260312-bd33ee2), but they all presume the vendor kernel.

Unblock: flash a vendor-kernel image (kernel with kbase/mali.ko, e.g. Armbian images with the Rockchip BSP kernel), then install
libmali-valhall-g610-g13p0-gbm (or g24p0) and point Dawn/Vulkan at it
(VK_DRIVER_FILES/LD_LIBRARY_PATH). That same blob also provides OpenCL 3.0 (libMaliOpenCL.so + /etc/OpenCL/vendors/mali.icd), which would additionally satisfy the "would OpenCL be faster?" curiosity — for running LLMs, both WebGPU/Vulkan and OpenCL on the same GPU land in the same class of throughput; the win is the mature compiler's fast startup, not raw speed.

7.3 OpenCL on the current kernel — not available

Mesa's rusticl on panthor currently exposes zero devices (clinfo -l shows only the rusticl platform, no device). So there is no OpenCL device at all on the mainline stack, and LiteRT-LM has no Linux OpenCL accelerator anyway.

7.4 Practical advice for this board today

  • Chat / streaming (decode-bound): CPU is the better lane — 12.3 vs 8.7 tk/s decode.
  • Long prompts / RAG / document Q&A (prefill-bound): GPU pays off — 345 vs 124 tk/s prefill,
    3.1 vs 8.4 s TTFT.

Images / VL: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s (~30%). Shortest VL TTFT is text+vision both on GPU (5.6 vs 8.9 s all-CPU), but keep the LLM on CPU when replies are short and chatty (6.2 s TTFT plus CPU-fast decode).

  • --speculative-decoding true can lift decode further on both lanes (Gemma 4 E2B supports it).

Serving an OpenAI-compatible endpoint (litert-lm serve)

litert-lm serve exposes an OpenAI API on 0.0.0.0:9379, so LAN clients (LiteCode, opencode, aider, Continue, scripts) use the board like any OpenAI endpoint. Import a model once (litert-lm import ./gemma-4-E2B-it.litertlm, registry at ~/.litert-lm/models/), then litert-lm serve. Per-model settings come from ~/.litert-lm/config.json (default + models.<id>), so clients stay plain-OpenAI:

{
  "default": { "backend": "cpu", "cpu_thread_count": 8, "cache": "disk" },
  "models": { "gemma-4-E2B-it.litertlm": { "speculative_decoding": true, "max_num_tokens": 4096 } }
}

Endpoints: GET /v1/models and POST /v1/chat/completions (streaming + non-streaming). OpenAI tools / tool_choice are bridged to the model's function-calling template — verified to return valid tool_calls JSON (non-streaming and streamed) and to complete the full agent cycle (assistant tool_call → tool result → final answer). /v1/embeddings exists but is not tied to LLM models.

Even though litert-lm describe reports Supports Function Call: NO for Gemma 4, the serve layer still bridges tools into the model template (empirically verified); that flag only means the CLI's interactive run has no native FC template.

RAM budget (E2B, CPU): max_num_tokens preallocates KV/ringbuffer arenas up front.Measured process RSS: 4096 → ~3.1 GB (4.9 GB free — recommended), 8192 → ~7 GB (1.1 GB free — works but leaves no headroom). Keep 4096 and let clients budget. Config keys (0.15+): backend, vision_backend, audio_backend, cpu_thread_count, cache,
max_num_tokens, speculative_decoding, thinking, thinking_budget,
gpu_decode_steps_per_sync, sampling. CLI flags override config. For a persistent border, run under systemd.

Verified client on this board

LiteCode (razvanneculai/litecode) — works end-to-end. Its Planner
({"synthesis","tasks"} strict JSON) and Executor (raw file content, no fences) prompts fit the 4096 budget; single-request task runs completed correctly and files linter-clean.
litecode.json:

{
  "provider": { "baseURL": "http://<yourIP>:9379/v1", "apiKey": "", "model": "gemma-4-E2B-it.litertlm" },
  "tokenLimit": 4096, "reservedOutputTokens": 1500, "systemPromptBudget": 1000, "maxParallelExecutors": 1
}

Troubleshooting

FATAL ERROR: This binary was compiled with dotprod enabled... → CPU lacks FEAT_DotProd, not supported by the ARM64 prebuilt wheels. RK3588 has it.

GPU benchmark errors but CPU works → with stock Mesa this is the §7.1 Dawn limit crash (maxImageDimension3D = 512); with the patched build, check vulkaninfo --summary again — panvk must list the Mali device and report maxImageDimension3D = 2048. ExportVK_ICD_FILENAMES+LD_LIBRARY_PATH for every run that should use the patched driver.

Could not load shared library libLiteRtTopKWebGpuSampler.so → the CLI wheel does not bundle the WebGPU samplers; fetch them from the litert-lm repo prebuilt/linux_arm64/ at the matching version tag (e.g. v0.17.1) and export their directory on LD_LIBRARY_PATH.

First GPU run is slow (one-time kernel compilation) — normal; use --cache disk so later loads skip it. Caches persist next to the model.

Bigger models (e.g. stock gemma-4-E4B-it.litertlm, 3.66 GB) fail on the GPU even with the patched driver: panthor ... job timeout in dmesg (fixed 1 s driver watchdog, not tunable; the model has a one-shot dispatch that exceeds it even at the real 1 GHz boost) theVK_ERROR_DEVICE_LOST, and/or a global OOM-kill (EXIT=137) when pinned GPU buffers + the model outgrow 8 GB. E2B fits, E4B-stock doesn't. Use the text-only -web flavor (gemma-4-E4B-it-web.litertlm, 2.97 GB) for E4B-on-GPU — its finer kernels stay under the watchdog and its GPU set peaks ~4.3 GB (§5 E4B section).

Join the conversation on the Armbian Forum and let us know how it runs on your hardware!

View the full article

]]>62337Wed, 30 Sep 2026 15:24:54 +0000[Armbian newsletter] - Mali GPU with LiteRT-LMhttps://testforum.armbian.com/topic/62335-armbian-newsletter-mali-gpu-with-litert-lm/Running Gemma 4 E2B on a Mali GPU with LiteRT-LMMali GPU with LiteRT-LM

This guide should work on any armbian minimal/console (trixie) system with a working Mali-g610 GPU.

DO NOT USE DESKTOP

Verified on: Orange Pi 5 Max (Rockchip RK3588, Arm Mali-G610 MC4), Armbian/Debian 13 (trixie), aarch64, 8 GB RAM.

Status summary: Both CPU (XNNPACK) and GPU (WebGPU/Dawn → Vulkan → panvk → panthor) work on the mainline panthor kernel — numbers below. The GPU path needed one line of local patching in
Mesa's panvk driver (raise maxImageDimension3D 512 → 2048 to meet the WebGPU minimums that LiteRT's Dawn library enforces; recipe in §5, rationale in §7.1). The model is multimodal (Text + Vision + Audio): the vision encoder runs on the same patched panvk via--vision-backend gpu (§5 "VL path" results). The vendor Rockchip libmali route and OpenCL remain unavailable on mainline panthor (§7.2, §7.3).

Stack (as shipped):

Gemma 4 E2B (.litertlm, int4)  →  LiteRT-LM CLI  →  LiteRT GPU accelerator (WebGPU/ML Drift)

Dawn (WebGPU impl) → Vulkan → panvk → panthor (kernel) → Mali-G610

1. Prerequisites

  • ARM (aarch64) Linux with a Mali GPU and at least 8 GB RAM.
  • Armbian/Debian 13 (trixie)
  • The panthor (or panfrost for older Mali) kernel driver active:
ls /dev/dri/renderD128          # render node must exist
lsmod | grep panthor            # or panfrost / lima

Full ARMv8.2-A dotprod support is required — LiteRT's ARM64 binaries are built with it and will SIGILL otherwise:lscpu | grep -w asimddp (both A55 and A76 cores list it here).

2. Install Mesa + Vulkan for Mali (needs root)

sudo apt update
# Prefer the newest Mesa (backports on Debian) for the best panvk coverage of Valhall CSF GPUs:
sudo apt install -y -t trixie-backports mesa-vulkan-drivers libvulkan1 vulkan-tools
# Optional (see §7 — currently yields NO usable OpenCL device on panthor):
sudo apt install -y -t trixie-backports mesa-opencl-icd clinfo

Verify the GPU is visible to Vulkan:

vulkaninfo --summary | grep -iE "deviceName|driverName"
# Expect: deviceName = Mali-G610 MC4   driverName = panvk

3. Install the LiteRT-LM CLI (user space, no root)

curl -LsSf https://astral.sh/uv/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
uv tool install litert-lm        # current: v0.17.x; incl. CPU (XNNPACK/YNNPACK) + GPU (WebGPU/Vulkan) backends

4. Get the model (Gemma 4 E2B, int4 .litertlm, 2.58 GB)

mkdir -p ~/litert-lm-bench && cd ~/litert-lm-bench
curl -L -o gemma-4-E2B-it.litertlm \
  https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm
# or have the CLI fetch it for you:
#   litert-lm benchmark --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm gemma-4-E2B-it.litertlm

Other ready models: google/gemma-3n-E2B-it-litert-lm (gemma-3n-E2B-it-int4.litertlm),litert-community/gemma-4-E4B-it-litert-lm, ... (see litert-lm list / HF).

5. Benchmark

Lock the CPU governor to performance first (fair, repeatable numbers):

sudo sh -c 'for c in /sys/devices/system/cpu/cpu[0-7]/cpufreq/scaling_governor; do echo performance > $c; done'

CPU baseline (XNNPACK, 8 threads):

litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  -p 1024 -d 256 --backend cpu --cpu-thread-count 8 --cache disk --runs 2

GPU (patched panvk, §7.1). One-time local Mesa build — stays entirely in userland, the system Mesa is untouched:

# 1) Mesa source + one-line patch (26.1.2)
cd ~/litert-lm-bench
curl -L -o mesa.tar.xz https://archive.mesa3d.org/mesa-26.1.2.tar.xz
tar -xf mesa.tar.xz && cd mesa-26.1.2
python3 - <<'PY'
p = 'src/panfrost/vulkan/panvk_vX_physical_device.c'
s = open(p).read()
s = s.replace('.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),',
              '.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min */')
open(p, 'w').write(s)
PY

# 2) build deps (the LLVM/CLC chain is required — panvk bakes CLC-compiled SPIR-V for libpan)
sudo apt install -y --no-install-recommends meson ninja-build pkg-config gcc g++ python3-mako \
  python3-yaml python3-ply libdrm-dev llvm-19-dev libllvmspirvlib-19-dev spirv-tools \
  libclang-19-dev libclang-cpp19-dev

# 3) panvk-only build (~10–25 min on the 5 Max)
meson setup build-panvk -Dvulkan-drivers=panfrost -Dgallium-drivers= -Dbuildtype=release \
  -Dllvm=enabled -Dmesa-clc=auto -Dplatforms= -Degl=disabled -Dgbm=disabled -Dglx=disabled \
  -Dopengl=false -Dglvnd=disabled -Dtools= -Dbuild-tests=false
ninja -C build-panvk -j6

# 4) benchmark with the patched driver, process-scoped. First put the WebGPU prebuilts
#    (libLiteRtTopKWebGpuSampler.so + libwebgpu_dawn.so etc., litert-lm repo tag v0.17.1,
#    prebuilt/linux_arm64) in ~/litert-lm-bench/prebuilt_v0171/ — see Troubleshooting.
export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk
export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json"
export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171"
export PATH="$HOME/.local/bin:$PATH"            # uv-installed CLI
litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  -p 1024 -d 256 --backend gpu --cache disk --runs 2

First GPU run compiles the WebGPU/Vulkan shaders (one-time) and uploads GPU-rearranged weights (~0.8 GB weight cache); --cache disk persists both next to the model, so later loads start fast — the compile cost is NOT repaid on every run.

Results on this Orange Pi 5 Max (Mali-G610 MC4)

Backend Prefill (tk/s) Decode (tk/s) TTFT (s)
CPU (XNNPACK, 8 threads) 123.6 12.3 8.4
GPU (WebGPU/Dawn→Vulkan, patched panvk §5/§7.1) 374.0 8.7 2.9

Google's on-device-class references for Gemma 4 E2B: S26 Ultra GPU 3808/52 tk/s, Raspberry Pi 5 CPU 133/7.6 tk/s. On this board the GPU wins the prefill race by ~3.0× (374 vs 124 tk/s) and TTFT by ~2.9× (2.9 vs 8.4 s), while decode stays on the CPU's side (8.7 vs 12.3 tk/s) — as expected, decode is the bottleneck on Mali-class hardware; the Mali GPU is a prefill/TTFT accelerator here, not a decode accelerator.

GPU clock note (measured, no guesswork): the Mali-G610 is an integrated GPU sharing the board's DDR. The devfreq governor (simple_ondemand, stock) boosts it to 1 GHz under load and parks it at 200 MHz idle — confirmed by sampling cur_freq at 400 ms during the run (233/263 samples at 1000 MHz, temps 41→56 °C, no thermal trip). Leave the governor alone: forcingperformance/min/max via sysfs was counterproductive (idle readbacks that look like the clock collapsed, and it destabilized perfectly good runs). The numbers above are at the stock governor's real 1 GHz boost.

Results: Gemma 4 E4B (4B) — text GPU via the web flavor, vision GPU straight from stock

E4B (the 4B sibling) ships as three files in the HF repo: the stock gemma-4-E4B-it.litertlm (text+vision+audio, 3.66 GB) plus an -gpu and a -web (text-only, 2.97 GB) variant. On this 8 GB board the stock file cannot run on the GPU — two structural walls, both measured:

panthor job watchdog: a fixed one-shot pipeline dispatch (dmesg: job timeout ... seqno=144, same job on every E4B attempt) exceeds the driver's compiled-in 1 s job timeout even at the real 1 GHz boost (E2B's equivalent is seqno=77 and fits). The GPU is reset, Dawn reports VK_ERROR_DEVICE_LOST, generation aborts.

8 GB RAM ceiling: GPU buffers (pinned, unrescalable shmem) peak near 4–5 GB on top of the 3.66 GB model; every run ended in a global OOM-kill (EXIT=137) during iteration 2 even with a 2048-token KV cap + ringbuffers + disk cache.

The -web flavor dodges both — its finer op layout splits the killer dispatch under the 1 s bar and shrinks the GPU working set (peak 4.3 GB observed, holds 1 GHz the whole run):

Gemma 4 E4B lane Flavor Prefill (tk/s) Decode (tk/s) TTFT (s)
CPU (XNNPACK, 8 threads) stock 52.6 5.58 19.6
GPU (patched panvk) web (text-only) 75.1 4.54 13.9

(reproducible to the decimal across --runs 2; init 6.2 s; note --cache disk does not persist for the web flavor — expect a recompile each run. --speculative-decoding true gave no gain:4.37 vs 4.54 tok/s decode (this build ships no draft model).) Reference: Raspberry Pi 5 (16 GB, CPU) 51/3.2/20.5 — this board matches or beats it on every column. Same shape as E2B: GPU wins prefill +1.4× and TTFT 19.6→13.9 s, but decode stays CPU-favored (4.5 vs 5.6 tk/s).

E4B vision (VL) on GPU works — cpu text + gpu vision

The stock E4B's vision encoder is a separate 1477-op subgraph that fits under the panthor watchdog and inside 8 GB even though the full stock model's text lane does not. Drive it via the Engine API (this repo's vl_bench.py --model ...), LLM lane = CPU, vision encoder = GPU (patched panvk): the test image (resized to 912×672 → 2394 patches, near E4B's max_num_patches 2520) is encoded on the Mali.

E4B VL (LLM lane = cpu) vision cpu vision gpu (patched panvk)
TTFT (s) 12.3–12.5 9.6
Decode (tok/s) 7.33–7.37 7.28–7.39
Reply (same image) "coyote walking on a dirt path" identical

Text-only CPU control: TTFT ≈ 2.0 s (7-token prompt, decode ~7.8 tok/s). Isolated vision-encode cost: ~10.4 s CPU vs ~7.6 s GPU — the Mali cuts E4B vision latency by ~2.9 s/image (~27%). No watchdog hits, no OOM (peaks well below ceiling; vision weights are a fraction of a GB). Same conclusion as E2B: for vision work keep the LLM on CPU and let the GPU run the encoder.

# 1. SET ENVIRONMENT FOR GPU VISION DELEGATE
  export LITERT_VISION_DELEGATE=gpu

  # 2. RUN VL HARNESS FOR STOCK GEMMA-4-E4B
~/.local/share/uv/tools/litert-lm/bin/python vl_bench.py \
    --text cpu \
    --vision gpu \
    --image \
    --iters 3 \
    --model gemma-4-E4B-it.litertlm
# Ensure directory exists and download model
mkdir -p ~/litert-lm-bench
curl -L -o ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \
  https://huggingface.co/litert-community/gemma-4-E4B-it-litert-lm/resolve/main/gemma-4-E4B-it-web.litertlm

# Execute benchmark with standard LiteRT-LM flags
litert-lm benchmark ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \
  --backend=gpu \
  -p 1024 \
  -d 256 \
  --runs 2

Results: VL (vision) path

The benchmark sub-command only benches the text path. To time the vision encoder, drive the same engine via the Python API (vl_bench.py in this directory) — it loads the model, streams a real image (test_multi.jpg, httpbin.org/image/jpeg) + text through vision_backend=cpu|gpu and prints TTFT (vision encode + prefill + first token), per-chunk decode rate, and the reply. One sentence prompt, 13-token answer, ~290-token total prefill (280 vision + text), generations deterministic (temperature=0). Medians over 3+ runs after compile:

Combo (text / vision) VL TTFT (s) Decode (tok/s) Reply matches CPU?
cpu / cpu 8.93–9.40 17.4 baseline
cpu / gpu (patched panvk) 6.16–6.62 17.2 yes, identical
gpu / gpu (patched panvk) 5.62–6.16 9.8 yes, identical

Text-only controls (7-token prompt): CPU TTFT ≈ 0.8 s, GPU TTFT ≈ 0.57 s.

Isolating the vision cost (VL TTFT − text-only TTFT for the same text backend): ~8.1 s on a CPU vision encoder vs ~5.4 s GPU — the Mali GPU cuts vision-encoder latency by ~2.7–3 s per image (~30%), and the full-GPU combo is ~37% faster end-to-end (5.6 vs 8.9 s). The patched panvk covers the model's separate VISION_ENCODER subgraph too (no extra Dawn limits tripped).

Caveat: for short generations (< ~20 tokens) GPU decode is slower than CPU (9.8 vs 17.4 tok/s) — per-iteration GPU sync overhead — so for chatty/VL replies the CPU text lane with GPU vision is often the best mix (6.2 s TTFT, CPU-fast decode).

Benchmarking the VL path yourself

# 1. FETCH SAMPLE TEST IMAGE
  curl -sL -o ~/litert-lm-bench/test_multi.jpg https://httpbin.org/image/jpeg

  # 2. SET PYTHON INTERPRETER PATH
  VL_PY=~/.local/share/uv/tools/litert-lm/bin/python

  # 3. BASELINE: TEXT (CPU) + VISION (CPU)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision cpu --image --iters 3

  # 4. HYBRID: TEXT (CPU) + VISION (GPU) — EXPORT PANVK MESA ENVS FIRST
  export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk
  export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json"
  export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171"

  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision gpu --image --iters 3

  # 5. FULL ACCELERATION: TEXT (GPU) + VISION (GPU)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --vision gpu --image --iters 3

  # 6. TEXT-ONLY CONTROLS (ISOLATE VISION-ENCODER COST)
  $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --iters 3
  $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --iters 3

Prints per-iteration TTFT / decode tok/s / reply. Run cases sequentially — parallel GPU runs contend for the Mali GPU and inflate the numbers (observed 2× TTFT when two ran at once).

6. Inference

# 1. DIRECT CLI EVALUATION 
  litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
    --cache disk --prompt "What is the capital of France?"

  # 2. INTERACTIVE REPL MODE
  litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm

  # 3. OPENAI-COMPATIBLE API SERVER
  litert-lm serve ~/litert-lm-bench/gemma-4-E2B-it.litertlm

Vision (and audio) input uses run with attachments — one per --attachment, placed before the first user text (images and audio can be mixed):

litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \
  --attachment ~/litert-lm-bench/test_multi.jpg \
  --prompt "What is in this image? Answer in one sentence." \
  --vision-backend cpu          
  # or gpu (patched panvk, §5) — ~2.7–3 s faster vision encode

--vision-backend/--audio-backend pick the encoder lane independently of --backend (which chooses the LLM lane). Like --backend gpu, --vision-backend gpu needs the §5 env (VK_ICD_FILENAMES + LD_LIBRARY_PATH) exported for that run.

Notes:

--cache disk persists compiled artifacts next to the model — the first GPU load compiles shaders, later loads start instantly. The load time is NOT paid on every run. Observed caches: <model>_*_mldrift_program_cache.bin (compiled kernels) and<model>_*_mldrift_weight_cache.bin (GPU-rearranged weights, ~0.8 GB). The vision encoder's kernels live in the same cache files — first GPU --vision-backend gpu run compiles, later
runs reuse.

GPU (patched panvk) is ~2.8× faster at prefill and ~2.7× on TTFT, but ~30% slower at decode — pick the lane by workload (§7.4).

Vision: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s per image; CPU text + GPU vision is the best blend for short/chatty replies (§5 VL results).

Speculative decoding (--speculative-decoding true) can lift decode on CPU+GPU for rewrite/summarize/coding style prompts (Gemma 4 E2B supports it).

7. GPU deep dive: the blocker and how it was unblocked here

Everything below was reproduced with LiteRT-LM v0.17.1 (CLI + litert-lm-api), Mesa 26.1.2 (trixie-backports), kernel 7.2.4-edge-rockchip64 (mainline panthor).

7.1 The panvk limit blocker — RESOLVED with a one-line local patch

LiteRT's WebGPU accelerator uses Dawn, which enforces the WebGPU spec minimums against the Vulkan driver and refuses to proceed when they are unmet. Stock panvk reports:

maxImageDimension3D = 512      # WebGPU spec requires ≥ 2048

Dawn logs exactly this (PhysicalDeviceVk.cpp:794: "Insufficient Vulkan limits for maxTextureDimension3D ... must be at least 2048"), and stock panvk then dies with a null-pointer dispatch (SIGSEGV, pc=0x0) inside the WebGPU path on the first real GPU execution. The root cause is the driver limit, not packaging: the crash is identical even with the WebGPU prebuilts (libLiteRtTopKWebGpuSampler.so + friends) fetched from the litert-lm repo prebuilt/linux_arm64 @ v0.17.1 on LD_LIBRARY_PATH.

The fix (validated on this board): panvk caps 3D textures at 512 for Valhall
(PAN_ARCH <= 10), but the Mali-G610 hardware handles 2048³ — raising the advertised limit to 2048 makes Dawn accept the adapter:

-.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),
+.maxImageDimension3D = (1 << 11),       /* 2048 — meets WebGPU min (was 512 on arch <= 10) */

Why it's safe: Dawn only validates the advertised limit against its spec minimum, and the value also caps future image allocations — so if a kernel ever genuinely requested a 2048³ 3D texture, panvk would fail cleanly at allocation instead of corrupting anything. LiteRT/ML-Drift's LLM and vision-encoder kernels allocate buffers and 2D textures only, so real GPU behaviour is unchanged; Dawn simply stops rejecting the adapter, the SIGSEGV disappears, and the full benchmark runs (§5). Confirmed via vulkaninfo on the patched build: maxImageDimension3D = 2048. All other WebGPU minimums (per-stage descriptors, workgroup sizes, buffer ranges) were already comfortably met.

The build is process-scoped (VK_ICD_FILENAMES + LD_LIBRARY_PATH per run), the system Mesa is never touched, and reverting is unsetting two variables. Unless/until Mesa raises this limit upstream for Valhall, keep this build around for LiteRT-LM GPU runs.

7.2 The vendor route (Rockchip libmali) — needs a different kernel

Rockchip's proprietary blob would satisfy Dawn (it exposes Vulkan 1.3 with full limits), but the blob's userspace talks to Rockchip's proprietary kbase kernel driver (/dev/mali) and cannot attach to the mainline panthor driver:

"libmali-valhall-g610-g13p0-gbm"      → loads, exports NO Vulkan ICD (0 vk_* symbols)
"libmali-valhall-g610-g24p0-gbm"
  libMaliVulkan.so.1 (api 1.3.276)    → loads, "No mali devices found" then SIGSEGV (no /dev/mali)

Installable packages exist (tsukumijima/libmali-rockchip releases, e.g.
v1.9-1-20260312-bd33ee2), but they all presume the vendor kernel.

Unblock: flash a vendor-kernel image (kernel with kbase/mali.ko, e.g. Armbian images with the Rockchip BSP kernel), then install
libmali-valhall-g610-g13p0-gbm (or g24p0) and point Dawn/Vulkan at it
(VK_DRIVER_FILES/LD_LIBRARY_PATH). That same blob also provides OpenCL 3.0 (libMaliOpenCL.so + /etc/OpenCL/vendors/mali.icd), which would additionally satisfy the "would OpenCL be faster?" curiosity — for running LLMs, both WebGPU/Vulkan and OpenCL on the same GPU land in the same class of throughput; the win is the mature compiler's fast startup, not raw speed.

7.3 OpenCL on the current kernel — not available

Mesa's rusticl on panthor currently exposes zero devices (clinfo -l shows only the rusticl platform, no device). So there is no OpenCL device at all on the mainline stack, and LiteRT-LM has no Linux OpenCL accelerator anyway.

7.4 Practical advice for this board today

  • Chat / streaming (decode-bound): CPU is the better lane — 12.3 vs 8.7 tk/s decode.
  • Long prompts / RAG / document Q&A (prefill-bound): GPU pays off — 345 vs 124 tk/s prefill,
    3.1 vs 8.4 s TTFT.

Images / VL: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s (~30%). Shortest VL TTFT is text+vision both on GPU (5.6 vs 8.9 s all-CPU), but keep the LLM on CPU when replies are short and chatty (6.2 s TTFT plus CPU-fast decode).

  • --speculative-decoding true can lift decode further on both lanes (Gemma 4 E2B supports it).

Serving an OpenAI-compatible endpoint (litert-lm serve)

litert-lm serve exposes an OpenAI API on 0.0.0.0:9379, so LAN clients (LiteCode, opencode, aider, Continue, scripts) use the board like any OpenAI endpoint. Import a model once (litert-lm import ./gemma-4-E2B-it.litertlm, registry at ~/.litert-lm/models/), then litert-lm serve. Per-model settings come from ~/.litert-lm/config.json (default + models.<id>), so clients stay plain-OpenAI:

{
  "default": { "backend": "cpu", "cpu_thread_count": 8, "cache": "disk" },
  "models": { "gemma-4-E2B-it.litertlm": { "speculative_decoding": true, "max_num_tokens": 4096 } }
}

Endpoints: GET /v1/models and POST /v1/chat/completions (streaming + non-streaming). OpenAI tools / tool_choice are bridged to the model's function-calling template — verified to return valid tool_calls JSON (non-streaming and streamed) and to complete the full agent cycle (assistant tool_call → tool result → final answer). /v1/embeddings exists but is not tied to LLM models.

Even though litert-lm describe reports Supports Function Call: NO for Gemma 4, the serve layer still bridges tools into the model template (empirically verified); that flag only means the CLI's interactive run has no native FC template.

RAM budget (E2B, CPU): max_num_tokens preallocates KV/ringbuffer arenas up front.Measured process RSS: 4096 → ~3.1 GB (4.9 GB free — recommended), 8192 → ~7 GB (1.1 GB free — works but leaves no headroom). Keep 4096 and let clients budget. Config keys (0.15+): backend, vision_backend, audio_backend, cpu_thread_count, cache,
max_num_tokens, speculative_decoding, thinking, thinking_budget,
gpu_decode_steps_per_sync, sampling. CLI flags override config. For a persistent border, run under systemd.

Verified client on this board

LiteCode (razvanneculai/litecode) — works end-to-end. Its Planner
({"synthesis","tasks"} strict JSON) and Executor (raw file content, no fences) prompts fit the 4096 budget; single-request task runs completed correctly and files linter-clean.
litecode.json:

{
  "provider": { "baseURL": "http://<yourIP>:9379/v1", "apiKey": "", "model": "gemma-4-E2B-it.litertlm" },
  "tokenLimit": 4096, "reservedOutputTokens": 1500, "systemPromptBudget": 1000, "maxParallelExecutors": 1
}

Troubleshooting

FATAL ERROR: This binary was compiled with dotprod enabled... → CPU lacks FEAT_DotProd, not supported by the ARM64 prebuilt wheels. RK3588 has it.

GPU benchmark errors but CPU works → with stock Mesa this is the §7.1 Dawn limit crash (maxImageDimension3D = 512); with the patched build, check vulkaninfo --summary again — panvk must list the Mali device and report maxImageDimension3D = 2048. ExportVK_ICD_FILENAMES+LD_LIBRARY_PATH for every run that should use the patched driver.

Could not load shared library libLiteRtTopKWebGpuSampler.so → the CLI wheel does not bundle the WebGPU samplers; fetch them from the litert-lm repo prebuilt/linux_arm64/ at the matching version tag (e.g. v0.17.1) and export their directory on LD_LIBRARY_PATH.

First GPU run is slow (one-time kernel compilation) — normal; use --cache disk so later loads skip it. Caches persist next to the model.

Bigger models (e.g. stock gemma-4-E4B-it.litertlm, 3.66 GB) fail on the GPU even with the patched driver: panthor ... job timeout in dmesg (fixed 1 s driver watchdog, not tunable; the model has a one-shot dispatch that exceeds it even at the real 1 GHz boost) theVK_ERROR_DEVICE_LOST, and/or a global OOM-kill (EXIT=137) when pinned GPU buffers + the model outgrow 8 GB. E2B fits, E4B-stock doesn't. Use the text-only -web flavor (gemma-4-E4B-it-web.litertlm, 2.97 GB) for E4B-on-GPU — its finer kernels stay under the watchdog and its GPU set peaks ~4.3 GB (§5 E4B section).

Join the conversation on the Armbian Forum and let us know how it runs on your hardware!

View the full article

]]>62335Wed, 30 Sep 2026 15:24:54 +0000[CNX-Software] - OpenArm 2.0 – An open-source 7-DOF robot arm with QDD joints, bilateral force feedback, in-hand camera https://testforum.armbian.com/topic/62453-cnx-software-openarm-20-an-open-source-7-dof-robot-arm-with-qdd-joints-bilateral-force-feedback-in-hand-camera%C2%A0/OpenArm 2.0 arms installed inside the OpenArm Cell for standardized evaluation

Tokyo-based Enactic OpenArm 2.0 is an open-source hardware 7-DOF robot arm designed for physical AI research, teleoperation, and contact-rich data collection. It uses quasi-direct-drive (QDD) backdrivable joints to support compliant motion and bilateral force-feedback control. The arm supports 4.1 kg nominal and 6 kg peak payload, features 1 kHz CAN-FD control, and a compact parallel gripper with an in-hand camera and replaceable fingers. It supports bilateral force-feedback teleoperation, gravity compensation, and compliant interaction, with an aluminum and stainless-steel structure and MISUMI-frame base. The ecosystem also includes the OpenArm Cell for standardized evaluation and OpenArm KER, a motorless replica for teleoperation and data collection. Open-source CAD, BOM, firmware, control software, ROS 2, MuJoCo, Isaac Lab, and dataset tools support applications such as imitation learning, reinforcement learning, sim-to-real, and robotic manipulation. OpenArm 2.0 specifications: Communication CAN-FD (recommended): nominal 1 Mbps, data 5 Mbps, control loop 1 kHz Classic CAN 2.0 fallback @ [...]

The post OpenArm 2.0 – An open-source 7-DOF robot arm with QDD joints, bilateral force feedback, in-hand camera  appeared first on CNX Software - Embedded Systems News.

View the full article

]]>62453Wed, 30 Sep 2026 09:00:23 +0000[Collabora] - AMD Embedded Computing Summit 2026 in Frankfurthttps://testforum.armbian.com/topic/62317-collabora-amd-embedded-computing-summit-2026-in-frankfurt/View the full article

]]>62317Tue, 29 Sep 2026 20:39:18 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62300-news-from-armbian-github-highlights/

This week's work centers on Rockchip platform maturation, kernel and toolchain modernization, and board-level enablement across vendors.

Rockchip received the largest share of attention, with RK3528 gaining a thermal driver, cooling-map refinements, and cleanup of legacy PCIe and pmdomain workarounds. The Radxa E24C now stores its U-Boot environment in SPI flash and reads switch port MAC addresses from EEPROM, while device trees for the Mixtile Blade 3, Core3588E, and Edge 2 were corrected. New board support was added for the Boardcon SBC3568, and the Rock 5T now ships an edge kernel. On the configuration side, hyphenated LINUXFAMILY handling was fixed in both the kernel selector and firmware remap logic for the rk35xx family.

Kernel and build infrastructure saw significant modernization. Mainline advanced to 7.3-rc5, several C23 build errors were resolved for D1 ATF, OpenSBI, and libbpf, and the default FRAME_WARN was restored on 64-bit configs. Deprecated patch directories for imx6 and the RK BSP 5.10 legacy kernel were retired, parallel patch queueing was optimized, and kernel-debs postinst ordering was hardened for DKMS safety. CI switched to remote ccache only, and ATF builds now honor USE_CCACHE correctly.

Board-level enablement spanned multiple vendors. ODROID-HC4 gained PCIe suspend, Wake-on-LAN, and RTC alarm support, along with a usable SPI NOR and SD card power-down. ODROID-XU4 was bumped from 6.15 to 7.2 on edge, the Amlogic C400 Plus received SD-boot and Wi-Fi profile fixes, and the Raspberry Pi 4B added support for Waveshare and Raspberry touchscreen v2 panels. The MorseMicro DKMS project also matured substantially with split MM6108/MM8108 packages, Linux 7.1 API compatibility, and initial NetworkManager udev integration.

#Armbian #EmbeddedLinux #Rockchip #Kernel #SBC

Changes

View the full article

]]>62300Mon, 28 Sep 2026 14:26:40 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62299-armbian-newsletter-github-highlights/

This week's work centers on Rockchip platform maturation, kernel and toolchain modernization, and board-level enablement across vendors.

Rockchip received the largest share of attention, with RK3528 gaining a thermal driver, cooling-map refinements, and cleanup of legacy PCIe and pmdomain workarounds. The Radxa E24C now stores its U-Boot environment in SPI flash and reads switch port MAC addresses from EEPROM, while device trees for the Mixtile Blade 3, Core3588E, and Edge 2 were corrected. New board support was added for the Boardcon SBC3568, and the Rock 5T now ships an edge kernel. On the configuration side, hyphenated LINUXFAMILY handling was fixed in both the kernel selector and firmware remap logic for the rk35xx family.

Kernel and build infrastructure saw significant modernization. Mainline advanced to 7.3-rc5, several C23 build errors were resolved for D1 ATF, OpenSBI, and libbpf, and the default FRAME_WARN was restored on 64-bit configs. Deprecated patch directories for imx6 and the RK BSP 5.10 legacy kernel were retired, parallel patch queueing was optimized, and kernel-debs postinst ordering was hardened for DKMS safety. CI switched to remote ccache only, and ATF builds now honor USE_CCACHE correctly.

Board-level enablement spanned multiple vendors. ODROID-HC4 gained PCIe suspend, Wake-on-LAN, and RTC alarm support, along with a usable SPI NOR and SD card power-down. ODROID-XU4 was bumped from 6.15 to 7.2 on edge, the Amlogic C400 Plus received SD-boot and Wi-Fi profile fixes, and the Raspberry Pi 4B added support for Waveshare and Raspberry touchscreen v2 panels. The MorseMicro DKMS project also matured substantially with split MM6108/MM8108 packages, Linux 7.1 API compatibility, and initial NetworkManager udev integration.

#Armbian #EmbeddedLinux #Rockchip #Kernel #SBC

Changes

View the full article

]]>62299Mon, 28 Sep 2026 14:26:40 +0000[Collabora] - Panfrost, Kraid, Tyr, and more at XDC 2026https://testforum.armbian.com/topic/62222-collabora-panfrost-kraid-tyr-and-more-at-xdc-2026/GPU drivers.

View the full article

]]>62222Wed, 23 Sep 2026 16:36:43 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62198-news-from-armbian-github-highlights/

This cycle centers on expanded board and SoC support, kernel maintenance across sunxi, rockchip, and sophgo families, and infrastructure refinements to installer, extensions, and CI tooling.

New platform enablement covers a broad range of vendors and architectures. Notable additions include the EmbedFire LubanCat 3 v2 and Seeed reComputer RK3576 devkits, the TQ-Systems MBa62xx/MBa67xx TI K3 boards, the Tanix TX6s (Allwinner H616), and the ZTL A568 (RK3568). The Allwinner A733 line advances with a full HDMI display pipeline (DE33/RCQ), PCIe/NVMe, and U-Boot 2026.07 integration for sun55iw3, while the Sophgo SG200x family bumps edge to 7.2, gains TPU support for the Milk-V Duo S, and doubles the /boot partition to 256 MB.

Kernel work spans multiple maintenance streams. The sunxi 6.18 and 7.2 patch sets were rewritten against upstream changes, with fixes for a sun8i_thermal NULL-caldata Oops that also resolves a reboot hang, and a correction for H616/H618 analog LINEOUT playing at half speed. Rockchip receives an RK3588 SDMMC fix for bus-width > 1, plymouth and ttyGS0 gadget console improvements on RK35xx, and Radxa E24C network fixes. Amlogic meson64 gains GPIO wakeup sources, PCIe port service requirements, and a rebased MPS series, while the cix-6.18 sky1 PDC driver was converted to the new syscore API.

Tooling and distribution changes improve reliability and lifecycle handling. A new backward-compatible switch-alias mechanism formalizes deprecation, armbian-install gains an "spi" mode for self-contained boot on NVMe, SATA, or USB, and armbian_firmware now installs linux-headers before linux-image to satisfy first-pass DKMS. GitHub release lookups are checked and authenticated with GITHUB_TOKEN propagated through CI, kernel-deb postinst symlinks are made resilient to hook failures, and download-external mirrors only the newest version of each package to reduce archive bloat.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #KernelDevelopment

Changes

View the full article

]]>62198Tue, 22 Sep 2026 01:46:38 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62197-armbian-newsletter-github-highlights/

This cycle centers on expanded board and SoC support, kernel maintenance across sunxi, rockchip, and sophgo families, and infrastructure refinements to installer, extensions, and CI tooling.

New platform enablement covers a broad range of vendors and architectures. Notable additions include the EmbedFire LubanCat 3 v2 and Seeed reComputer RK3576 devkits, the TQ-Systems MBa62xx/MBa67xx TI K3 boards, the Tanix TX6s (Allwinner H616), and the ZTL A568 (RK3568). The Allwinner A733 line advances with a full HDMI display pipeline (DE33/RCQ), PCIe/NVMe, and U-Boot 2026.07 integration for sun55iw3, while the Sophgo SG200x family bumps edge to 7.2, gains TPU support for the Milk-V Duo S, and doubles the /boot partition to 256 MB.

Kernel work spans multiple maintenance streams. The sunxi 6.18 and 7.2 patch sets were rewritten against upstream changes, with fixes for a sun8i_thermal NULL-caldata Oops that also resolves a reboot hang, and a correction for H616/H618 analog LINEOUT playing at half speed. Rockchip receives an RK3588 SDMMC fix for bus-width > 1, plymouth and ttyGS0 gadget console improvements on RK35xx, and Radxa E24C network fixes. Amlogic meson64 gains GPIO wakeup sources, PCIe port service requirements, and a rebased MPS series, while the cix-6.18 sky1 PDC driver was converted to the new syscore API.

Tooling and distribution changes improve reliability and lifecycle handling. A new backward-compatible switch-alias mechanism formalizes deprecation, armbian-install gains an "spi" mode for self-contained boot on NVMe, SATA, or USB, and armbian_firmware now installs linux-headers before linux-image to satisfy first-pass DKMS. GitHub release lookups are checked and authenticated with GITHUB_TOKEN propagated through CI, kernel-deb postinst symlinks are made resilient to hook failures, and download-external mirrors only the newest version of each package to reduce archive bloat.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #KernelDevelopment

Changes

View the full article

]]>62197Tue, 22 Sep 2026 01:46:38 +0000[Collabora] - Decoding with Rockchip at Kernel Recipes 2026https://testforum.armbian.com/topic/62153-collabora-decoding-with-rockchip-at-kernel-recipes-2026/View the full article

]]>62153Thu, 17 Sep 2026 17:30:07 +0000[Collabora] - Enabling responsive AI at SIDO 2026https://testforum.armbian.com/topic/62123-collabora-enabling-responsive-ai-at-sido-2026/View the full article

]]>62123Tue, 15 Sep 2026 18:36:17 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62109-news-from-armbian-github-highlights/

This week's work centers on new board and SoC enablement, a broad wireless driver and firmware overhaul, and continued kernel, boot, and installer refinements.

Board support expanded on multiple fronts. A new RK3562 family was introduced alongside the KICKPI K3B with mainline U-Boot and Linux, and mainline 7.2 bring-up landed for the S5P6818 platform covering NanoPC-T3+, NanoPi M3, and Fire3. The FriendlyELEC NanoPi R28S, Wildfire Lubancat 3 v2, OrangePi CM5 Base edition, and SpacemiT Musebook (current branch) were added, while the Mixtile Edge2 and Blade 3, Orange Pi 5 Max/Ultra, and Banana Pi M2 Ultra received targeted fixes for Bluetooth, eMMC, Ethernet, and thermal behavior.

Wireless support saw substantial cleanup and expansion. The rtl8723ds driver underwent an extensive warning-elimination pass — addressing -Wmissing-prototypes, -Wempty-body, -Wmaybe-uninitialized, -Wrestrict, and -Warray-bounds findings — with parallel improvements to rtl8189es/fs, rtl8192eu, rtl8852bs, and uwe5622. Firmware additions include MT7986 Wi-Fi and Airoha EN8811H blobs, AIC8800 D80 SDIO names, and AP6212 NVRAM for S5P6818 boards, complemented by Bluetooth and 5 GHz Wi-Fi fixes on Rockchip and AYN Odin 2 targets.

On the platform side, the mainline kernel was bumped to 7.3-rc2, a critical stmmac resume-ordering backport restores Ethernet after suspend on RK3588, and sunxi 6.18 and 7.2 gained fixes for eMMC boot hangs and post-reboot Ethernet loss. The installer engine now supports extlinux boards and native USB/NVMe boot on RPi-style hardware, zram-config was corrected for modern kernels, and BSP changes make SSH host key regeneration power-loss safe. Build infrastructure improvements include ORAS gitball use for U-Boot, better shallow-export handling during merge windows, and expanded CI coverage.

#Armbian #EmbeddedLinux #Rockchip #SBC #KernelDevelopment

Changes

View the full article

]]>62109Tue, 15 Sep 2026 01:02:38 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62108-armbian-newsletter-github-highlights/

This week's work centers on new board and SoC enablement, a broad wireless driver and firmware overhaul, and continued kernel, boot, and installer refinements.

Board support expanded on multiple fronts. A new RK3562 family was introduced alongside the KICKPI K3B with mainline U-Boot and Linux, and mainline 7.2 bring-up landed for the S5P6818 platform covering NanoPC-T3+, NanoPi M3, and Fire3. The FriendlyELEC NanoPi R28S, Wildfire Lubancat 3 v2, OrangePi CM5 Base edition, and SpacemiT Musebook (current branch) were added, while the Mixtile Edge2 and Blade 3, Orange Pi 5 Max/Ultra, and Banana Pi M2 Ultra received targeted fixes for Bluetooth, eMMC, Ethernet, and thermal behavior.

Wireless support saw substantial cleanup and expansion. The rtl8723ds driver underwent an extensive warning-elimination pass — addressing -Wmissing-prototypes, -Wempty-body, -Wmaybe-uninitialized, -Wrestrict, and -Warray-bounds findings — with parallel improvements to rtl8189es/fs, rtl8192eu, rtl8852bs, and uwe5622. Firmware additions include MT7986 Wi-Fi and Airoha EN8811H blobs, AIC8800 D80 SDIO names, and AP6212 NVRAM for S5P6818 boards, complemented by Bluetooth and 5 GHz Wi-Fi fixes on Rockchip and AYN Odin 2 targets.

On the platform side, the mainline kernel was bumped to 7.3-rc2, a critical stmmac resume-ordering backport restores Ethernet after suspend on RK3588, and sunxi 6.18 and 7.2 gained fixes for eMMC boot hangs and post-reboot Ethernet loss. The installer engine now supports extlinux boards and native USB/NVMe boot on RPi-style hardware, zram-config was corrected for modern kernels, and BSP changes make SSH host key regeneration power-loss safe. Build infrastructure improvements include ORAS gitball use for U-Boot, better shallow-export handling during merge windows, and expanded CI coverage.

#Armbian #EmbeddedLinux #Rockchip #SBC #KernelDevelopment

Changes

View the full article

]]>62108Tue, 15 Sep 2026 01:02:38 +0000[Collabora] - Re-engineering YouTube for the living room: Bringing Google's Chrobalt to the RDKhttps://testforum.armbian.com/topic/62257-collabora-re-engineering-youtube-for-the-living-room-bringing-googles-chrobalt-to-the-rdk/View the full article

]]>62257Fri, 11 Sep 2026 13:23:00 +0000[Collabora] - Re-engineering YouTube for the Living Room: Bringing Chrobalt to RDKhttps://testforum.armbian.com/topic/62054-collabora-re-engineering-youtube-for-the-living-room-bringing-chrobalt-to-rdk/View the full article

]]>62054Fri, 11 Sep 2026 13:23:00 +0000[Collabora] - Mesa on Android: How We Brought Turnip, SkiaVK, and Cuttlefish to CIhttps://testforum.armbian.com/topic/62035-collabora-mesa-on-android-how-we-brought-turnip-skiavk-and-cuttlefish-to-ci/View the full article

]]>62035Thu, 10 Sep 2026 12:53:18 +0000[Collabora] - Building GPU Drivers in Rust: Tyr at RustConf 2026https://testforum.armbian.com/topic/62018-collabora-building-gpu-drivers-in-rust-tyr-at-rustconf-2026/View the full article

]]>62018Tue, 08 Sep 2026 17:56:00 +0000[Collabora] - From AI video analytics to XR streaming at IBC 2026https://testforum.armbian.com/topic/62015-collabora-from-ai-video-analytics-to-xr-streaming-at-ibc-2026/View the full article

]]>62015Tue, 08 Sep 2026 14:02:28 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/62016-news-from-armbian-github-highlights/

This cycle centers on Linux 7.2/7.3 kernel enablement across out-of-tree drivers, new board support and platform fixes across Rockchip, SpacemiT, and Amlogic, and a broad documentation and CI cleanup.

Kernel progression dominated the driver ecosystem, with 7.3 patch sets prepared for rockchip64, meson64, and the UEFI targets, and edge bumps to 7.2.3 landing for qcs6490, qrb2210, and sc8280xp. A wave of Wi‑Fi drivers was re-enabled and bumped for 7.3 compatibility, including rtl8189es/fs, rtl8192eu, rtl8723ds, rtl8852bs, uwe5622, and bcmdhd-dkms, most addressing the strncpy removal and the cfg80211 remain_on_channel cookie signature change. The rk35xx vendor kernel also advanced to the 6.1.172 rkr7.2 SDK.

Board and platform work introduced GL.iNet GL-MT2500, Xiangcheng XC3399FR, and NanoPi R28S, alongside U-Boot bumps to v2026.07 for Helios64, Odroid N2, Khadas VIM3L, and Mixtile Core3588e. Notable hardware corrections include a cold-boot switch fix on BananaPi R2, RK808 LDO mapping repair on Firefly RK3399 to restore analog audio, RTC correction on Orange Pi Zero 3W, an MSDOS partition table workaround for GPT/eGON on Orange Pi 4A, and SPI controller selection on NanoPi NEO3 Plus. SpacemiT K3 saw defconfig refinements and a transition from extlinux to boot.scr on the Pico ITX.

Infrastructure work focused on documentation consolidation and workflow hardening: a new "Armbian vs Debian & Ubuntu" comparison page, pinned third-party actions with scoped GITHUB_TOKEN, removal of dead PDF plumbing and unused announce workflows, and CI adjustments including GHCR visibility reporting and a lower stall-retry threshold in the SDK. The configng TUI received usability improvements to help text and top-level navigation.

#Armbian #EmbeddedLinux #Rockchip #LinuxKernel #SBC

Changes

View the full article

]]>62016Tue, 08 Sep 2026 13:36:38 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/62013-armbian-newsletter-github-highlights/

This cycle centers on Linux 7.2/7.3 kernel enablement across out-of-tree drivers, new board support and platform fixes across Rockchip, SpacemiT, and Amlogic, and a broad documentation and CI cleanup.

Kernel progression dominated the driver ecosystem, with 7.3 patch sets prepared for rockchip64, meson64, and the UEFI targets, and edge bumps to 7.2.3 landing for qcs6490, qrb2210, and sc8280xp. A wave of Wi‑Fi drivers was re-enabled and bumped for 7.3 compatibility, including rtl8189es/fs, rtl8192eu, rtl8723ds, rtl8852bs, uwe5622, and bcmdhd-dkms, most addressing the strncpy removal and the cfg80211 remain_on_channel cookie signature change. The rk35xx vendor kernel also advanced to the 6.1.172 rkr7.2 SDK.

Board and platform work introduced GL.iNet GL-MT2500, Xiangcheng XC3399FR, and NanoPi R28S, alongside U-Boot bumps to v2026.07 for Helios64, Odroid N2, Khadas VIM3L, and Mixtile Core3588e. Notable hardware corrections include a cold-boot switch fix on BananaPi R2, RK808 LDO mapping repair on Firefly RK3399 to restore analog audio, RTC correction on Orange Pi Zero 3W, an MSDOS partition table workaround for GPT/eGON on Orange Pi 4A, and SPI controller selection on NanoPi NEO3 Plus. SpacemiT K3 saw defconfig refinements and a transition from extlinux to boot.scr on the Pico ITX.

Infrastructure work focused on documentation consolidation and workflow hardening: a new "Armbian vs Debian & Ubuntu" comparison page, pinned third-party actions with scoped GITHUB_TOKEN, removal of dead PDF plumbing and unused announce workflows, and CI adjustments including GHCR visibility reporting and a lower stall-retry threshold in the SDK. The configng TUI received usability improvements to help text and top-level navigation.

#Armbian #EmbeddedLinux #Rockchip #LinuxKernel #SBC

Changes

View the full article

]]>62013Tue, 08 Sep 2026 13:36:38 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61873-armbian-newsletter-github-highlights/

This week's development centered on kernel and toolchain progression, expanded board support, and substantial wireless driver cleanup.

Mainline tracking advanced with kernel bumps to 7.2-rc7, Rockchip edge promoted to 7.2, and sunxi edge moved to 7.1.y. Platform work included loong64 migration from debian-ports to the main Debian archive with corresponding apt repository publishing, mainline kernel and U-Boot enablement on the Avaota A1, restored CONFIG_DWMAC_SUN8I for sunxi64, and a new RK3528 bl32/DDR blob update. Rockchip64 also received backported fixes for an 8250 DMA reopen crash and for CAN TX stalls.

Board coverage grew across multiple vendors, with the NanoPi NEO3 Plus (RK3528A) added and standard-support promotions for the Anbernic RG DS and RG Vita Pro, LubanCat 5IO, Luckfox Nova, and Qidi X-6. UEFI device-tree support was extended with Qualcomm X1E patches and new CIX mainline support, while the Radxa E24C was reworked against U-Boot 26.07 and the v7.2-rcX kernel.

Wireless stacks saw a coordinated quality pass: the rtl8852bs driver had thousands of compiler warnings resolved across missing prototypes, unused functions and variables, enum conversions, and empty-body cases, alongside a NULL-dereference fix and stricter proc write handling. The uwe5622 (unisocwifi) driver received parallel structural cleanups, including a flexible array conversion and forward-declaration hygiene, with both drivers rebased to their August 2026 upstreams.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #MainlineKernel #WirelessDrivers #LoongArch

Changes

View the full article

]]>61873Mon, 31 Aug 2026 22:58:02 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61871-news-from-armbian-github-highlights/

This week's development centered on kernel and toolchain progression, expanded board support, and substantial wireless driver cleanup.

Mainline tracking advanced with kernel bumps to 7.2-rc7, Rockchip edge promoted to 7.2, and sunxi edge moved to 7.1.y. Platform work included loong64 migration from debian-ports to the main Debian archive with corresponding apt repository publishing, mainline kernel and U-Boot enablement on the Avaota A1, restored CONFIG_DWMAC_SUN8I for sunxi64, and a new RK3528 bl32/DDR blob update. Rockchip64 also received backported fixes for an 8250 DMA reopen crash and for CAN TX stalls.

Board coverage grew across multiple vendors, with the NanoPi NEO3 Plus (RK3528A) added and standard-support promotions for the Anbernic RG DS and RG Vita Pro, LubanCat 5IO, Luckfox Nova, and Qidi X-6. UEFI device-tree support was extended with Qualcomm X1E patches and new CIX mainline support, while the Radxa E24C was reworked against U-Boot 26.07 and the v7.2-rcX kernel.

Wireless stacks saw a coordinated quality pass: the rtl8852bs driver had thousands of compiler warnings resolved across missing prototypes, unused functions and variables, enum conversions, and empty-body cases, alongside a NULL-dereference fix and stricter proc write handling. The uwe5622 (unisocwifi) driver received parallel structural cleanups, including a flexible array conversion and forward-declaration hygiene, with both drivers rebased to their August 2026 upstreams.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #MainlineKernel #WirelessDrivers #LoongArch

Changes

View the full article

]]>61871Mon, 31 Aug 2026 22:58:02 +0000[News from Armbian] - Armbian Newsletter August 2026https://testforum.armbian.com/topic/61715-news-from-armbian-armbian-newsletter-august-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

Armbian 26.8 brings a major shift to the ecosystem, focusing heavily on rebuilding and refining the core tools users interact with every day. Anchored by the Linux 7.1 kernel across the tree, this milestone release introduces three major overhauls: a redesigned armbian-install utility featuring expanded boot topologies and standalone bootloader flashing, the all-new Imager 2.0, and standardized UEFI ISO images for seamless deployment across desktop and minimal environments. Paired with expanded platform support stretching from new Rockchip and Qualcomm SBCs to gaming handhelds and 3D printer mainboards Armbian 26.8 turns raw single-board computer hardware into an accessible, enterprise-grade foundation for developers, self-hosters, and hardware enthusiasts alike.

SPONSORED
Armbian Newsletter August 2026

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.

View the full article

]]>61715Wed, 26 Aug 2026 15:35:54 +0000[Armbian newsletter] - Armbian Newsletter August 2026https://testforum.armbian.com/topic/61713-armbian-newsletter-armbian-newsletter-august-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

Armbian 26.8 brings a major shift to the ecosystem, focusing heavily on rebuilding and refining the core tools users interact with every day. Anchored by the Linux 7.1 kernel across the tree, this milestone release introduces three major overhauls: a redesigned armbian-install utility featuring expanded boot topologies and standalone bootloader flashing, the all-new Imager 2.0, and standardized UEFI ISO images for seamless deployment across desktop and minimal environments. Paired with expanded platform support stretching from new Rockchip and Qualcomm SBCs to gaming handhelds and 3D printer mainboards Armbian 26.8 turns raw single-board computer hardware into an accessible, enterprise-grade foundation for developers, self-hosters, and hardware enthusiasts alike.

SPONSORED
Armbian Newsletter August 2026

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.

Armbian release 26.8
Rebuilding the tools you actually touch Kernel 7.1 across the tree, a rewritten installer, Imager 2.0, and UEFI ISO images Three rewrites in one cycle Most releases are a long list of small improvements. This one had three larger pieces landing at roughly the same time, and all
SBC storage
Modernizing SBC Storage: From Qualcomm EDL Flashing to SPI-to-NVMe Boots For years, single-board computer (SBC) storage followed a simple, predictable pattern: flash an image onto a microSD card or eMMC module, plug it in, and turn on the board. However, as modern embedded hardware approaches laptop-grade
One board, two architectures: Armbian on the Milk-V Duo S
The Milk-V Duo S is a very cheap and small board. It runs a Sophgo SG2000 with an Arm Cortex-A53 and a RISC-V C906, 512 MB of RAM, and a physical slide switch decides which one boots. Armbian now supports both architectures. PR #10326 landed the port
Armbian image writer
Armbian has this awesome Image Writer that I have to show off — it’s just too good not to. And if you haven’t checked out the Armbian website recently, do yo…

View the full article

]]>61713Wed, 26 Aug 2026 15:35:54 +0000[News from Armbian] - One board, two architectures: Armbian on the Milk-V Duo Shttps://testforum.armbian.com/topic/61716-news-from-armbian-one-board-two-architectures-armbian-on-the-milk-v-duo-s/

The Milk-V Duo S is a very cheap and small board. It runs a Sophgo SG2000 with
an Arm Cortex-A53 and a RISC-V C906, 512 MB of RAM, and a physical slide switch decides which
one boots. Armbian now supports both architectures. PR #10326 landed the port (175 files) as two thin board targets – milkv-duos-arm and milkv-duos-riscv – over a single shared family include, so the bootloader pins can't drift apart. PR #10510 moved the edge branch to kernel 7.1.

Standing on the shoulders of others

There are at least 2 projects the port owes a lot to: queenkjuul/milkv-duo-ubuntu (Ubuntu on a mainline kernel 7.0, RISC-V) and Fishwaldo/sophgo-sg200x-debian (Debian sid, vendor kernel 5.10). Armbian takes the mainline route, adds arm64, and builds the entire boot chain from source: no prebuilt fip.bin.

What the patches add

Kernel (57 patches per branch, one series for both architectures – the arm64
device tree includes the RISC-V ones): thermal sensor, watchdog, PWM, eFuse, DMA, MDIO mux, I2S, mailbox, the C906L coprocessor, correct eMMC and
microSD pin muxing, USB gadget mode, ramoops, and overlays for the 26-pin header (I²C, SPI, UART, PWM) and USB device mode.

U-Boot (vendor 2021.10): distroboot: the standard armbianEnv.txt + boot.scr mechanism works and overlays are chosen at boot rather than at build (like in other implementations), plus a fix for the SD slot being powered down when empty.

1050 MHz as a default RISC-V speed. Provided by a build option
SOPHGO_CPU_OVERDRIVE.

Both bootloaders ship in every image, so one image boots from microSD or eMMC – but flashing to the eMMC still requires special treatment using sophgo-emmc-install.

./compile.sh build BOARD=milkv-duos-arm BRANCH=edge

Usage example

The board runs under 1 W, so it can make a nice always-on serial console.
milkv-duos-uart turns a Duo S into a recorder for Rockchip boards (or any others!): enable the UART2 overlay, connect three pins, and it keeps a 32 MiB RAM ring buffer you can follow, dump as history, or attachand use like a normal console. This way a guest's boot log can survive even it it dies.

What are your ideas for this board?

View the full article

]]>61716Wed, 26 Aug 2026 15:31:13 +0000[Armbian newsletter] - One board, two architectures: Armbian on the Milk-V Duo Shttps://testforum.armbian.com/topic/61714-armbian-newsletter-one-board-two-architectures-armbian-on-the-milk-v-duo-s/

The Milk-V Duo S is a very cheap and small board. It runs a Sophgo SG2000 with
an Arm Cortex-A53 and a RISC-V C906, 512 MB of RAM, and a physical slide switch decides which
one boots. Armbian now supports both architectures. PR #10326 landed the port (175 files) as two thin board targets – milkv-duos-arm and milkv-duos-riscv – over a single shared family include, so the bootloader pins can't drift apart. PR #10510 moved the edge branch to kernel 7.1.

Standing on the shoulders of others

There are at least 2 projects the port owes a lot to: queenkjuul/milkv-duo-ubuntu (Ubuntu on a mainline kernel 7.0, RISC-V) and Fishwaldo/sophgo-sg200x-debian (Debian sid, vendor kernel 5.10). Armbian takes the mainline route, adds arm64, and builds the entire boot chain from source: no prebuilt fip.bin.

What the patches add

Kernel (57 patches per branch, one series for both architectures – the arm64
device tree includes the RISC-V ones): thermal sensor, watchdog, PWM, eFuse, DMA, MDIO mux, I2S, mailbox, the C906L coprocessor, correct eMMC and
microSD pin muxing, USB gadget mode, ramoops, and overlays for the 26-pin header (I²C, SPI, UART, PWM) and USB device mode.

U-Boot (vendor 2021.10): distroboot: the standard armbianEnv.txt + boot.scr mechanism works and overlays are chosen at boot rather than at build (like in other implementations), plus a fix for the SD slot being powered down when empty.

1050 MHz as a default RISC-V speed. Provided by a build option
SOPHGO_CPU_OVERDRIVE.

Both bootloaders ship in every image, so one image boots from microSD or eMMC – but flashing to the eMMC still requires special treatment using sophgo-emmc-install.

./compile.sh build BOARD=milkv-duos-arm BRANCH=edge

Usage example

The board runs under 1 W, so it can make a nice always-on serial console.
milkv-duos-uart turns a Duo S into a recorder for Rockchip boards (or any others!): enable the UART2 overlay, connect three pins, and it keeps a 32 MiB RAM ring buffer you can follow, dump as history, or attachand use like a normal console. This way a guest's boot log can survive even it it dies.

What are your ideas for this board?

View the full article

]]>61714Wed, 26 Aug 2026 15:31:13 +0000[Collabora] - Building Tyr in Rust, part 3: Managing GPU memoryhttps://testforum.armbian.com/topic/61722-collabora-building-tyr-in-rust-part-3-managing-gpu-memory/GPU kernel driver work puts GPU memory management in place, from VM binding and GPUVM to GEM-backed buffers and firmware boot, moving key pieces upstream before tackling synchronization next.

View the full article

]]>61722Wed, 26 Aug 2026 14:10:14 +0000[Armbian newsletter] - SBC storagehttps://testforum.armbian.com/topic/61702-armbian-newsletter-sbc-storage/Modernizing SBC Storage: From Qualcomm EDL Flashing to SPI-to-NVMe BootsSBC storage

For years, single-board computer (SBC) storage followed a simple, predictable pattern: flash an image onto a microSD card or eMMC module, plug it in, and turn on the board. However, as modern embedded hardware approaches laptop-grade performance, that legacy approach is starting to break down.

The latest quarter of Armbian development highlights a major shift toward modern storage pipelines. By combining Qualcomm Emergency Download (EDL) flashing in Armbian Imager 2.0 with a redesigned installation engine, Armbian is making high-performance hardware far easier to set up.

Direct Qualcomm Flashing with Imager 2.0

As boards like the Radxa Dragon Q6A and Q8B bring Qualcomm Snapdragon chips to developers, standard image writers no longer work. These devices require low-level vendor tools to write to storage before an operating system can even start.

Armbian Imager 2.0 now handles EDL flashing directly over USB without third-party software, automatically tailoring the setup to the specific hardware:

Radxa Dragon (Q6A & Q8B): Flashes directly to high-speed UFS storage, setting up the board’s custom UEFI boot environment.(Note: Users will need to enter the UEFI menu and set the boot order manually after flashing to boot from UFS).

Arduino Qualcomm Boards: Flashes directly to onboard eMMC storage, setting up a U-Boot environment.

Because EDL writes straight to the main storage, it leaves external SPI flash completely untouched, providing a clean, single-step recovery or setup process.

Decoupling Boot Files for Faster Drives

On powerful boards like those using the Rockchip RK3588, running an entire system from an SD card or eMMC creates a storage bottleneck. The ideal setup separates where the board starts from where it runs: loading basic boot files from tiny onboard memory (SPI NOR flash), then handing the heavy lifting off to a fast NVMe SSD or SATA drive.

View the full article

]]>61702Wed, 26 Aug 2026 03:37:40 +0000[News from Armbian] - SBC storagehttps://testforum.armbian.com/topic/61701-news-from-armbian-sbc-storage/Modernizing SBC Storage: From Qualcomm EDL Flashing to SPI-to-NVMe BootsSBC storage

For years, single-board computer (SBC) storage followed a simple, predictable pattern: flash an image onto a microSD card or eMMC module, plug it in, and turn on the board. However, as modern embedded hardware approaches laptop-grade performance, that legacy approach is starting to break down.

The latest quarter of Armbian development highlights a major shift toward modern storage pipelines. By combining Qualcomm Emergency Download (EDL) flashing in Armbian Imager 2.0 with a redesigned installation engine, Armbian is making high-performance hardware far easier to set up.

Direct Qualcomm Flashing with Imager 2.0

As boards like the Radxa Dragon Q6A and Q8B bring Qualcomm Snapdragon chips to developers, standard image writers no longer work. These devices require low-level vendor tools to write to storage before an operating system can even start.

Armbian Imager 2.0 now handles EDL flashing directly over USB without third-party software, automatically tailoring the setup to the specific hardware:

Radxa Dragon (Q6A & Q8B): Flashes directly to high-speed UFS storage, setting up the board’s custom UEFI boot environment.(Note: Users will need to enter the UEFI menu and set the boot order manually after flashing to boot from UFS).

Arduino Qualcomm Boards: Flashes directly to onboard eMMC storage, setting up a U-Boot environment.

Because EDL writes straight to the main storage, it leaves external SPI flash completely untouched, providing a clean, single-step recovery or setup process.

Decoupling Boot Files for Faster Drives

On powerful boards like those using the Rockchip RK3588, running an entire system from an SD card or eMMC creates a storage bottleneck. The ideal setup separates where the board starts from where it runs: loading basic boot files from tiny onboard memory (SPI NOR flash), then handing the heavy lifting off to a fast NVMe SSD or SATA drive.

View the full article

]]>61701Wed, 26 Aug 2026 03:37:40 +0000[News from Armbian] - Armbian release 26.8https://testforum.armbian.com/topic/61700-news-from-armbian-armbian-release-268/Rebuilding the tools you actually touchArmbian release 26.8

Kernel 7.1 across the tree, a rewritten installer, Imager 2.0, and UEFI ISO images

Three rewrites in one cycle

Most releases are a long list of small improvements. This one had three larger pieces landing at roughly the same time, and all three touch parts of Armbian that people use directly rather than parts they only read about in changelogs.

The installer was rewritten. Armbian Imager reached 2.0. And our CI moved out of the repository it had outgrown into one built for the job. None of these were planned to coincide; they simply reached the point where postponing them again would have cost more than doing them.

The installer rewrite is the one I expect people to notice first. It now ships as an armbian-config module, which means it is unit-tested, the same way the rest of armbian-config is tested, rather than living as a script that everyone was slightly afraid to touch. It can target SPI and MTD, treats eMMC and NVMe as separate flows instead of pretending they are the same thing, can flash a bootloader on its own, and — this one is overdue — reports when a bootloader write fails instead of printing "Done." and leaving you to find out at the next boot.

As always, every image in this release was manually validated for basic functionality. The automation keeps improving, but a board that boots in CI and a board that boots on a desk are still two different things.

Igor
Project Manager

Changes overview

This release advances on three fronts: kernel and firmware baselines moved forward across the entire tree, the tooling around installing and writing images was rebuilt, and the build and CI infrastructure was restructured onto Debian Trixie with a weekly stable cadence.

Kernels and firmware

Mainline support moves to 7.1 stable, with 7.2 available on edge branches for rockchip64, meson64, mvebu64, sunxi and bcm2711. U-Boot went to v2026.07 across most of boards, including the Rockchip RK35xx family, Amlogic, i.MX6, and the mvebu.

A number of long-carried patches were finally dropped this cycle because upstream fixed them properly — the 8250 DMA reopen crash, the SysRq-via-BREAK handling, several sunxi and meson64 patches. Carrying fewer patches is not a headline feature, but it is what makes the next kernel bump cheaper than the last one.

Wireless driver cleanup

The rtl8852bs, rtl8189es, rtl8192eu and uwe5622 drivers now live in dedicated Armbian repositories, build against up to 7.2, and are several thousand compiler warnings quieter than they were in June. That work was not cosmetic: going through the warnings surfaced a use-after-free in the uwe5622 probe path, a NULL dereference on efuse allocation failure, a leaked path reference, and a handful of unbounded copies in ioctl handlers. Vendor Wi-Fi blobs have been the least-inspected code in the tree for years. They are meaningfully less so now.

Incoming hardware

New this cycle: Anbernic RG DS and RG Vita Pro, Radxa Cubie A7Z and Dragon Q6A/Q8B, Seeed reComputer RK3576 and RK3588 DevKits, TI BeagleBadge and TMDS64EVM, Orange Pi 4 Pro and Zero 3W, Sovol Zero and SV08, Walnut Pi Box and 1B, EmbedFire LubanCat 5IO, LuckFox Nova, SpacemiT K3 Pico-ITX, Milk-V DuoS, Avnet MaaXBoard 8ULP, NanoPi NEO3 Plus, KICKPI K3B, Graperain G3568 v2, EASY EAI Nano, Mellow Fly C5, CIX P1, Xiaomi Pad 6S Pro and Tanix TX6S. Fourteen existing boards were promoted to standard support, a few dropped to community support, and Banana Pi R2 came back from the dead on 6.18.

Imager and image formats

Armbian Imager 2.0 adds QDL and UFS flashing for Qualcomm targets, pulls the board registry from the Armbian API rather than shipping a copy that goes stale, and enumerates devices more carefully on both Windows and Linux.

UEFI images can now be built as bootable live ISOs through the new image-output-iso extension. This makes Armbian directly usable over IPMI virtual CD and in cloud environments where an ISO is the only accepted input. The download and redirector infrastructure was extended to carry those ISOs alongside the compressed raw images.

Build framework and CI

CI moved out of armbian/os into its own armbian/ci repository. Runners register through NetBox, each one carrying its own proxy and cache export configuration, and a watchdog automatically retries runs killed by stalled runners rather than leaving a red cross for someone to notice in the morning. Stable builds now run weekly.

The default build host and Docker base image are Debian Trixie, which forced a long tail of fixes to older U-Boot trees against GCC 14 and SWIG 4.3 — the kind of work that is invisible when it succeeds. riscv64 images are now generated natively, and kernel patch rewriting runs in parallel with stricter From-header hygiene.

Every board, every promotion and every one of the 787 merged pull requests is listed in the release notes.

Thank you

787 pull requests went into this release, from long-standing team members and from people who showed up once to fix a device tree on a board nobody else owns. Both matter. The wireless cleanup in particular was one contributor deciding that thousands of warnings were worth working through, one file at a time.

And to our partners and donors — hardware, infrastructure, engineering time, and money — thank you. The infrastructure work in this release is expensive in exactly the way that is hard to fundraise for, and it happened because you make it possible.

View the full article

]]>61700Tue, 25 Aug 2026 20:49:35 +0000[Armbian newsletter] - Armbian release 26.8https://testforum.armbian.com/topic/61698-armbian-newsletter-armbian-release-268/Rebuilding the tools you actually touchArmbian release 26.8

Kernel 7.1 across the tree, a rewritten installer, Imager 2.0, and UEFI ISO images

Three rewrites in one cycle

Most releases are a long list of small improvements. This one had three larger pieces landing at roughly the same time, and all three touch parts of Armbian that people use directly rather than parts they only read about in changelogs.

The installer was rewritten. Armbian Imager reached 2.0. And our CI moved out of the repository it had outgrown into one built for the job. None of these were planned to coincide; they simply reached the point where postponing them again would have cost more than doing them.

The installer rewrite is the one I expect people to notice first. It now ships as an armbian-config module, which means it is unit-tested, the same way the rest of armbian-config is tested, rather than living as a script that everyone was slightly afraid to touch. It can target SPI and MTD, treats eMMC and NVMe as separate flows instead of pretending they are the same thing, can flash a bootloader on its own, and — this one is overdue — reports when a bootloader write fails instead of printing "Done." and leaving you to find out at the next boot.

As always, every image in this release was manually validated for basic functionality. The automation keeps improving, but a board that boots in CI and a board that boots on a desk are still two different things.

Igor
Project Manager

Changes overview

This release advances on three fronts: kernel and firmware baselines moved forward across the entire tree, the tooling around installing and writing images was rebuilt, and the build and CI infrastructure was restructured onto Debian Trixie with a weekly stable cadence.

Kernels and firmware

Mainline support moves to 7.1 stable, with 7.2 available on edge branches for rockchip64, meson64, mvebu64, sunxi and bcm2711. U-Boot went to v2026.07 across most of boards, including the Rockchip RK35xx family, Amlogic, i.MX6, and the mvebu.

A number of long-carried patches were finally dropped this cycle because upstream fixed them properly — the 8250 DMA reopen crash, the SysRq-via-BREAK handling, several sunxi and meson64 patches. Carrying fewer patches is not a headline feature, but it is what makes the next kernel bump cheaper than the last one.

Wireless driver cleanup

The rtl8852bs, rtl8189es, rtl8192eu and uwe5622 drivers now live in dedicated Armbian repositories, build against up to 7.2, and are several thousand compiler warnings quieter than they were in June. That work was not cosmetic: going through the warnings surfaced a use-after-free in the uwe5622 probe path, a NULL dereference on efuse allocation failure, a leaked path reference, and a handful of unbounded copies in ioctl handlers. Vendor Wi-Fi blobs have been the least-inspected code in the tree for years. They are meaningfully less so now.

Incoming hardware

New this cycle: Anbernic RG DS and RG Vita Pro, Radxa Cubie A7Z and Dragon Q6A/Q8B, Seeed reComputer RK3576 and RK3588 DevKits, TI BeagleBadge and TMDS64EVM, Orange Pi 4 Pro and Zero 3W, Sovol Zero and SV08, Walnut Pi Box and 1B, EmbedFire LubanCat 5IO, LuckFox Nova, SpacemiT K3 Pico-ITX, Milk-V DuoS, Avnet MaaXBoard 8ULP, NanoPi NEO3 Plus, KICKPI K3B, Graperain G3568 v2, EASY EAI Nano, Mellow Fly C5, CIX P1, Xiaomi Pad 6S Pro and Tanix TX6S. Fourteen existing boards were promoted to standard support, a few dropped to community support, and Banana Pi R2 came back from the dead on 6.18.

Imager and image formats

Armbian Imager 2.0 adds QDL and UFS flashing for Qualcomm targets, pulls the board registry from the Armbian API rather than shipping a copy that goes stale, and enumerates devices more carefully on both Windows and Linux.

UEFI images can now be built as bootable live ISOs through the new image-output-iso extension. This makes Armbian directly usable over IPMI virtual CD and in cloud environments where an ISO is the only accepted input. The download and redirector infrastructure was extended to carry those ISOs alongside the compressed raw images.

Build framework and CI

CI moved out of armbian/os into its own armbian/ci repository. Runners register through NetBox, each one carrying its own proxy and cache export configuration, and a watchdog automatically retries runs killed by stalled runners rather than leaving a red cross for someone to notice in the morning. Stable builds now run weekly.

The default build host and Docker base image are Debian Trixie, which forced a long tail of fixes to older U-Boot trees against GCC 14 and SWIG 4.3 — the kind of work that is invisible when it succeeds. riscv64 images are now generated natively, and kernel patch rewriting runs in parallel with stricter From-header hygiene.

Every board, every promotion and every one of the 787 merged pull requests is listed in the release notes.

Thank you

787 pull requests went into this release, from long-standing team members and from people who showed up once to fix a device tree on a board nobody else owns. Both matter. The wireless cleanup in particular was one contributor deciding that thousands of warnings were worth working through, one file at a time.

And to our partners and donors — hardware, infrastructure, engineering time, and money — thank you. The infrastructure work in this release is expensive in exactly the way that is hard to fundraise for, and it happened because you make it possible.

View the full article

]]>61698Tue, 25 Aug 2026 20:49:35 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61694-news-from-armbian-github-highlights/

This week's changes center on expanded board and platform support, a modernized build and release pipeline anchored on Debian Trixie and ISO output, and a substantial documentation and release-process overhaul.

On the hardware side, the EmbedFire LubanCat 4 (RK3588S) and Xiaomi Pad 6S Pro (sheng) join as new boards, Tanix TX6S is promoted to Supported, and Banana Pi R2 (MT7623) returns with kernel 6.18, edge 7.1, and U-Boot 2026.07. The reComputer RK3588 moves to the Panthor open-source GPU stack, NanoPCT6 U-Boot advances to v2026.07, and reComputer RK3576/RK3588 receives U-Boot fixes for SPI boot, NVMe, and rockusb. Several Rockchip and Qualcomm device trees are corrected, and RTL8852BS, RTL88x2CS, and related wireless drivers are refreshed with substantial warning cleanup.

Build infrastructure sees the official host and default Docker image switch to Debian Trixie, Ubuntu Noble dropped from release and SDK targets, and image signing extended to every format. UEFI current/edge targets now ship as ISO for both minimal and desktop variants, nightly builds are restricted to platinum boards, and SDK CI moves to self-hosted runners with auto-retry and dispatch-driven index updates. A weekly stable build with automatic version bump is now scheduled.

Documentation and release tooling receive extensive rework: armbian-config pages are reorganized under /config/ with per-subcategory splits, per-app SEO pages and category hubs are emitted, and the manual changelog is replaced by per-release pages with a quarterly digest published to docs.armbian.com. Release-summary generation now groups by source repository, recovers PR links, and is anchored to release windows.

#Armbian #EmbeddedLinux #Rockchip #DebianTrixie #ReleaseEngineering

Changes

View the full article

]]>61694Tue, 25 Aug 2026 11:59:30 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61693-armbian-newsletter-github-highlights/

This week's changes center on expanded board and platform support, a modernized build and release pipeline anchored on Debian Trixie and ISO output, and a substantial documentation and release-process overhaul.

On the hardware side, the EmbedFire LubanCat 4 (RK3588S) and Xiaomi Pad 6S Pro (sheng) join as new boards, Tanix TX6S is promoted to Supported, and Banana Pi R2 (MT7623) returns with kernel 6.18, edge 7.1, and U-Boot 2026.07. The reComputer RK3588 moves to the Panthor open-source GPU stack, NanoPCT6 U-Boot advances to v2026.07, and reComputer RK3576/RK3588 receives U-Boot fixes for SPI boot, NVMe, and rockusb. Several Rockchip and Qualcomm device trees are corrected, and RTL8852BS, RTL88x2CS, and related wireless drivers are refreshed with substantial warning cleanup.

Build infrastructure sees the official host and default Docker image switch to Debian Trixie, Ubuntu Noble dropped from release and SDK targets, and image signing extended to every format. UEFI current/edge targets now ship as ISO for both minimal and desktop variants, nightly builds are restricted to platinum boards, and SDK CI moves to self-hosted runners with auto-retry and dispatch-driven index updates. A weekly stable build with automatic version bump is now scheduled.

Documentation and release tooling receive extensive rework: armbian-config pages are reorganized under /config/ with per-subcategory splits, per-app SEO pages and category hubs are emitted, and the manual changelog is replaced by per-release pages with a quarterly digest published to docs.armbian.com. Release-summary generation now groups by source repository, recovers PR links, and is anchored to release windows.

#Armbian #EmbeddedLinux #Rockchip #DebianTrixie #ReleaseEngineering

Changes

View the full article

]]>61693Tue, 25 Aug 2026 11:59:30 +0000[Collabora] - Kernel 7.2: RK3588 media, smarter GPU memory, and Rust foundationshttps://testforum.armbian.com/topic/61681-collabora-kernel-72-rk3588-media-smarter-gpu-memory-and-rust-foundations/SoC enablement.

View the full article

]]>61681Tue, 18 Aug 2026 13:53:19 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61560-news-from-armbian-github-highlights/

This week's development centered on kernel and toolchain progression, expanded board support, and substantial wireless driver cleanup.

Mainline tracking advanced with kernel bumps to 7.2-rc7, Rockchip edge promoted to 7.2, and sunxi edge moved to 7.1.y. Platform work included loong64 migration from debian-ports to the main Debian archive with corresponding apt repository publishing, mainline kernel and U-Boot enablement on the Avaota A1, restored CONFIG_DWMAC_SUN8I for sunxi64, and a new RK3528 bl32/DDR blob update. Rockchip64 also received backported fixes for an 8250 DMA reopen crash and for CAN TX stalls.

Board coverage grew across multiple vendors, with the NanoPi NEO3 Plus (RK3528A) added and standard-support promotions for the Anbernic RG DS and RG Vita Pro, LubanCat 5IO, Luckfox Nova, and Qidi X-6. UEFI device-tree support was extended with Qualcomm X1E patches and new CIX mainline support, while the Radxa E24C was reworked against U-Boot 26.07 and the v7.2-rcX kernel.

Wireless stacks saw a coordinated quality pass: the rtl8852bs driver had thousands of compiler warnings resolved across missing prototypes, unused functions and variables, enum conversions, and empty-body cases, alongside a NULL-dereference fix and stricter proc write handling. The uwe5622 (unisocwifi) driver received parallel structural cleanups, including a flexible array conversion and forward-declaration hygiene, with both drivers rebased to their August 2026 upstreams.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #MainlineKernel #WirelessDrivers #LoongArch

Changes

View the full article

]]>61560Tue, 18 Aug 2026 00:40:57 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61559-armbian-newsletter-github-highlights/

This week's development centered on kernel and toolchain progression, expanded board support, and substantial wireless driver cleanup.

Mainline tracking advanced with kernel bumps to 7.2-rc7, Rockchip edge promoted to 7.2, and sunxi edge moved to 7.1.y. Platform work included loong64 migration from debian-ports to the main Debian archive with corresponding apt repository publishing, mainline kernel and U-Boot enablement on the Avaota A1, restored CONFIG_DWMAC_SUN8I for sunxi64, and a new RK3528 bl32/DDR blob update. Rockchip64 also received backported fixes for an 8250 DMA reopen crash and for CAN TX stalls.

Board coverage grew across multiple vendors, with the NanoPi NEO3 Plus (RK3528A) added and standard-support promotions for the Anbernic RG DS and RG Vita Pro, LubanCat 5IO, Luckfox Nova, and Qidi X-6. UEFI device-tree support was extended with Qualcomm X1E patches and new CIX mainline support, while the Radxa E24C was reworked against U-Boot 26.07 and the v7.2-rcX kernel.

Wireless stacks saw a coordinated quality pass: the rtl8852bs driver had thousands of compiler warnings resolved across missing prototypes, unused functions and variables, enum conversions, and empty-body cases, alongside a NULL-dereference fix and stricter proc write handling. The uwe5622 (unisocwifi) driver received parallel structural cleanups, including a flexible array conversion and forward-declaration hygiene, with both drivers rebased to their August 2026 upstreams.

#Armbian #EmbeddedLinux #Rockchip #Allwinner #MainlineKernel #WirelessDrivers #LoongArch

Changes

View the full article

]]>61559Tue, 18 Aug 2026 00:40:57 +0000[Collabora] - MediaTek Genio upstream update: from HDMI 2.0 to booting on U-Boot and TF-Ahttps://testforum.armbian.com/topic/61485-collabora-mediatek-genio-upstream-update-from-hdmi-20-to-booting-on-u-boot-and-tf-a/View the full article

]]>61485Wed, 12 Aug 2026 16:21:47 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61467-news-from-armbian-github-highlights/

This week's work centers on kernel 7.2 enablement across out-of-tree drivers, a redesigned armbian-install with expanded boot topologies, and new UEFI cloud ISO delivery alongside board additions.

The mainline bump to 7.2-rc6 drove a coordinated pass through wireless and peripheral drivers, with compatibility updates landing for uwe5622, rtl8723ds, rtl8852bs, and radxa-aic8800, plus a broader rewrite of kernel configs and patch sets for the new baseline. Rockchip received targeted fixes including RGA3 upscaling flicker correction, scoped rk3576 HS400 DLL calibration, RK808 clkout cell naming, and a switch to CUBIC congestion control as the default. Additional platform work covers mvebu64 kernel bumps to 6.12/6.18/7.1, SpacemiT K1 patch cleanup now that changes are upstream, imx93 build repair on 6.18.42, and a btrfs-enabling CRC32C config change applied across all boards.

The armbian-install tool was redesigned as a tested armbian-config module, gaining eMMC/NVMe boot fixes, a split boot-from-eMMC installer, SPI/MTD boot with root on NVMe/SATA/USB, and clearer diagnostics for blocked dual-boot scenarios such as BitLocker or dirty NTFS volumes. Companion configng modules add Proxmox VE on Debian trixie, virt-manager alongside Cockpit for desktop hosts, UEFI defaults for new x86 VMs, and docker-buildx on distro-maintained installs.

Image delivery expands with a new image-output-iso extension producing bootable live ISOs from UEFI images for cloud and IPMI virtual CD use, backed by CI changes to sign, torrent, and publish ISO artifacts, and a website update surfacing the new image type. Board support grows with the Milk-V DuoS (aarch64+riscv64), Walnut Pi Box and 1B DDR3 variant, Tanix TX6S, Odin3 bringup, and a promotion pass moving tested boards into supported configuration.

#Armbian #EmbeddedLinux #Kernel72 #Rockchip #UEFI #RISCV

Changes

View the full article

]]>61467Tue, 11 Aug 2026 01:10:46 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61466-armbian-newsletter-github-highlights/

This week's work centers on kernel 7.2 enablement across out-of-tree drivers, a redesigned armbian-install with expanded boot topologies, and new UEFI cloud ISO delivery alongside board additions.

The mainline bump to 7.2-rc6 drove a coordinated pass through wireless and peripheral drivers, with compatibility updates landing for uwe5622, rtl8723ds, rtl8852bs, and radxa-aic8800, plus a broader rewrite of kernel configs and patch sets for the new baseline. Rockchip received targeted fixes including RGA3 upscaling flicker correction, scoped rk3576 HS400 DLL calibration, RK808 clkout cell naming, and a switch to CUBIC congestion control as the default. Additional platform work covers mvebu64 kernel bumps to 6.12/6.18/7.1, SpacemiT K1 patch cleanup now that changes are upstream, imx93 build repair on 6.18.42, and a btrfs-enabling CRC32C config change applied across all boards.

The armbian-install tool was redesigned as a tested armbian-config module, gaining eMMC/NVMe boot fixes, a split boot-from-eMMC installer, SPI/MTD boot with root on NVMe/SATA/USB, and clearer diagnostics for blocked dual-boot scenarios such as BitLocker or dirty NTFS volumes. Companion configng modules add Proxmox VE on Debian trixie, virt-manager alongside Cockpit for desktop hosts, UEFI defaults for new x86 VMs, and docker-buildx on distro-maintained installs.

Image delivery expands with a new image-output-iso extension producing bootable live ISOs from UEFI images for cloud and IPMI virtual CD use, backed by CI changes to sign, torrent, and publish ISO artifacts, and a website update surfacing the new image type. Board support grows with the Milk-V DuoS (aarch64+riscv64), Walnut Pi Box and 1B DDR3 variant, Tanix TX6S, Odin3 bringup, and a promotion pass moving tested boards into supported configuration.

#Armbian #EmbeddedLinux #Kernel72 #Rockchip #UEFI #RISCV

Changes

View the full article

]]>61466Tue, 11 Aug 2026 01:10:46 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61318-news-from-armbian-github-highlights/

This week's work centers on a consolidated uwe5622 Wi-Fi/Bluetooth driver, CI and repository infrastructure changes, and board and toolchain enablement across multiple SoC families.

The uwe5622 driver has been relocated to a dedicated repository and unified across kernel versions. Initial commits address a use-after-free in mtty_probe(), resolve 157 -Wmissing-prototypes warnings, correct dev_addr const guards for kernels 5.17–6.18 under clang, and fix sdio_pub_int_init for the newer gpiod int_ap API on GCC 14. The build system now sources the driver from this repository, adds a GitHub Actions test workflow, and refactors the associated DVFS patch and kernel configuration.

CI and publishing pipelines received substantial attention. Nightly images have moved from the os to the ci release channel, with the download portal, router, and reporting scripts updated to match. The community build now publishes to its own repository and version series, dispatch inputs have been trimmed, and board/maintainer dropdowns are auto-generated for standard-support builds. Stall recovery gained a five-attempt budget with a >50% success gate, later raised back to ten attempts. On the repository side, repo-reprepro now skips missing .deb files rather than aborting and logs a single count of skipped packages.

Platform work spans several architectures. New boards include the Anbernic RG Vita Pro (RK3576) handheld and the Recomputer RK3576 devkit, while EasePi-A2/R2 mainline U-Boot advances to v2026.07. Toolchain fixes enable imx8ulp libbpf builds on GCC 15, fit the AM62P/AM62-LP R5 SPL into SRAM under GCC 13, and correct a sunxi-6.12 Bluetooth quirk for the pre-6.16 API. Additional user-visible changes include a new BTRFS_CHECKSUM build switch, F2FS enabled across all kernels via a central config hook, and parallelized patch rewriting scaled to nproc.

#Armbian #EmbeddedLinux #RK3576 #uwe5622 #CI

Changes

View the full article

]]>61318Tue, 04 Aug 2026 01:34:40 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61317-armbian-newsletter-github-highlights/

This week's work centers on a consolidated uwe5622 Wi-Fi/Bluetooth driver, CI and repository infrastructure changes, and board and toolchain enablement across multiple SoC families.

The uwe5622 driver has been relocated to a dedicated repository and unified across kernel versions. Initial commits address a use-after-free in mtty_probe(), resolve 157 -Wmissing-prototypes warnings, correct dev_addr const guards for kernels 5.17–6.18 under clang, and fix sdio_pub_int_init for the newer gpiod int_ap API on GCC 14. The build system now sources the driver from this repository, adds a GitHub Actions test workflow, and refactors the associated DVFS patch and kernel configuration.

CI and publishing pipelines received substantial attention. Nightly images have moved from the os to the ci release channel, with the download portal, router, and reporting scripts updated to match. The community build now publishes to its own repository and version series, dispatch inputs have been trimmed, and board/maintainer dropdowns are auto-generated for standard-support builds. Stall recovery gained a five-attempt budget with a >50% success gate, later raised back to ten attempts. On the repository side, repo-reprepro now skips missing .deb files rather than aborting and logs a single count of skipped packages.

Platform work spans several architectures. New boards include the Anbernic RG Vita Pro (RK3576) handheld and the Recomputer RK3576 devkit, while EasePi-A2/R2 mainline U-Boot advances to v2026.07. Toolchain fixes enable imx8ulp libbpf builds on GCC 15, fit the AM62P/AM62-LP R5 SPL into SRAM under GCC 13, and correct a sunxi-6.12 Bluetooth quirk for the pre-6.16 API. Additional user-visible changes include a new BTRFS_CHECKSUM build switch, F2FS enabled across all kernels via a central config hook, and parallelized patch rewriting scaled to nproc.

#Armbian #EmbeddedLinux #RK3576 #uwe5622 #CI

Changes

View the full article

]]>61317Tue, 04 Aug 2026 01:34:40 +0000[Collabora] - Kraid is a now a real compilerhttps://testforum.armbian.com/topic/61233-collabora-kraid-is-a-now-a-real-compiler/Panfrost driver stack, now passes all 800,000 Vulkan CTS compute shader tests. This marks a major milestone, with work continuing on additional shader stages, code quality, and performance optimization.

View the full article

]]>61233Thu, 30 Jul 2026 14:50:52 +0000[Armbian newsletter] - Armbian Newsletter July 2026https://testforum.armbian.com/topic/61224-armbian-newsletter-armbian-newsletter-july-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

The upcoming Armbian release 26.08 will be based on Linux 6.18 LTS, giving users the benefits of a long-term support kernel with improved hardware compatibility, security updates, and ongoing upstream maintenance. This provides a solid foundation for future development while keeping systems stable and reliable.

SPONSORED
Armbian Newsletter July 2026

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability so everyone can enjoy a solid foundation for their devices.

Github Highlights
This week’s work centers on new board enablement and platform maintenance, kernel and U-Boot refresh across Rockchip and Sunxi, and CI/build infrastructure improvements. Board support expanded with the addition of Sovol Zero, SV08, and SV08 Max on the H616 platform, alongside mainline and edge enablement for the
Beat the heat
Rising summer ambient temperatures erode the thermal headroom SBCs rely on, causing silent throttling and instability. Here’s why high-density SoCs like the RK3588 are most at risk, and how to pick the right cooling strategy to stay stable.
The factory behind Armbian
When you download an Armbian image, flash it to your SD card or SSD, and boot your board, a huge amount of automation has already happened behind the scenes. That invisible engine is what you can see at https://actions.armbian.com. Think of it as the mission control center

View the full article

]]>61224Wed, 29 Jul 2026 15:29:43 +0000[News from Armbian] - Armbian Newsletter July 2026https://testforum.armbian.com/topic/61223-news-from-armbian-armbian-newsletter-july-2026/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

The upcoming Armbian release 26.08 will be based on Linux 6.18 LTS, giving users the benefits of a long-term support kernel with improved hardware compatibility, security updates, and ongoing upstream maintenance. This provides a solid foundation for future development while keeping systems stable and reliable.

SPONSORED
Armbian Newsletter July 2026

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability so everyone can enjoy a solid foundation for their devices.

View the full article

]]>61223Wed, 29 Jul 2026 15:29:43 +0000[Armbian newsletter] - The factory behind Armbianhttps://testforum.armbian.com/topic/61221-armbian-newsletter-the-factory-behind-armbian/

When you download an Armbian image, flash it to your SD card or SSD, and boot your board, a huge amount of automation has already happened behind the scenes.
That invisible engine is what you can see at https://actions.armbian.com.

Think of it as the mission control center of Armbian’s infrastructure.

It doesn’t look flashy, but it represents one of the most important parts of the project: the system that builds, tests, validates, and maintains Armbian for hundreds of boards, kernels, and configurations.

Armbian isn’t just an operating system. It’s an automated production platform for embedded Linux.

What is actions.armbian.com?

actions.armbian.com is Armbian’s public automation dashboard. It shows the real-time status of the workflows that power the project:

  • Image builds
  • Infrastructure maintenance
  • Package and repository updates
  • Testing and validation
  • Data generation for tools and download pages

All of this is driven by GitHub Actions, running on Armbian’s own infrastructure and cloud runners.

In simple terms:

If Armbian were a factory, actions.armbian.com would be the live dashboard showing which machines are running, which are done, and which need attention.

Why does this matter to end users?

Even if you never write code, this system directly impacts you:

  • Reliability: Builds are reproducible and verified automatically
  • Fresh images: New kernels, fixes, and board support are rolled out faster
  • Stability: Failures are detected early, before broken images reach users
  • Scale: Armbian can support hundreds of boards without manual work

Without this automation, Armbian simply couldn’t exist in its current form.

What can you see on the site?

When you open actions.armbian.com, you’ll find:

  • A list of workflows and jobs
  • Their current state (success, failed, running)
  • Execution time and timestamps
  • Links to detailed logs and JSON outputs

This transparency is rare in open-source OS projects. You are literally watching Armbian being built in real time.

From code to your SD card

Here’s what typically happens behind the scenes:

  1. A developer updates code (kernel patches, board definitions, build scripts)
  2. A workflow starts automatically
  3. The system prepares a build environment
  4. Kernels and packages are compiled
  5. OS images are built
  6. Checks and validations are executed
  7. Results appear on actions.armbian.com
  8. If certain processes are green, images are published

This process runs thousands of times per month and is fully automated. From another perspective, our servers perform the equivalent of ten years of continuous compute time in a single calendar year.

Why Armbian needs this level of automation

Armbian is not a single OS for one device. It supports:

  • ARM, RISC-V, and x86
  • Dozens of SoCs
  • Hundreds of boards
  • Multiple kernels (legacy, current, edge)
  • Multiple Debian and Ubuntu releases

Manually maintaining this would be impossible. Action script behind is what makes Armbian scalable.

Not just builds – a full ecosystem

The automation system also handles:

  • Generation of download metadata
  • Repository synchronization
  • Mirror health checks
  • Infrastructure housekeeping
  • Statistics and reporting
  • Future tools like Armbian Imager integration

It is the backbone of Armbian’s modern platform approach.

Should users look at it?

Most users don’t need to.
But when something goes wrong, it becomes incredibly valuable:

  • Why is my board image missing?
  • Why did today’s build fail?
  • Is Armbian currently building new images?

The answers are often already visible there.

In short

actions.armbian.com is the heart of Armbian’s automation.

It represents:

  • Transparency
  • Quality control
  • Engineering discipline
  • And the reason Armbian can support such a massive hardware ecosystem

You may never interact with it directly, but every Armbian image you use was born there.

View the full article

]]>61221Wed, 29 Jul 2026 15:16:29 +0000[News from Armbian] - The factory behind Armbianhttps://testforum.armbian.com/topic/61219-news-from-armbian-the-factory-behind-armbian/

When you download an Armbian image, flash it to your SD card or SSD, and boot your board, a huge amount of automation has already happened behind the scenes.
That invisible engine is what you can see at https://actions.armbian.com.

Think of it as the mission control center of Armbian’s infrastructure.

It doesn’t look flashy, but it represents one of the most important parts of the project: the system that builds, tests, validates, and maintains Armbian for hundreds of boards, kernels, and configurations.

Armbian isn’t just an operating system. It’s an automated production platform for embedded Linux.

What is actions.armbian.com?

actions.armbian.com is Armbian’s public automation dashboard. It shows the real-time status of the workflows that power the project:

  • Image builds
  • Infrastructure maintenance
  • Package and repository updates
  • Testing and validation
  • Data generation for tools and download pages

All of this is driven by GitHub Actions, running on Armbian’s own infrastructure and cloud runners.

In simple terms:

If Armbian were a factory, actions.armbian.com would be the live dashboard showing which machines are running, which are done, and which need attention.

Why does this matter to end users?

Even if you never write code, this system directly impacts you:

  • Reliability: Builds are reproducible and verified automatically
  • Fresh images: New kernels, fixes, and board support are rolled out faster
  • Stability: Failures are detected early, before broken images reach users
  • Scale: Armbian can support hundreds of boards without manual work

Without this automation, Armbian simply couldn’t exist in its current form.

What can you see on the site?

When you open actions.armbian.com, you’ll find:

  • A list of workflows and jobs
  • Their current state (success, failed, running)
  • Execution time and timestamps
  • Links to detailed logs and JSON outputs

This transparency is rare in open-source OS projects. You are literally watching Armbian being built in real time.

From code to your SD card

Here’s what typically happens behind the scenes:

  1. A developer updates code (kernel patches, board definitions, build scripts)
  2. A workflow starts automatically
  3. The system prepares a build environment
  4. Kernels and packages are compiled
  5. OS images are built
  6. Checks and validations are executed
  7. Results appear on actions.armbian.com
  8. If certain processes are green, images are published

This process runs thousands of times per month and is fully automated. From another perspective, our servers perform the equivalent of ten years of continuous compute time in a single calendar year.

Why Armbian needs this level of automation

Armbian is not a single OS for one device. It supports:

  • ARM, RISC-V, and x86
  • Dozens of SoCs
  • Hundreds of boards
  • Multiple kernels (legacy, current, edge)
  • Multiple Debian and Ubuntu releases

Manually maintaining this would be impossible. Action script behind is what makes Armbian scalable.

Not just builds – a full ecosystem

The automation system also handles:

  • Generation of download metadata
  • Repository synchronization
  • Mirror health checks
  • Infrastructure housekeeping
  • Statistics and reporting
  • Future tools like Armbian Imager integration

It is the backbone of Armbian’s modern platform approach.

Should users look at it?

Most users don’t need to.
But when something goes wrong, it becomes incredibly valuable:

  • Why is my board image missing?
  • Why did today’s build fail?
  • Is Armbian currently building new images?

The answers are often already visible there.

In short

actions.armbian.com is the heart of Armbian’s automation.

It represents:

  • Transparency
  • Quality control
  • Engineering discipline
  • And the reason Armbian can support such a massive hardware ecosystem

You may never interact with it directly, but every Armbian image you use was born there.

View the full article

]]>61219Wed, 29 Jul 2026 15:16:29 +0000[Armbian newsletter] - Beat the heathttps://testforum.armbian.com/topic/61222-armbian-newsletter-beat-the-heat/Why thermal management is non-negotiable for modern SBCsBeat the heat

By Michael Robinson

As Western Europe endures severe summer conditions with climate monitors at the Copernicus Climate Change Service reporting unprecedented regional heatwaves and extreme highs stretching across the continent ambient indoor conditions are testing the limits of self-hosted edge hardware.

In unconditioned workspaces, home server racks, and industrial enclosures, rising ambient air temperatures erode the thermal headroom that single-board computers (SBCs) rely on. Modern System-on-Chips (SoCs) such as the Rockchip RK3588, Allwinner, and Broadcom platforms integrate high-performance CPUs, GPUs, and neural processing units on a single piece of silicon. When summer weather drives up ambient baselines, that extreme component density makes uncooled hardware uniquely vulnerable to severe throttling and instability.

Why ambient heat hits SBCs harder

Unlike desktop workstations equipped with liquid cooling loops or expansive fan arrays, small form-factor boards operate under strict physical constraints:

  • High component density: High-performance SoCs integrate the processor cores, graphics processing unit, memory controller, and power management IC onto a compact footprint.
  • Bare-board defaults: Most SBCs ship without pre-mounted thermal hardware, depending almost entirely on passive air movement around the bare board.
  • Eroded thermal headroom: Passive cooling relies on heat transferring from the warm chip into cooler surrounding air. As room temperatures climb during a heatwave, that temperature gap shrinks, causing the board's baseline resting temperature to rise right along with the room.

When workload demands push internal silicon temperatures past safety limits, the hardware triggers automatic protective mechanisms. The system governor scales down operating frequencies and voltages to protect the silicon from permanent damage a process known as thermal throttling.

Thermal throttling: The silent bottleneck

Thermal throttling rarely triggers explicit desktop warnings or system crashes. Instead, it degrades board behavior behind the scenes:

  • Degraded throughput: Code compilation, container builds, and database queries take significantly longer as clock speeds drop under sustained load.
  • Latency spikes and stutter: Frame drops occur during media playback, desktop rendering, or video stream processing.
  • System instability: Prolonged high-temperature operation can destabilize power delivery components, causing unexpected kernel panics or filesystem corruption.

When a self-hosted node or edge gateway exhibits sluggish performance on hot summer afternoons, reduced thermal headroom rather than a software bug is frequently the root cause.

Real-world impact: High-performance SoCs

Under sustained computational workloads, powerful SBCs like the Orange Pi 5 (powered by the Rockchip RK3588S SoC) clearly demonstrate the need for thermal dissipation hardware:

  • Without thermal protection: Operating as a bare board under full CPU or NPU load, the SoC quickly reaches its built-in thermal threshold, forcing steep frequency cuts within seconds.
  • With passive cooling: Mounting a finned aluminum heatsink provides the added surface area needed to dissipate heat into ambient air, helping the board sustain target frequencies through typical day-to-day tasks.
  • With active cooling: Adding forced airflow via a low-noise fan sweeps hot air clear of the heatsink fins, completely eliminating throttling even during multi-threaded stress testing or local AI workloads.

Choosing the right thermal strategy

  1. Passive radiative heatsinks: Extruded aluminum or copper blocks rely on natural air convection. They are silent and durable, making them ideal for headless servers provided the board isn't trapped in a sealed plastic case that acts as an insulator.
  2. Active cooling (heatsink + fan): Combining a heatsink with a dedicated fan uses forced air to clear heat buildup. This approach is recommended for heavy continuous workloads like video encoding, local machine learning models, or continuous software builds.
  3. Full-body aluminum enclosures: These designs turn the entire outer chassis into a heat sink, using internal thermal pads to transfer heat directly away from the SoC.

Mounting best practices

  • Always use thermal interface material (TIM): Microscopic air gaps between metal and silicon trap heat. Apply a thin thermal pad or an even layer of thermal paste to establish proper conductive contact.
  • Clean contact surfaces: Clear away oils or residue on the SoC die using high-purity isopropyl alcohol before mounting hardware.
  • Ensure even pressure: Verify that the heatsink sits flat and makes uniform contact across the top of the chip.
  • Cool secondary heat sources: Under heavy continuous operation, secondary components such as power management ICs (PMICs), system RAM, and NVMe drives also benefit from smaller passive heatsinks.

Conclusion

As seasonal temperature extremes become more common, proactive thermal management is essential for maintaining server stability and device longevity. Adding proper cooling hardware protects your single-board computers from silent performance bottlenecks and ensures reliable operation through summer heatwaves.

View the full article

]]>61222Wed, 29 Jul 2026 15:13:05 +0000[News from Armbian] - Beat the heathttps://testforum.armbian.com/topic/61220-news-from-armbian-beat-the-heat/Why thermal management is non-negotiable for modern SBCsBeat the heat

By Michael Robinson

As Western Europe endures severe summer conditions with climate monitors at the Copernicus Climate Change Service reporting unprecedented regional heatwaves and extreme highs stretching across the continent ambient indoor conditions are testing the limits of self-hosted edge hardware.

In unconditioned workspaces, home server racks, and industrial enclosures, rising ambient air temperatures erode the thermal headroom that single-board computers (SBCs) rely on. Modern System-on-Chips (SoCs) such as the Rockchip RK3588, Allwinner, and Broadcom platforms integrate high-performance CPUs, GPUs, and neural processing units on a single piece of silicon. When summer weather drives up ambient baselines, that extreme component density makes uncooled hardware uniquely vulnerable to severe throttling and instability.

Why ambient heat hits SBCs harder

Unlike desktop workstations equipped with liquid cooling loops or expansive fan arrays, small form-factor boards operate under strict physical constraints:

  • High component density: High-performance SoCs integrate the processor cores, graphics processing unit, memory controller, and power management IC onto a compact footprint.
  • Bare-board defaults: Most SBCs ship without pre-mounted thermal hardware, depending almost entirely on passive air movement around the bare board.
  • Eroded thermal headroom: Passive cooling relies on heat transferring from the warm chip into cooler surrounding air. As room temperatures climb during a heatwave, that temperature gap shrinks, causing the board's baseline resting temperature to rise right along with the room.

When workload demands push internal silicon temperatures past safety limits, the hardware triggers automatic protective mechanisms. The system governor scales down operating frequencies and voltages to protect the silicon from permanent damage a process known as thermal throttling.

Thermal throttling: The silent bottleneck

Thermal throttling rarely triggers explicit desktop warnings or system crashes. Instead, it degrades board behavior behind the scenes:

  • Degraded throughput: Code compilation, container builds, and database queries take significantly longer as clock speeds drop under sustained load.
  • Latency spikes and stutter: Frame drops occur during media playback, desktop rendering, or video stream processing.
  • System instability: Prolonged high-temperature operation can destabilize power delivery components, causing unexpected kernel panics or filesystem corruption.

When a self-hosted node or edge gateway exhibits sluggish performance on hot summer afternoons, reduced thermal headroom rather than a software bug is frequently the root cause.

Real-world impact: High-performance SoCs

Under sustained computational workloads, powerful SBCs like the Orange Pi 5 (powered by the Rockchip RK3588S SoC) clearly demonstrate the need for thermal dissipation hardware:

  • Without thermal protection: Operating as a bare board under full CPU or NPU load, the SoC quickly reaches its built-in thermal threshold, forcing steep frequency cuts within seconds.
  • With passive cooling: Mounting a finned aluminum heatsink provides the added surface area needed to dissipate heat into ambient air, helping the board sustain target frequencies through typical day-to-day tasks.
  • With active cooling: Adding forced airflow via a low-noise fan sweeps hot air clear of the heatsink fins, completely eliminating throttling even during multi-threaded stress testing or local AI workloads.

Choosing the right thermal strategy

  1. Passive radiative heatsinks: Extruded aluminum or copper blocks rely on natural air convection. They are silent and durable, making them ideal for headless servers provided the board isn't trapped in a sealed plastic case that acts as an insulator.
  2. Active cooling (heatsink + fan): Combining a heatsink with a dedicated fan uses forced air to clear heat buildup. This approach is recommended for heavy continuous workloads like video encoding, local machine learning models, or continuous software builds.
  3. Full-body aluminum enclosures: These designs turn the entire outer chassis into a heat sink, using internal thermal pads to transfer heat directly away from the SoC.

Mounting best practices

  • Always use thermal interface material (TIM): Microscopic air gaps between metal and silicon trap heat. Apply a thin thermal pad or an even layer of thermal paste to establish proper conductive contact.
  • Clean contact surfaces: Clear away oils or residue on the SoC die using high-purity isopropyl alcohol before mounting hardware.
  • Ensure even pressure: Verify that the heatsink sits flat and makes uniform contact across the top of the chip.
  • Cool secondary heat sources: Under heavy continuous operation, secondary components such as power management ICs (PMICs), system RAM, and NVMe drives also benefit from smaller passive heatsinks.

Conclusion

As seasonal temperature extremes become more common, proactive thermal management is essential for maintaining server stability and device longevity. Adding proper cooling hardware protects your single-board computers from silent performance bottlenecks and ensures reliable operation through summer heatwaves.

View the full article

]]>61220Wed, 29 Jul 2026 15:13:05 +0000[Collabora] - Cracking Windows Open: Porting RADV to WIN32https://testforum.armbian.com/topic/61206-collabora-cracking-windows-open-porting-radv-to-win32/View the full article

]]>61206Tue, 28 Jul 2026 14:50:59 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61205-armbian-newsletter-github-highlights/

This week's work centers on new board enablement and platform maintenance, kernel and U-Boot refresh across Rockchip and Sunxi, and CI/build infrastructure improvements.

Board support expanded with the addition of Sovol Zero, SV08, and SV08 Max on the H616 platform, alongside mainline and edge enablement for the Recomputer RK3576 devkit. BeagleY-AI features were forward-ported through kernel 7.2, the Mekotronics R58S2 gained rockusb recovery-key support, and the NanoPi R3S received an ethernet alias. Vendor logos and board imagery were also refreshed on the website.

On the kernel and bootloader side, the cix-p1 edge kernel moved to 7.1.5 with refreshed patches, meson64 dropped multiple upstreamed patches, and rk3328 DMC was repaired for newer kernels. U-Boot bumps landed for Rockpi-4A and EasePi-A2/R2 at v2026.07, rk35xx vendor patches were isolated from 2024.03 boards, and Rockchip vendor UFS support was corrected. Several BigTreeTech CB1 and sunxi issues were resolved, including WiFi power sequencing and PWM driver race conditions.

Infrastructure changes introduced a BTRFS_CHECKSUM build switch and a DOCKER_FORCE_PULL option, parallelized patch rewriting up to nproc, and raised the CI artifact build timeout from 60 to 120 minutes. Runner cleanup logic now installs and selects docker buildx by flavor, stable-track dispatch inputs were trimmed, and the AI README generator was made feedback-aware while forbidden from inventing paths.

#Armbian #EmbeddedLinux #Rockchip #Sunxi #UBoot #CI

Changes

View the full article

]]>61205Tue, 28 Jul 2026 01:16:05 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61204-news-from-armbian-github-highlights/

This week's work centers on new board enablement and platform maintenance, kernel and U-Boot refresh across Rockchip and Sunxi, and CI/build infrastructure improvements.

Board support expanded with the addition of Sovol Zero, SV08, and SV08 Max on the H616 platform, alongside mainline and edge enablement for the Recomputer RK3576 devkit. BeagleY-AI features were forward-ported through kernel 7.2, the Mekotronics R58S2 gained rockusb recovery-key support, and the NanoPi R3S received an ethernet alias. Vendor logos and board imagery were also refreshed on the website.

On the kernel and bootloader side, the cix-p1 edge kernel moved to 7.1.5 with refreshed patches, meson64 dropped multiple upstreamed patches, and rk3328 DMC was repaired for newer kernels. U-Boot bumps landed for Rockpi-4A and EasePi-A2/R2 at v2026.07, rk35xx vendor patches were isolated from 2024.03 boards, and Rockchip vendor UFS support was corrected. Several BigTreeTech CB1 and sunxi issues were resolved, including WiFi power sequencing and PWM driver race conditions.

Infrastructure changes introduced a BTRFS_CHECKSUM build switch and a DOCKER_FORCE_PULL option, parallelized patch rewriting up to nproc, and raised the CI artifact build timeout from 60 to 120 minutes. Runner cleanup logic now installs and selects docker buildx by flavor, stable-track dispatch inputs were trimmed, and the AI README generator was made feedback-aware while forbidden from inventing paths.

#Armbian #EmbeddedLinux #Rockchip #Sunxi #UBoot #CI

Changes

View the full article

]]>61204Tue, 28 Jul 2026 01:16:05 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/61085-armbian-newsletter-github-highlights/

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

Changes

View the full article

]]>61085Mon, 20 Jul 2026 16:56:55 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/61084-news-from-armbian-github-highlights/

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

Changes

View the full article

]]>61084Mon, 20 Jul 2026 16:56:55 +0000[Collabora] - Building an Arch Linux aarch64 port for Holo Corehttps://testforum.armbian.com/topic/61082-collabora-building-an-arch-linux-aarch64-port-for-holo-core/View the full article

]]>61082Fri, 17 Jul 2026 11:35:00 +0000[Collabora] - Weston 16: HDR-ready, improved debugging, and DRM backend featureshttps://testforum.armbian.com/topic/61038-collabora-weston-16-hdr-ready-improved-debugging-and-drm-backend-features/View the full article

]]>61038Thu, 16 Jul 2026 17:25:00 +0000[Collabora] - From Apertis to SBOMs: Debian development at DebConf 2026https://testforum.armbian.com/topic/60987-collabora-from-apertis-to-sboms-debian-development-at-debconf-2026/View the full article

]]>60987Mon, 13 Jul 2026 19:13:19 +0000[News from Armbian] - Github highlightshttps://testforum.armbian.com/topic/60980-news-from-armbian-github-highlights/

This week's updates center on expanded board support, Rockchip and Qualcomm platform maturation, and build system refinements.

New hardware coverage grew across multiple SoC families, with the Lubancat 5IO (RK3588), KickPi K3B, Mellow Fly C5 3D printer board, and community support for the Orange Pi Zero 3W (Allwinner A733). The Arduino UNO Q advanced to mainline 7.1 on the edge kernel and gained desktop hardware acceleration via Mesa pinned to Trixie backports, while the BeagleY-AI received ISP, IMX219, and VPAC patches. Companion fixes addressed NVMe/SD boot conflicts on the NanoPi M6, Ethernet on the BigTreeTech CB1, and AIC8800 UART Bluetooth on Orange Pi A733 hardware.

Rockchip work concentrated on the YY3588 and CM3588-NAS platforms, with device tree cleanups, a corrected HDMI-RX detect GPIO, and quieter DRM logging for dw-hdmi-qp and dw-dp bridges. Newer bl31, bl32, and DDR blobs landed for RK3576, and stale U-Boot was refreshed fleet-wide to resolve a SWIG build break. On the Qualcomm side, SC8280XP was refactored from a board to a family configuration, and the Radxa Dragon Q8B gained UFS image provisioning, QDL flashing support via the imager, and a mainline 7.1 edge target for the Q6A variant.

Build and tooling improvements included a new show-extensions CLI command, a switch from the adduser suite to useradd/groupadd during first login, non-interactive Dpkg conffile handling in chroot, and clang compatibility fixes for carried Rockchip64 patches and SpacemiT RTL8852BS builds. The mainline kernel target advanced to 7.2-rc2, and MGLRU was enabled across sunxi, sunxi64, and sun60iw2 kernel configurations.

#Armbian #EmbeddedLinux #Rockchip #Qualcomm #SBC

Changes

View the full article

]]>60980Mon, 13 Jul 2026 12:32:25 +0000[Armbian newsletter] - Github highlightshttps://testforum.armbian.com/topic/60979-armbian-newsletter-github-highlights/

This week's updates center on expanded board support, Rockchip and Qualcomm platform maturation, and build system refinements.

New hardware coverage grew across multiple SoC families, with the Lubancat 5IO (RK3588), KickPi K3B, Mellow Fly C5 3D printer board, and community support for the Orange Pi Zero 3W (Allwinner A733). The Arduino UNO Q advanced to mainline 7.1 on the edge kernel and gained desktop hardware acceleration via Mesa pinned to Trixie backports, while the BeagleY-AI received ISP, IMX219, and VPAC patches. Companion fixes addressed NVMe/SD boot conflicts on the NanoPi M6, Ethernet on the BigTreeTech CB1, and AIC8800 UART Bluetooth on Orange Pi A733 hardware.

Rockchip work concentrated on the YY3588 and CM3588-NAS platforms, with device tree cleanups, a corrected HDMI-RX detect GPIO, and quieter DRM logging for dw-hdmi-qp and dw-dp bridges. Newer bl31, bl32, and DDR blobs landed for RK3576, and stale U-Boot was refreshed fleet-wide to resolve a SWIG build break. On the Qualcomm side, SC8280XP was refactored from a board to a family configuration, and the Radxa Dragon Q8B gained UFS image provisioning, QDL flashing support via the imager, and a mainline 7.1 edge target for the Q6A variant.

Build and tooling improvements included a new show-extensions CLI command, a switch from the adduser suite to useradd/groupadd during first login, non-interactive Dpkg conffile handling in chroot, and clang compatibility fixes for carried Rockchip64 patches and SpacemiT RTL8852BS builds. The mainline kernel target advanced to 7.2-rc2, and MGLRU was enabled across sunxi, sunxi64, and sun60iw2 kernel configurations.

#Armbian #EmbeddedLinux #Rockchip #Qualcomm #SBC

Changes

View the full article

]]>60979Mon, 13 Jul 2026 12:32:25 +0000[Collabora] - The power of APIs: The unsung hero of AI interfacehttps://testforum.armbian.com/topic/60756-collabora-the-power-of-apis-the-unsung-hero-of-ai-interface/View the full article

]]>60756Tue, 07 Jul 2026 10:21:00 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/60720-news-from-armbian-github-highlights/

This week's cycle emphasizes broad U-Boot modernization, new board and SoC enablement, and kernel and wireless driver consolidation.

A large-scale U-Boot bump moves sunxi 32-bit and 64-bit targets from v2024.01 to v2026.07-rc4, with follow-on updates for self-pinned H616/H618 boards (Zero2W, Zero3, Longan Pi 3H), Mixtile Edge2, NanoPi R5S (now patch-less), and the Youyeetoo YY3588 switching to mainline v2026.04. The imx6 line (UDOO, Cubox-i) was modernized to U-Boot v2026.07 with legacy 6.12, current 6.18, and edge 7.1 kernels. Related toolchain work fixes ODROID-C1, ODROID-XU4, Recore, and X96Q builds under Trixie's GCC 14, and resolves errexit failures on Rockchip SPI boards.

Platform expansion introduces community support for the Allwinner A733-based Radxa Cubie A7Z and Orange Pi Zero 3W, Rockchip Graperain G3568 v2, and Anbernic RG Vita Pro and Lubancat-5IO image entries. BeagleY-AI gained USB, PCIe, ISP + IMX219, and VPAC patches on the vendor kernel, alongside GPU acceleration fixes for TI K3 targets and TI Wave5 VPU firmware. Rockchip RV1106 support was split into distinct RV1103G and RV1103B families, and new SPI/NVMe boot and Maskrom recovery paths were added.

On the kernel and driver side, sunxi received an H3/H5 DVFS RCU-stall fix, MMC/I2C PM deadlock resolution, MGLRU enablement, and LTE modem USB serial support. Meson64 gained a GPIO pinctrl cansleep series and v7.2-rc1 via bleedingedge, while SpacemiT K1 was updated to linux-7.2.y. The RTL8189ES, RTL8189FS, and RTL8192EU wireless drivers were migrated to dedicated forks with 7.2 compatibility and patch cleanup, and an RTW88 SDIO interrupt storm was addressed. User-visible improvements include swapfile creation fixes, useradd-based first-login provisioning, and video-group access to Rockchip MPP codec devices.

#Armbian #EmbeddedLinux #UBoot #Rockchip #Allwinner

Changes

View the full article

]]>60720Tue, 07 Jul 2026 04:20:02 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/60715-armbian-newsletter-github-highlights/

This week's cycle emphasizes broad U-Boot modernization, new board and SoC enablement, and kernel and wireless driver consolidation.

A large-scale U-Boot bump moves sunxi 32-bit and 64-bit targets from v2024.01 to v2026.07-rc4, with follow-on updates for self-pinned H616/H618 boards (Zero2W, Zero3, Longan Pi 3H), Mixtile Edge2, NanoPi R5S (now patch-less), and the Youyeetoo YY3588 switching to mainline v2026.04. The imx6 line (UDOO, Cubox-i) was modernized to U-Boot v2026.07 with legacy 6.12, current 6.18, and edge 7.1 kernels. Related toolchain work fixes ODROID-C1, ODROID-XU4, Recore, and X96Q builds under Trixie's GCC 14, and resolves errexit failures on Rockchip SPI boards.

Platform expansion introduces community support for the Allwinner A733-based Radxa Cubie A7Z and Orange Pi Zero 3W, Rockchip Graperain G3568 v2, and Anbernic RG Vita Pro and Lubancat-5IO image entries. BeagleY-AI gained USB, PCIe, ISP + IMX219, and VPAC patches on the vendor kernel, alongside GPU acceleration fixes for TI K3 targets and TI Wave5 VPU firmware. Rockchip RV1106 support was split into distinct RV1103G and RV1103B families, and new SPI/NVMe boot and Maskrom recovery paths were added.

On the kernel and driver side, sunxi received an H3/H5 DVFS RCU-stall fix, MMC/I2C PM deadlock resolution, MGLRU enablement, and LTE modem USB serial support. Meson64 gained a GPIO pinctrl cansleep series and v7.2-rc1 via bleedingedge, while SpacemiT K1 was updated to linux-7.2.y. The RTL8189ES, RTL8189FS, and RTL8192EU wireless drivers were migrated to dedicated forks with 7.2 compatibility and patch cleanup, and an RTW88 SDIO interrupt storm was addressed. User-visible improvements include swapfile creation fixes, useradd-based first-login provisioning, and video-group access to Rockchip MPP codec devices.

#Armbian #EmbeddedLinux #UBoot #Rockchip #Allwinner

Changes

View the full article

]]>60715Tue, 07 Jul 2026 04:20:02 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/60566-armbian-newsletter-github-highlights/

This week's work centers on a comprehensive CI pipeline overhaul, expanded board and SoC support, and notable U-Boot and kernel modernization across Rockchip platforms.

A substantial portion of the changes target CI infrastructure hardening in the new os-ci-test repository, including self-contained release handling, GHCR authentication via builtin tokens, watchdog-based auto-retry for stalled runs, proxy normalization, and sane build timeouts (60m packages, 30m/60m images). Related fixes in armbian/actions resolve datacenter runner proxy issues, while a rootfs change strips mmdebstrap's apt proxy from shipped images. Codeowners pruning of inactive maintainers and a Docker per-build image tag for parallel builds round out the developer-experience work.

On the platform side, new board and SoC enablement continues with cix-p1 support, Orange Pi 4 Pro (Allwinner A733) community files, and Radxa Dragon Q6A audio, Chromium, and libbpf fixes. RK3506 and RK3506B are now split with proper ROCKUSB_BLOB handling, and Helios4 gains dual-PWM fan control on 6.18. Kernel configurations enable ATH9K_HTC, NFS client across all three kernels, and REALTEK_PHY_HWMON on rockchip64, while an RK3588 I2S MCLK regression is corrected.

U-Boot modernization is broad: rk3308 boards (Rock Pi S, Rock S0) move from v2024.10 to v2026.07 with booti FDT fixes, Khadas VIM3 jumps to v2026.04, and VIM1/VIM2 receive khadas-uboot 0.17.3. The MediaTek Genio and NIO-12L platforms transition to pure mainline v7.1.y with loadaddr fixes for large kernels and initrds, and UEFI builds bump to v7.1 with Phytium dwmac rework.

#Armbian #EmbeddedLinux #Rockchip #UBoot #CI

Changes

View the full article

]]>60566Mon, 29 Jun 2026 22:06:51 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/60565-news-from-armbian-github-highlights/

This week's work centers on a comprehensive CI pipeline overhaul, expanded board and SoC support, and notable U-Boot and kernel modernization across Rockchip platforms.

A substantial portion of the changes target CI infrastructure hardening in the new os-ci-test repository, including self-contained release handling, GHCR authentication via builtin tokens, watchdog-based auto-retry for stalled runs, proxy normalization, and sane build timeouts (60m packages, 30m/60m images). Related fixes in armbian/actions resolve datacenter runner proxy issues, while a rootfs change strips mmdebstrap's apt proxy from shipped images. Codeowners pruning of inactive maintainers and a Docker per-build image tag for parallel builds round out the developer-experience work.

On the platform side, new board and SoC enablement continues with cix-p1 support, Orange Pi 4 Pro (Allwinner A733) community files, and Radxa Dragon Q6A audio, Chromium, and libbpf fixes. RK3506 and RK3506B are now split with proper ROCKUSB_BLOB handling, and Helios4 gains dual-PWM fan control on 6.18. Kernel configurations enable ATH9K_HTC, NFS client across all three kernels, and REALTEK_PHY_HWMON on rockchip64, while an RK3588 I2S MCLK regression is corrected.

U-Boot modernization is broad: rk3308 boards (Rock Pi S, Rock S0) move from v2024.10 to v2026.07 with booti FDT fixes, Khadas VIM3 jumps to v2026.04, and VIM1/VIM2 receive khadas-uboot 0.17.3. The MediaTek Genio and NIO-12L platforms transition to pure mainline v7.1.y with loadaddr fixes for large kernels and initrds, and UEFI builds bump to v7.1 with Phytium dwmac rework.

#Armbian #EmbeddedLinux #Rockchip #UBoot #CI

Changes

View the full article

]]>60565Mon, 29 Jun 2026 22:06:51 +0000[Collabora] - Kraid: A new compiler for Panfrosthttps://testforum.armbian.com/topic/60495-collabora-kraid-a-new-compiler-for-panfrost/Panfrost that replaces the aging Bifrost-rooted compiler stack with a cleaner, more flexible design for modern Mali GPUs, improving IR structure, register allocation, hardware testing, and long-term maintainability.

View the full article

]]>60495Thu, 25 Jun 2026 17:17:23 +0000[News from Armbian] - Armbian Newsletterhttps://testforum.armbian.com/topic/60478-news-from-armbian-armbian-newsletter/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

This week: the desktop installer in armbian-config has been rebuilt from the ground up tiered installs, clean uninstalls, and snap-free native browsers across all architectures. Armbian Imager 2.0 is out, rewritten interface and flashing engine, with boards that boot already configured (username, Wi-Fi, timezone) and byte-for-byte write verification. And the NanoPi M5 becomes the first RK3576 board to boot end-to-end from UFS on mainline U-Boot, with no proprietary image in the loop.

SPONSORED
Armbian Newsletter

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.

Armbian Newsletter
Armbian Newsletter
Armbian Newsletter
Armbian Newsletter

View the full article

]]>60478Wed, 24 Jun 2026 15:19:41 +0000[Armbian newsletter] - Armbian Newsletterhttps://testforum.armbian.com/topic/60476-armbian-newsletter-armbian-newsletter/

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

This week: the desktop installer in armbian-config has been rebuilt from the ground up tiered installs, clean uninstalls, and snap-free native browsers across all architectures. Armbian Imager 2.0 is out, rewritten interface and flashing engine, with boards that boot already configured (username, Wi-Fi, timezone) and byte-for-byte write verification. And the NanoPi M5 becomes the first RK3576 board to boot end-to-end from UFS on mainline U-Boot, with no proprietary image in the loop.

SPONSORED
Armbian Newsletter

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.

Github Highlights
This week’s work centers on board portfolio expansion, kernel and U-Boot version bumps, and CI and infrastructure hardening across the build and documentation pipelines. Board support saw notable growth with the introduction of the SpacemiT K3 Pico-ITX and Luckfox Nova (RK3308B), alongside a new generic uefi-arm64-dt family and board intended
Armbian NewsletterArmbian blogMichael Robinson
Armbian Newsletter
Native UFS boot lands on the NanoPi M5
Armbian’s next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage class
Armbian NewsletterArmbian blogDaniele Briguglio
Armbian Newsletter
Meet our new Armbian Imager 2.0
We’re releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you’ll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up
Armbian NewsletterArmbian blogDaniele Briguglio
Armbian Newsletter
We rewrote how Armbian installs desktops. Here’s what changed
A friendlier, faster, snap-free desktop install in armbian-config If you’ve installed a desktop environment with armbian-config over the last few months, you may have noticed things feel different: there’s a tier you can pick, the browser actually works on every arch, uninstall doesn’t take half your system with it, and
Armbian NewsletterArmbian blogIgor Pecovnik
Armbian Newsletter

View the full article

]]>60476Wed, 24 Jun 2026 15:19:41 +0000[Armbian newsletter] - Github Highlightshttps://testforum.armbian.com/topic/60477-armbian-newsletter-github-highlights/

This week's work centers on board portfolio expansion, kernel and U-Boot version bumps, and CI and infrastructure hardening across the build and documentation pipelines.

Board support saw notable growth with the introduction of the SpacemiT K3 Pico-ITX and Luckfox Nova (RK3308B), alongside a new generic uefi-arm64-dt family and board intended to standardize UEFI device-tree targets. Qualcomm enablement advanced through Radxa Dragon Q6A and Q8B work, including UFS provisioning for Kodiak, EDL-based UFS flashing in the imager, and audioreach topology firmware for sc8280xp. Catalog assets were extended for the MaaXBoard 8ULP, Mellow Fly C5, Xiaomi Sheng, and the new Radxa and SpacemiT boards.

On the kernel and bootloader front, rockchip64, meson64, and rpi4b edge branches were promoted to the stable 7.1 series, with the rtl8192eu driver rebuilt and re-enabled against the new tree. U-Boot was refreshed on cm3588-nas, nanopik2-s905, and the Luckfox Nova, while updated DDR, BL31, and BL32 blobs landed for RK3528 and new SPL loaders were published for RV1103, RV1106, and RK3506. Targeted kernel-config work restored md/RAID modules on sunxi, enabled MIPI DBI panels on sunxi64, and added CPUFreq support for the SpacemiT K1.

Infrastructure changes focused on resilience and resource control. The git-trees workflow gained bounded retries, escalating timeouts, and Google mirror fallbacks; Docker base-image pulls now retry transient GHCR failures and split host dependencies into per-group apt layers. Image compression caps xz memory and thread usage, the info-gatherer no longer exhausts file descriptors, and a new CI policy enforces transparent backgrounds and object-size limits for board and vendor logos, with offending assets re-cropped.

#Armbian #EmbeddedLinux #UBoot #Qualcomm #Rockchip

Changes

View the full article

]]>60477Wed, 24 Jun 2026 14:33:01 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/60475-news-from-armbian-github-highlights/

This week's work centers on board portfolio expansion, kernel and U-Boot version bumps, and CI and infrastructure hardening across the build and documentation pipelines.

Board support saw notable growth with the introduction of the SpacemiT K3 Pico-ITX and Luckfox Nova (RK3308B), alongside a new generic uefi-arm64-dt family and board intended to standardize UEFI device-tree targets. Qualcomm enablement advanced through Radxa Dragon Q6A and Q8B work, including UFS provisioning for Kodiak, EDL-based UFS flashing in the imager, and audioreach topology firmware for sc8280xp. Catalog assets were extended for the MaaXBoard 8ULP, Mellow Fly C5, Xiaomi Sheng, and the new Radxa and SpacemiT boards.

On the kernel and bootloader front, rockchip64, meson64, and rpi4b edge branches were promoted to the stable 7.1 series, with the rtl8192eu driver rebuilt and re-enabled against the new tree. U-Boot was refreshed on cm3588-nas, nanopik2-s905, and the Luckfox Nova, while updated DDR, BL31, and BL32 blobs landed for RK3528 and new SPL loaders were published for RV1103, RV1106, and RK3506. Targeted kernel-config work restored md/RAID modules on sunxi, enabled MIPI DBI panels on sunxi64, and added CPUFreq support for the SpacemiT K1.

Infrastructure changes focused on resilience and resource control. The git-trees workflow gained bounded retries, escalating timeouts, and Google mirror fallbacks; Docker base-image pulls now retry transient GHCR failures and split host dependencies into per-group apt layers. Image compression caps xz memory and thread usage, the info-gatherer no longer exhausts file descriptors, and a new CI policy enforces transparent backgrounds and object-size limits for board and vendor logos, with offending assets re-cropped.

#Armbian #EmbeddedLinux #UBoot #Qualcomm #Rockchip

Changes

View the full article

]]>60475Wed, 24 Jun 2026 14:33:01 +0000[News from Armbian] - Github Highlightshttps://testforum.armbian.com/topic/60452-news-from-armbian-github-highlights/

This week's work centers on board portfolio expansion, kernel and U-Boot version bumps, and CI and infrastructure hardening across the build and documentation pipelines.

Board support saw notable growth with the introduction of the SpacemiT K3 Pico-ITX and Luckfox Nova (RK3308B), alongside a new generic uefi-arm64-dt family and board intended to standardize UEFI device-tree targets. Qualcomm enablement advanced through Radxa Dragon Q6A and Q8B work, including UFS provisioning for Kodiak, EDL-based UFS flashing in the imager, and audioreach topology firmware for sc8280xp. Catalog assets were extended for the MaaXBoard 8ULP, Mellow Fly C5, Xiaomi Sheng, and the new Radxa and SpacemiT boards.

On the kernel and bootloader front, rockchip64, meson64, and rpi4b edge branches were promoted to the stable 7.1 series, with the rtl8192eu driver rebuilt and re-enabled against the new tree. U-Boot was refreshed on cm3588-nas, nanopik2-s905, and the Luckfox Nova, while updated DDR, BL31, and BL32 blobs landed for RK3528 and new SPL loaders were published for RV1103, RV1106, and RK3506. Targeted kernel-config work restored md/RAID modules on sunxi, enabled MIPI DBI panels on sunxi64, and added CPUFreq support for the SpacemiT K1.

Infrastructure changes focused on resilience and resource control. The git-trees workflow gained bounded retries, escalating timeouts, and Google mirror fallbacks; Docker base-image pulls now retry transient GHCR failures and split host dependencies into per-group apt layers. Image compression caps xz memory and thread usage, the info-gatherer no longer exhausts file descriptors, and a new CI policy enforces transparent backgrounds and object-size limits for board and vendor logos, with offending assets re-cropped.

#Armbian #EmbeddedLinux #UBoot #Qualcomm #Rockchip

Changes

View the full article

]]>60452Mon, 22 Jun 2026 14:26:51 +0000