Active threads

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.

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.

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 …

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.

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

1. If written by AI, it should be disclosed more openly than hidden in the commits IMHO. (this is written by claude) 2. By using this, the storage gets written to 1440 times per day, ie once per minute via the systemd timer. (If storage is on an SD-card the longevity of that storage is significantly shortened, you might as well just disable the ramlog completely) 3. After a very quick glance it looks like logs will be deleted without archiving too. For example, if the rotation fails, the logs are still truncated making it impossible to debug using logs in case of a write failure. It also looks like it will --vacuum-size with JOURNAL_VACUUM_SIZE=20M, that is a very small size imho, so not a lot to look back at after it vacuums. /var/log/journal is excluded? (disclaimer: I only took a very quick glance, so I could be wrong in my analysis) The better option is to do what is described in this thread, increase the size of the ramlog by editing /etc/default/armbian-ramlog and reboot (or reloading configs & restarting the relevant systemd service), or just disable ramlog to write directly to disk. Just my two cents.

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

Also to me it looks strange, but it works (in the configuration without the backslash)

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

Now this issue has been fixed on Odin2 edge 7.2 kernel branch

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

I had em build the damn thing. I think it was 39 lines of code: Cool having first https://bugzilla.mozilla.org/show_bug.cgi?id=2078820

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