https://testforum.armbian.com/rss/2-armbian-topics.xml/New topicsenWireless-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 articleSun, 11 Oct 2026 11:36:22 +0000M5Stack 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 articleSat, 10 Oct 2026 07:00:45 +0000Developed 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 articleFri, 09 Oct 2026 12:00:44 +0000After installing Armbian_community_26.11.0-trunk.62_Orangepiplus_trixie_current_6.18.54_minimal.img.xz on the Orange Pi PC Plus, the USB keyboard does not work.Fri, 09 Oct 2026 09:40:53 +0000I have a recently commissioned Radxa Rock-5B that I use as my PXE host. It has a number of iso images that are loopback mounted on directories like /var/www/html/mirrors/Fedora-44. I recently attempted an install of Fedora 44 on a VM and it crashed, complaining that it was unable to download a package from /var/www/html/mirrors/Fedora-44/Packages/p/parted-3.6-14.fc44.x86_64.rpm. I checked the directory on the Rock-5B and it was indeed missing but it was also giving me a lot of output that looked like -r--r--r-- 1 root root 264876 Feb 2 2026 policycoreutils-3.10-1.fc44.x86_64.rpm ?????????? ? ? ? ? ? policycoreutils-newrole-3.10-1.fc44.x86_64.rpm all files from here are the same ??? I checked the sha256sum of the Fedora 44 iso against the one published on the website and it matches. I renamed the file and downloaded a fresh copy, just in case, same size, same sha256sum, same errors. I rebooted the Rock-5B to see if it was a transient problem but it was still broken on reboot. I copied the iso file to a different system running an older kernel and mounted it there and the content was correct and there were no errors and more importantly the parted-3.6 rpm file it complained about was present. I removed linux-image-bleedingedge-rockchip64 and rebooted into Linux rock-5b 6.18.53-current-rockchip64 and the problem was gone. It seems something about loopback mounting iso images is broken in 7.3.0-rc4. I have not tried a more recent bleedingedge version yet.Fri, 09 Oct 2026 06:11:30 +0000Fri, 09 Oct 2026 05:01:42 +0000Sipeed 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 articleThu, 08 Oct 2026 17:01:38 +0000When flashing the Armbian image for the Odin 2 Portal to the SD card and attempting to boot (on ROCKNIX ABL v1.2), the ABL can detect the SD card but does not detect the OS at all. This is on the latest version of the OS, with the GNOME/ubuntu image flashed via the official Armbian Imager. When will this be fixed? (image not uploaded as it kept throwing errors)Thu, 08 Oct 2026 16:15:25 +0000ZeroWire 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 articleThu, 08 Oct 2026 09:00:08 +0000While doing some testing of multiple things I decided to build 2 images, fresh/new for my nanopineo's also trying to have the resulting image as close as possible to what I have running on the nanopineo's for years since 2022 or so. That was originally Armbian Buster and I have been tweaking the installations to match other computer installations. Main thing is split the root partitions into a rootfs (Btrfs) and a bootfs (Ext4). More recently, I did more changes, such that I can run the whole image as KVM and/or systemd-nspawn container. The 1st image was adding extension 'u-boot-menu'; build ended in success, but have not tested it on HW. I saw in extlinux.conf that there was no 'FDT' line (with sun8i-h3-nanopi-neo.dtb), which I did ad myself in own extlinux testting/semi-automatic .conf generation, but as BOARD=nanopineo, the U-Boot can know a default to be loaded, or nothing at all as the DT in the U-Boot is likely good enough or almost the same as th eone from kernel, but maybe I test/challenge that later. The 2nd image build was just 'u-boot-menu' replaced by 'grub-with-dtb': cd /local/s0/armbuild/ sudo btrfs subvolume create nanopineo sudo chown 1000:1000 nanopineo cd nanopineo git clone https://github.com/armbian/build cd build ./compile.sh \ BOARD=nanopineo \ RELEASE=trixie \ BRANCH=edge \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ NETWORKING_STACK=systemd-networkd \ FIXED_IMAGE_SIZE=2G \ IMAGE_PARTITION_TABLE=gpt \ BOOTPART_REQUIRED=yes \ BOOTSIZE=256 \ BOOTFS_TYPE=fat \ ROOTFS_TYPE=btrfs \ BTRFS_COMPRESSION=zstd \ COMPRESS_OUTPUTIMAGE=sha \ EXTRAWIFI=no \ KERNEL_CONFIGURE=no \ KERNEL_BTF=no \ KERNEL_GIT=shallow \ ENABLE_EXTENSIONS=watchdog,net-systemd-networkd,uboot-btrfs,grub-with-dtb It then fails with: [🔨] E: Unable to locate package grub-efi-armhf-bin [🔨] E: Unable to locate package grub-efi-armhf The issue here is that the Debian package must be: grub-efi-arm Also I now remember an issue from years ago when I made a non-EFI system UEFI bootable, must have been RPi thing or so, but also did it several times for x86. AFAIR if only grub-efi-arm and grub-efi-arm-bin, you get into trouble later on, can be years later when dist-upgrading in-place. So I just do 'apt install grub-efi' which then works fine as is pulls in also some dependencies. Not 'efibootmgr', that is just recommended, and I add that manually as most systems allow storing boot URL's in SPI-flash or so, certainly the KVM ones where machine is using EDK2 UEFI, which I use extensively. So it seems to me that this is an architecture naming or aliasing issue, like we have amd64 vs. x86-64 vs. x86_64 and arm64 vs. aarch64 If just 'grub-efi' that also works for riscv I guess, so avoiding this naming/aliasing issue and also better future proof. It might be that dependencies are not supported in image building, I don't know enough about that to judge. I have also not looked in detail at size impact, but it is relative I would say. There is plenty of other issues that claim more space or can reduce way more. There were more issues, but I solved those via trial-error, no show-stoppers. Although topic tag NanoPi-NEO, this is more like an Armbian Build issue, but for me it is about my 5 NanoPi-NEO's that are still great (and still overkill for their 4x Cortex-A7), but they are still Debian 32-bit ARMv7, not like unsupported RPi0/1 single-core ARMv6 (arm11* or older). A reason for wanting EFI bootloader is that upgrading/testing can by done in a KVM running on RPi4 (fast USB3-SSD) or ROCK3A (fast PCI-Ev3x2 NVMe) while using (differential) btrfs send|receive, which is way faster than on SD-cards en real HW. The other option is via U-Boot (QEMU -enable-kvm option), is supported for 64-bit in Armbian by BOARD=qemu-uboot-arm64, not for 32-bit.Thu, 08 Oct 2026 08:58:31 +0000Edge kernel 7.3.0-rc6 Makes board unstable [ 1173.843180] rockchip-dw-pcie 3c0800000.pcie: PCIe Gen.3 x2 link up [ 1173.971258] pcieport 0002:20:00.0: Root Port has been reset [ 1173.971328] nvme nvme0: restart after slot reset [ 1173.982877] nvme nvme0: D3 entry latency set to 8 seconds [ 1173.994210] nvme nvme0: 4/0/0 default/read/poll queues [ 1173.994642] pcieport 0002:20:00.0: AER: device recovery successful [ 1173.994719] pcieport 0002:20:00.0: Recovering Root Port due to Link Down [ 1173.994761] nvme nvme0: frozen state error detected, reset controller [ 1174.028524] phy phy-fe8c0000.phy.7: lane number 0, val 1 [ 1174.343104] rockchip-dw-pcie 3c0800000.pcie: PCIe Gen.3 x2 link up [ 1174.471131] pcieport 0002:20:00.0: Root Port has been reset [ 1174.471191] nvme nvme0: restart after slot reset [ 1174.486326] nvme nvme0: D3 entry latency set to 8 seconds [ 1174.496045] nvme nvme0: 4/0/0 default/read/poll queues [ 1174.496250] pcieport 0002:20:00.0: AER: device recovery successful [ 1174.496284] pcieport 0002:20:00.0: Recovering Root Port due to Link Down [ 1174.496303] nvme nvme0: frozen state error detected, reset controller Please test rc in bleeding-edge before making it available on edge Thanks !Thu, 08 Oct 2026 02:01:04 +0000Efinix 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 articleThu, 08 Oct 2026 00:00:32 +0000DSPi 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 articleWed, 07 Oct 2026 09:00:08 +0000Nuvoton 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 articleWed, 07 Oct 2026 00:00:19 +0000Tue, 06 Oct 2026 22:28:15 +0000A look at the USB-PD, PHY, hotplug, and DRM changes involved in making USB-C DisplayPort Alternate Mode work on RK3588/RK3576, and where they stand on the way to mainline Linux. View the full articleTue, 06 Oct 2026 20:32:03 +0000Tue, 06 Oct 2026 16:15:36 +0000Tue, 06 Oct 2026 12:59:29 +0000Tue, 06 Oct 2026 12:59:29 +0000The 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 articleTue, 06 Oct 2026 09:00:22 +0000The 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 articleTue, 06 Oct 2026 01:00:26 +0000For many Years I was using a wlan SSID containing a backslash with no problems. While trying the current Armbian_community_26.11.0-trunk.62_Bananapim2plus_trixie_current_6.18.54_minimal.img.xz the network wlan0 would not connect. Connecting to the guest wlan of the same router worked. I could trace it to the backslash in the SSID which "netplan try" complained about. Escaping that with a additional backslash made "netplan try" accept it, but the connection did not work, the interface wlan0 remained in status "state DOWN". Changing the SSID (removing that single backslash) made it working. I did not find something that prohibits the backslash used in the name of the SSID, so I'm unsure.Mon, 05 Oct 2026 18:43:11 +0000The 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 articleMon, 05 Oct 2026 09:00:49 +0000Hi everyone, I’m sharing an engineering paper about getting a PP-OCRv6-based RapidOCR pipeline running on the Orange Pi Zero 3W’s Allwinner A733 / Vivante VIP9000 NPU, integrated into Visual AI. Full paper: https://github.com/sog777/orange-pi-zero-3w-rapidocr-npu The tests used the Orange Pi Debian 12 Bookworm image and its vendor NPU stack, not Armbian. This is an engineering case study, not an Armbian support request or a claim that the same binaries work on an Armbian image. The paper covers the ONNX → ACUITY → NBG → VIPLite conversion path, static model shapes, targeted convolution and LayerNorm graph rewrites, quantization, simulator-versus-hardware checks, and physical-board validation. The selected system remains hybrid: text detection and eligible recognition attempts run on the NPU, while canonical ONNX Runtime CPU recognition checks every crop and supplies the final text and confidence scores. Wide lines, orientation classification, preprocessing, and post-processing also use CPU execution. A repeated reference recognizer test passed 100 runs, with a median call of 13.36 ms. A CPU-verified 18-line page took approximately 1.64–1.66 seconds, including 18 NPU recognition attempts and 18 CPU checks. These are different benchmark scopes; reference agreement does not establish perfect transcription, and no matched CPU-only speed advantage has been established. The paper also describes higher-resolution tiled detection and rejected full-NPU experiments. One candidate reduced aggregate CPU consumption by approximately 77.65%, but increased processing time by approximately 79.34% and regressed accuracy, so it was not promoted. I’m posting this for SBC developers interested in the practical limits of accelerator conversion and validation. This is a paper-only publication, without commands, a source-code release, or model downloads. Feedback on the methodology is welcome.Mon, 05 Oct 2026 01:15:52 +0000Geekworm, 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 articleMon, 05 Oct 2026 00:00:22 +0000We 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 articleSun, 04 Oct 2026 03:00:42 +0000Well Well, Who's The Asshole Now? Yeah I Need a Job... I'm not too bad. Written for: the same readers as the finding, maintainers and users; the chart is built to be attached to it or to stand alone in a forum post. Ours versus theirs, same board, same 100-minute 4K 10-bit title, same afternoon, same kernel journal: frames out of 143,641decoder resetsspeed theirs, jellyfin-ffmpeg 8.1.3-1 with its bundled fork MPP100,13111,520~120 fps until it broke at 42:11 ours, system ffmpeg → rockchip-vaapi → upstream-lineage MPP143,6410106 fps, intact to the end The chart shows it in one glance: nothing missing anywhere for either until minute 40, then orange bars at 50 to 60 percent loss for the remaining hour, green flat on zero the whole way. The speed difference is the honest cost of the guard, one decode task at a time instead of two, and it's the throughput the revert was presumably chasing. Where everything is: claude-pi-handoffs/20261002/FINDING-jellyfin-mpp-vp9-10bit-frame-loss.md, now with the fourth row, the throughput note and the chart reference. ours-vs-theirs.png beside it, 1600×900, ready to attach. after-gaps-sheet.png in the evidence folder if anyone asks what the surviving frames look like. The evidence folder holds every log, both journal counts, the gap analysis, the test scripts and the rating with three addenda. One disclosure kept in the document rather than buried: ours printed two MPP buffer-slot assertion lines at teardown, after the last frame, with no effect on output. Better that you say it than someone else finds it. The output file and the source title are still on the test board under ~/probe if you want to watch the freezes before posting. Nothing else is running; the package is complete. NO SLOP!Sun, 04 Oct 2026 02:13:02 +0000For the vendor-rk35xx kernel (6.1.115): an out-of-tree build of the vendor imx415 driver with a real 4K@60 mode, plus the overlay to bind it. https://github.com/bambooCZ/rk3588-imx415-4k60Sun, 04 Oct 2026 00:05:06 +0000Sat, 03 Oct 2026 18:30:36 +0000Hello, 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 articleSat, 03 Oct 2026 03:00:36 +0000Next week we'll be in Prague for a packed Open Source week! We’ll speak at the Linux Plumbers Conference and GStreamer Conference, and present two demos at the ELC Technical Showcase. View the full articleFri, 02 Oct 2026 21:01:33 +0000AAEON 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 articleFri, 02 Oct 2026 09:00:53 +0000Avaota 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 articleFri, 02 Oct 2026 02:00:37 +0000ASRock 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 articleFri, 02 Oct 2026 00:00:32 +0000Hi everybody With freshly installed armbian (commit id: d9fb61be0) I created a new uboot config file: ./compile.sh uboot-config BOARD=orangepizeroplus BRANCH=current SHARE_LOG=yes This creates the file: ./output/defconfig-uboot-orangepizeroplus-current But the command: ./compile.sh uboot BOARD=orangepizeroplus BRANCH=current SHARE_LOG=yes does not compile uboot, it just touches ./output/debs/linux-u-boot-orangepizeroplus-current_26.11.0-trunk_arm64__2026.07-*.deb file. Do I miss something? Do I have to copy the file ./output/defconfig-uboot-orangepizeroplus-current to a place in ./userpatches? Thanks in advance, Hackbeere log-uboot-config-f8ff6bc1-9053-44de-932f-fc933aa65f54.log log-uboot-289bad48-a6fa-43df-9b92-ac809bac3c2d.logThu, 01 Oct 2026 16:36:32 +0000LakeShark 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 articleThu, 01 Oct 2026 09:00:28 +0000The system v26.11 rolling for Orange Pi PC Plus running Armbian Linux 6.18.53-current-sunxi cannot boot from eMMC on the Orange Pi PC Plus. The bootloader is looking for an old partition on /dev/mmcblk0p1, whereas the current partition of emmc is identified differently - as /dev/mmcblk2p1. Therefore, it is necessary to use a bootloader from an SD card, which specifies the path to the eMMC partition for subsequent operation.Thu, 01 Oct 2026 08:03:34 +0000Raspberry 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 articleThu, 01 Oct 2026 00:00:53 +0000Welcome 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 CIJetHome (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 × 1Sponsored Github HighlightsThis 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 nightArmbian 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 thatMali GPU with LiteRT-LMRunning 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, 8View the full articleWed, 30 Sep 2026 18:40:54 +0000Welcome 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 CIJetHome (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 × 1Sponsored Github HighlightsThis 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 nightArmbian 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 thatMali GPU with LiteRT-LMRunning 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, 8View the full articleWed, 30 Sep 2026 18:40:54 +0000Hello, i've installed the latest vendor version for Radxa ROCK 5 ITX. When I want to change settings, the password entry pop-up appears briefly and immediately disappears again, preventing the settings from being saved. I performed a completely fresh installation of the computer, and the problem still occurs. What is causing this? Any help would be appreciated. Best regards AlbrechtWed, 30 Sep 2026 18:30:27 +0000Armbian 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 rackFleet 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 takesPer 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 doesThe 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. Power on The fleet is brought up from the PDU and the boards are given several minutes to boot.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.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.Run the board pipeline A matrix job per board, in parallel across the runners. This is the part below.Scan again Post-test state is captured; what the run left behind, not just what it reported.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 doesupgradePoint 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 Current results are published publicly at docs.armbian.com/status/board-tests, refreshed as runs complete. What it actually catchesHere are few examples from recent runs. Reboots that hang on both kernelsOne 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 x86The 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 runnerSelf-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 fitsAnd 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 pointAI 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 timeThe 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. SelectionA 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. ArtifactsA 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 budgetA 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. RecoveryThis 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 qualityA 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. HelpingInfrastructure, 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 articleWed, 30 Sep 2026 18:29:14 +0000Armbian 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 rackFleet 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 takesPer 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 doesThe 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. Power on The fleet is brought up from the PDU and the boards are given several minutes to boot.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.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.Run the board pipeline A matrix job per board, in parallel across the runners. This is the part below.Scan again Post-test state is captured; what the run left behind, not just what it reported.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 doesupgradePoint 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 Current results are published publicly at docs.armbian.com/status/board-tests, refreshed as runs complete. What it actually catchesHere are few examples from recent runs. Reboots that hang on both kernelsOne 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 x86The 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 runnerSelf-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 fitsAnd 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 pointAI 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 timeThe 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. SelectionA 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. ArtifactsA 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 budgetA 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. RecoveryThis 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 qualityA 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. HelpingInfrastructure, 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 articleWed, 30 Sep 2026 18:29:14 +0000JetHome (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 today18 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 articleWed, 30 Sep 2026 15:26:59 +0000JetHome (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 today18 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 articleWed, 30 Sep 2026 15:26:59 +0000Wed, 30 Sep 2026 15:24:54 +0000Wed, 30 Sep 2026 15:24:54 +0000Tokyo-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 articleWed, 30 Sep 2026 09:00:23 +0000We’ll be in Frankfurt this Thursday for the AMD Embedded Computing Summit! See a live demo of our AI Magic Mirror for a touchless, real-time experience. View the full articleTue, 29 Sep 2026 20:39:18 +0000The new Orange Pi 4 Pro image connects to Bluetooth keyboards perfectly, but typing doesn't work because uinput is completely missing from the 6.6.98-vendor-sun60iw2 kernel config.Mon, 28 Sep 2026 17:43:12 +0000