RSS Bot

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

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

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

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

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

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

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

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

A 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 article

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 ChangesActions: Fix noble dkms, add to test matrix. by @vidplace7 in armbian/MorseMicro-DKMS#18Actions: Use numbered distro release in deb version. by @vidplace7 in armbian/MorseMicro-DKMS#19aml-c400-plus: repack blob; u-boot: env-in-mmc; +fancy-ish (<1MiB bl33). by @rpardini in armbian/build#10907aml-c400-plus: u-boot: fix u-boot.ext (bare bl33 for chainloading/toothpick). by @rpardini in armbian/build#10918anbernic-rg-ds: MBR image, fix battery charging, rumble at power-on. by @crackerjacques in armbian/build#10900anbernic-rg-vita-pro: MBR image, rumble at power-on. by @crackerjacques in armbian/build#10901apt: wait on lock + clear stale cache lock (fix "held by process 0"). by @igorpecovnik in armbian/build#10893armbian-firstlogin: allow underscore and hyphen in usernames. by @xsalaices in armbian/build#10844armbian-firstlogin: don't block an unattended preset run on questions. by @igorpecovnik in armbian/build#10840armbian-kernel: enable SMB/CIFS client and ksmbd on all kernels. by @igorpecovnik in armbian/build#10885Armbianmonitor refactor. by @EvilOlaf in armbian/build#9327autoconfig: document unattended first login and static IP scope. by @igorpecovnik in armbian/documentation#1419ayn-odin3: Migrate kernel to Linux 7.2. by @kasimling in armbian/build#10690bcm2711: always use official raspberrypi/firmware for start4.elf (and co). by @rpardini in armbian/build#10855bcm2711: don't enable a second serial getty on the Raspberry Pi UART. by @igorpecovnik in armbian/build#10848board-images: add KickPi K2B V2.2 board image. by @Novice-PG in armbian/armbian.github.io#478board-vendor-logos: add 9tripod logo. by @igorpecovnik in armbian/armbian.github.io#477board: add Toradex Verdin iMX8M Mini (board+vendor). by @lucshl in armbian/armbian.github.io#475board: bananapicm4io: blacklist out-of-tree 88x2cs wifi driver. by @igorpecovnik in armbian/build#10872board: mixtile-blade3: use rk3588-mixtile-blade3.dtb on the vendor branch. by @evtest-hash in armbian/build#10774boards: add Toradex Verdin iMX8M Mini support. by @lucshl in armbian/build#10867boards: aml-c400-plus: stabilize Mali-T820 by pinning runtime-PM on probe and reset. by @jomadeto in armbian/build#10797BPI-M4-Zero: Adjust LPDDR4 timings and AXP313 regulators. by @pyavitz in armbian/build#10873BPI-M4-Zero: Optimize mmc1 DT properties for fast SDIO initialization. by @pyavitz in armbian/build#10880BPI-M4-Zero: U-Boot: Drop HACK: sunxi: gpu enable. by @pyavitz in armbian/build#10881bring USERPATCHES_PATH back into working state and fix inconsistencies. by @EvilOlaf in armbian/build#10776bsp: refresh the release checksum after version changes. by @khaliforce in armbian/build#10909build-framework: document OCI storage and OCI_PROXY. by @igorpecovnik in armbian/documentation#1445bump rockchip armhf edge kernel to 7.3. by @paolosabatino in armbian/build#10864cache services: publish on the host and local containers only by default. by @igorpecovnik in armbian/configng#1043chunk workflows: export the runner's oci_cache as OCI_PROXY. by @igorpecovnik in armbian/ci#83ci: expand kernel defconfigs before the security check. by @igorpecovnik in armbian/build#10897contribute/datacenter: add infra repo screenshot to gallery. by @igorpecovnik in armbian/documentation#1507contribute/datacenter: add rack photo gallery. by @igorpecovnik in armbian/documentation#1503contribute/datacenter: correct console server port count. by @igorpecovnik in armbian/documentation#1508create AGENTS.md. by @EvilOlaf in armbian/build#10843d1: backport the RISC-V clocksource rating fix. by @khaliforce in armbian/build#10886d1: enable RTL8723DS Wi-Fi and fix regulatory database support. by @khaliforce in armbian/build#10887data: fail closed when a mirror is unreachable, not silently short. by @igorpecovnik in armbian/armbian.github.io#447docker_publish_local: use the default when BIND_ADDRESS has no address. by @igorpecovnik in armbian/configng#1045docs: link app pages to the install steps. by @igorpecovnik in armbian/configng#1049extension: add interactive shell. by @EvilOlaf in armbian/build#10879extensions: arm64-compat-vdso: fix the riscv64 host handling. by @iav in armbian/build#10869feat: Add Seeed Studio reComputer RK3576 Module devkit dts. by @Lesords in armbian/linux-rockchip#570fix customize-image and config-example . by @EvilOlaf in armbian/build#10878generate-servers-jsons: include VMs tagged "github runner". by @igorpecovnik in armbian/armbian.github.io#476getting-started: document armbian-debug; fix armbian-upgrade wording. by @igorpecovnik in armbian/documentation#1428git: don't hard-abort when the global safe.directory write fails. by @xsalaices in armbian/build#10845git: fetch trustedfirmware.org shared submodules from GitHub mirrors. by @igorpecovnik in armbian/build#10877gl-mt2500: use lowercase vendor slug gl.inet. by @igorpecovnik in armbian/build#10895helios4: u-boot: drop obsolete patches. by @iav in armbian/build#10883imx8m, imx93, imx8ulp: fetch NXP firmware from armbian/nxp-firmware. by @igorpecovnik in armbian/build#10868kernel-debs: headers: depend on python3-minimal. by @iav in armbian/build#10846kickpi-k2b-v2: add KickPi K2B V2.2 DDR3 board (DDR3 u-boot defconfig, DTS, WiFi watchdog). by @Novice-PG in armbian/build#10902main-config: cause error when lib.config is present. by @EvilOlaf in armbian/build#10876mainline: bump to 7.3-rc6. by @EvilOlaf in armbian/build#10914mangopi-mq: fix board configuration and clock handling. by @khaliforce in armbian/build#10908mangopi-mq: replace bundled boot firmware with source builds. by @khaliforce in armbian/build#10888meson-gxm-c400-plus: enable front panel display. by @jomadeto in armbian/build#10903meson64-6.12: rebase the old aiu HDMI codec patch onto 6.12.111+. by @iav in armbian/build#10898meson64-7.2: fix due to upstream changes broken patch. by @EvilOlaf in armbian/build#10890mkdocs: cache-bust extra_css with a version query. by @igorpecovnik in armbian/documentation#1506module_redis: opt-in cache mode (REDIS_MAXMEMORY). by @igorpecovnik in armbian/configng#1038module_tuning_profile: apply was undoing its own swappiness. by @igorpecovnik in armbian/configng#1039mvebu64: fetch TF-A from its GitHub mirror. by @igorpecovnik in armbian/build#10866network: abort static IP setup on dialog cancel instead of crashing netplan. by @xsalaices in armbian/configng#1040oci: configurable OCI storage and read-only OCI_PROXY. by @igorpecovnik in armbian/build#10860Odroidxu4 wifi adjustment. by @EvilOlaf in armbian/build#10875orangePi CM5 USB3 enhancement + exprimental mode. by @ECO1AI in armbian/build#10904pack-debian: publish the repository with Acquire-By-Hash. by @igorpecovnik in armbian/scripts#94patching: let a userpatch override the same-named core patch. by @iav in armbian/build#10884pkg_remove: use purge instead of autopurge to stop cascade removal. by @xsalaices in armbian/configng#1037Radxa Rock 2A/2F mainline. by @lukaszsobala in armbian/build#10852redirector: torrent check needs proof before reporting in sync. by @igorpecovnik in armbian/armbian.github.io#474redirector: verify mirror sync by file-probe, not directory mirroring. by @igorpecovnik in armbian/armbian.github.io#471repo management: adopt the production (singlemode) repo.sh into main. by @igorpecovnik in armbian/build#10304repo: publish with Acquire-By-Hash. by @igorpecovnik in armbian/build#10911repository update: publish stable only every STABLE_REPOSITORY_UPDATE days. by @igorpecovnik in armbian/armbian.github.io#472repository update: use repo.sh from build main. by @igorpecovnik in armbian/armbian.github.io#473rockchip64-7.2: media: rkvdec: Add VP9 support for VDPU381 variant (v1). by @rpardini in armbian/build#10874rockchip64: 7.3: helios64: Wake-on-LAN through the PHY. by @iav in armbian/build#10865rockchip64: copy the RK3562 patch set from 7.2 to 7.3. by @retro98boy in armbian/build#10863rockchip: rk3506: fix RockUSB full-speed enumeration data abort. by @stevenjoezhang in armbian/build#10833runner-clean: export the runner's oci_cache as OCI_PROXY. by @igorpecovnik in armbian/actions#43runner-cleanup: keep build-cache service images. by @igorpecovnik in armbian/configng#1048runner-cleanup: never wipe _work of a runner with a live job. by @igorpecovnik in armbian/configng#1050software: add registry-cache, a read-only cache of ghcr.io. by @igorpecovnik in armbian/configng#1044software: explain how to install an app. by @igorpecovnik in armbian/documentation#1504software: stop offering Watchtower install, keep Disable. by @xsalaices in armbian/configng#1041sophgo-sg200x-aic8800: fetch the driver only when the kernel builds. by @igorpecovnik in armbian/build#10847sophgo-sg200x-aic8800: keep the 7.3 RoC cookie in the RoC element. by @lukaszsobala in armbian/build#10854sun60iw2: fix GPU userspace install ELOOP on headless builds. by @ijiki16 in armbian/build#10882sun60iw2: GPU, desktop and hardware video decode for Orange Pi 4 Pro. by @ijiki16 in armbian/build#10835sun60iw2: keep the Dirty Frag mitigation over the Armbian default. by @igorpecovnik in armbian/build#10912sun60iw2: kernel config: modulize drivers, add wireguard, mitigate dirty frag. by @EvilOlaf in armbian/build#10871sunxi-7.2: drop patch upstreamed with v7.2.9. by @EvilOlaf in armbian/build#10889sunxi: add Maxio MAE0621 PHY driver (KickPi K2B V2.2 DDR3 ethernet fix). by @Novice-PG in armbian/build#10894sunxi: recore: add device trees for Recore A5-A8. by @eliasbakken in armbian/build#10850sunxi: recore: update U-Boot and put BL31 in DRAM. by @eliasbakken in armbian/build#10853tests: skip stable switch on forky, disable redis and portainer tests. by @igorpecovnik in armbian/configng#1051u-boot: report SPL/TPL size against CONFIG_*_MAX_SIZE. by @igorpecovnik in armbian/build#10858uefi-x86-6.18: rebase i915 4-lane quirk patch for 6.18.55. by @igorpecovnik in armbian/build#10891View the full article

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

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

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

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

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

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

Next 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 article

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

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

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

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

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

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 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 article

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 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 article

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 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 article