All Activity

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

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

After 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.

No, I installed the "current" distribution, v26.11 rolling for Orange Pi PC running Armbian Linux 6.18.53-current-sunxi from here Orange Pi PC + | Armbian

bleedingedge is not meant to be used as end-user but for developers only. Use "current" if you prefer stability over breakage.

I 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.

Sometimes if your monitor is off and olimex start first and after that just monitor is on you will get "default" resolution : ~> cat /sys/class/graphics/fb0/virtual_size 1024,768 I've created a script that fix that with recompiling initramfs, adding necessary /lib/firmware/edid/1920x1080.bin file directly into it. Feel free to use, suggestions are welcome. P.S. Please add tags A20-OLinuXino-LIME2 and T2-OLinuXino-LIME2 fix_hdmi_resolution.sh

By your log: Install works; client starts, then steamwebhelper (Steam's built-in browser, draws whole Steam window) keeps crashing: window stays empty. Please send: 1. `~/.local/share/steam-arm/.local/share/Steam/logs/webhelper-linux.txt` and `cef_log.txt` (if present). These show why steamwebhelper fails. 2. Hardware report: `steam-arm-config`, Maintenance > Hardware report (writes `steam-arm-report.txt`, personal details removed). 3. Output of `echo $XDG_SESSION_TYPE` and `getconf PAGESIZE`. One test that would narrow it down: switch desktop to X11 (`sudo raspi-config`, Advanced Options > Wayland > X11, reboot), then start Steam ARM again. If Steam opens on X11, cause is Wayland. No need for dmp file; crash IDs in log were uploaded to Valve already.

Until someone dares sending PR for Current …

It was already fixed in 7.2.9 edge nightly, but 7.2 branch is gone due to 7.3 rc 6 edge nightly which makes the board unstable to use, (yesterday, after .debs build it will be solved, (Thanks Igor for the pr) people who don't know how to upgrade kernel will have that thread issue using current kernel (default)

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

What I mean here is that (from what I saw in the bootloader logs) it searches the SD card and can't find a valid UEFI or kernel to boot, just felt like clarifying.

If the issue is so important, why no one dares sending relevant PR as suggested in that thread?

When 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)

Bleeding-edge branch was where 7.1 rc was put first, then moved to edge The ethernet fix patch is the following, current kernel gives upload speeds of 10/mbps https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-7.3/board-odroidm1-change-ethernet-TXD-timing-delay-value.patch The following thread describes the issue that various users have with current kernel I'll try with edge kernel instead of current kernel (No nightly build) maybe it's just the current kernel that is doing that speed cut Thanks !

I tried 2.2 on RPi OS. Installation goes fine, but starting steam-arm doesn't work. I also tried like this: steam-arm -no-cef-sandbox I also tried the restart options. Output of terminal attached. Anything else you need for analysis? The dmp file doesn't look human readable, but I can add it. Steam.txt

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

While 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.

@Gunwoo Gim as a workaround, I have found that forcing it to use gcc-14 allows dkms to successfully build the zfs modules against the kernel packages from the repo. I had trouble finding a working way to configure dkms to use a specific compiler, but replacing the global /usr/bin/gcc symlink got things working. # The gcc-14 packages likely got installed as a dependency, but double-check before replacing ls /usr/bin/gcc-14 && sudo ln -sf /usr/bin/gcc-14 /usr/bin/gcc This appears to confirm my theory that this is a build chain issue relating to how the CI system is building packages for the apt repo. It isn't just the kernel packages/configs that are built against gcc-14, as much of the system depends on the gcc-14-base package. I only had a quick peek, but it looks like there was some significant work on the CI package build system between 26.5 and 26.8, and the July commits in https://github.com/armbian/ci/commits/main/userpatches strike me as suspicious in this context, but if it were just that I would expect the issue to be more widespread than it seems to be.

unreadable walls of barfed ai stuff

I recommend using "caveman ultra" skill to reduce the barfed out walls of slop

@Nick A I updated the latest patches from jernejsk and added support for x98h. https://github.com/bk3a12/build/tree/sunxi-7.2

Didn't know that, our tests doesn't show alerts on suboptimal perfomance. https://docs.armbian.com/status/board-tests/#odroid-m1-01 This is with stable kernel at our tests: eth0 ↑644/↓941 Mbps Annoying but not critical. We can't change operations nor policy just like that. It is stressful and costly for time. Most of processes are automatic and disrupting their regular path is asking for much bigger problems then lower ethernet speed. Our staff and machinery is already operating at extreme edge. Idealy for sorting out this problem would be backporting fixes to LTS kernel. RC / edge kernels has different role and I think we are not moving CURRENT (LTS kernel) to 7.x in upcoming release. Its too soon.