Active threads

@robertojHi, friend! How are you? How's your health? Do you have any news on the release of the Orange Pi Zero3 and ili9488 screen setup guide?

Does this mean that the latest version on which OMV7 can be installed is the following? https://fi.mirror.armbian.de/oldarchive/helios4/archive/Armbian_25.8.1_Helios4_bookworm_current_6.6.101_minimal.img.xz

thnx. it seems latest working vendor kernel for 3566 is 6.1.115. i already tried rk35xx, with bigtreetech_cb2.dtb but it stops at u-boot (in uart console) using orangepi-3b it boots, but gives errors in dmesg. when i try to add fdtfile bigtreetech_cb2.dtb, it stops boot .... 47274496 bytes read in 3902 ms (11.6 MiB/s) Failed to load '/boot/dtb/rockchip/rk3566-bigtreetech-cb2.dtb' libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' ..... but when i boot btt_cb2 as orangepi3b board, it boots and even shows mpp venc/dec/npu/whatever modules properly loaded. not checked yet if it works really maybe need to make some hybrid dtb from btt_cb2 and orange3b ========= btw, could You share what You do for 35xx board change? when i tried to change family rockchip64 to 35xx, it comiled, but not copied bigtreeetech_cb2.dtb to boot , and not boots ewven if i copy it by myself there

At this point, the most realistic path is to use hardware that is already officially supported. Bringing up new hardware or maintaining outdated vendor kernels requires significant engineering time and resources. Board enablement is not a small task. It involves ongoing maintenance, testing, integration work, and long-term support. This represents real cost for the project while public project funding is not even on the level to cover response of such ideas. If you are expecting someone will just emerge and spent months of his private time in exchange for: constant insults, hate and complete absence of financial coverage for the time spent (things are never in perfect state to satisfy over-spoiled customers of someone else) ... adjust expectations. We encourage users to choose hardware wisely - that already has active support and to contribute back to the project when possible. That is the only way we can avoid overextending limited resources, burnouts, collapse.

This Gdrive is empty now... Did we see any improvements for the Orange Pi 4A in the 26.2.1 release?

That's strange 🙂 ...we have the same kernel. Maybe something's broken in the system? But I haven't messed with Bluetooth in the system. I've only updated the system: apt update /apt upgrade /reboot 🙂 root@orangepi3-lts:~# rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth bluetooth unblocked unblocked 1 wlan phy0 unblocked unblocked .............................. bluetoothctl Waiting to connect to bluetoothd... it keeps reading but shows nothing? ................... bt-device -l ** ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion failed: (ADAPTER_IS(self)) Bail out! ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion failed: (ADAPTER_IS(self)) Aborted ............. Something must have broken in the system, but what and where? Can you give me the exact: Armbian image + version ... Contents of ..../lib/firmware/uwe5622/ also: armbianEnv.txt Output dmesg | grep -i uart i dmesg | grep -i bluetooth Maybe that will help me figure out where the errors are in my system? Or maybe I have Debian and you have Ubuntu? Ps. or, more simply, information from the file: diagnostics.txt command in terminal: ................. ( uname -a cat /etc/os-release ls -lh /lib/firmware/uwe5622/ lsmod | grep -iE "bt|sprd|uwe" dmesg | grep -i uart ls /dev/tty* | grep -i "ttyS\|ttyAMA\|ttyBT" cat /boot/armbianEnv.txt rfkill list hciconfig -a bluetoothctl list hcitool dev bt-device -l dmesg | grep -iE "bluetooth|uwe|sprd|hci" ) > diagnostics.txt .....................

DKMS compilation per board, examples: https://github.com/armbian/build/blob/main/config/boards/radxa-cubie-a5e.csc#L20-L22 https://github.com/armbian/build/blob/main/config/boards/orangepirv2.wip#L13-L17 https://github.com/armbian/build/blob/main/extensions/radxa-aic8800.sh https://github.com/armbian/build/blob/main/extensions/bcmdhd-spacemit.sh

@Issou thanks for the feedback, I eventually got my hands on the Orange Pi zro I had in a remote location, I will make a fresh install and see how it behaves.

Testing the latest build: apt update && apt upgrade -y Hit:1 http://deb.debian.org/debian trixie InRelease Get:2 http://deb.debian.org/debian trixie-updates InRelease [47.3 kB] Get:3 http://security.debian.org trixie-security InRelease [43.4 kB] Get:4 https://github.armbian.com/configng stable InRelease [5,467 B] Get:5 http://deb.debian.org/debian trixie-backports InRelease [54.0 kB] Err:2 http://deb.debian.org/debian trixie-updates InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:41Z Verifying signature: Not live until 2026-03-02T13:39:55Z Err:3 http://security.debian.org trixie-security InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T02:15:55Z Verifying signature: Not live until 2026-03-02T02:15:55Z Err:4 https://github.armbian.com/configng stable InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T16:02:28Z Err:5 http://deb.debian.org/debian trixie-backports InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:27Z Verifying signature: Not live until 2026-03-02T13:39:49Z Get:6 http://fi.mirror.armbian.de/beta trixie InRelease [39.4 kB] Err:6 http://fi.mirror.armbian.de/beta trixie InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T08:25:38Z Fetched 190 kB in 1s (143 kB/s) All packages are up to date. Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://deb.debian.org/debian trixie-updates InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:41Z Verifying signature: Not live until 2026-03-02T13:39:55Z Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://security.debian.org trixie-security InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T02:15:55Z Verifying signature: Not live until 2026-03-02T02:15:55Z Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: https://github.armbian.com/configng stable InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T16:02:28Z Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://deb.debian.org/debian trixie-backports InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:27Z Verifying signature: Not live until 2026-03-02T13:39:49Z Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://fi.mirror.armbian.de/beta trixie InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T08:25:38Z Warning: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T16:02:28Z Warning: Failed to fetch http://beta.armbian.com/dists/trixie/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Missing key DF00FAF1C577104B50BF1D0093D6889F9F0E78D5, which is needed to verify signature. Verifying signature: Not live until 2026-03-02T08:25:38Z Warning: Failed to fetch http://deb.debian.org/debian/dists/trixie-updates/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:41Z Verifying signature: Not live until 2026-03-02T13:39:55Z Warning: Failed to fetch http://deb.debian.org/debian/dists/trixie-backports/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T13:39:27Z Verifying signature: Not live until 2026-03-02T13:39:49Z Warning: Failed to fetch http://security.debian.org/dists/trixie-security/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Verifying signature: Not live until 2026-03-02T02:15:55Z Verifying signature: Not live until 2026-03-02T02:15:55Z Warning: Some index files failed to download. They have been ignored, or old ones used instead. Summary: Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0 root@radxa-cubie-a5e:~# armbianmonitor -u Collecting info and sending to paste.armbian.com, wait... https://paste.armbian.com/zefutefuzi Please post the URL in the forum where you've been asked for. https://paste.armbian.com/zefutefuzi

There aren't any Armbian builds for 5.15 is what I said. And it would be a lot of work to make that happen. Why do you want 5.15? How do you know that would work, when 6.12 doesn't?

You can just download rock-3a edge(6.18+) images (not vendor 6.1) and change the device tree entry (sdcard/boot/armbianenv.txt) to point to "rockchip/rk3566-radxa-cm3-io.dtb" . This seems to boot fine with majority of features working.

Get the recap of Nicolas Frattaroli's FOSDEM talk detailing Rockchip’s mainline progress, including Vulkan 1.4 and NPU support as a vital path to sustainable, affordable hardware. View the full article

@Werner Sorry for disturbing. I found that my board is actually 3 gb variant. Removed the heat sink. It is actually 3gb variant. The problem was hardware. We can close this topic.

The Rock-s0 has the same rk3308b processor and the build uses a BL31binary, with u-boot. The SV06Ace has the same cpu and BL31/u-boot. I reviewed this thread and was trying to follow the example commit provided. It is a little difficult to work through a commit as not all of the paths to the files are present in my depth=1 git clone. Is it possible to download the commit for the Rock-s0 and use it to patch the build directory? If I could run the patch, then I would have some actual files to copy and edit. The maintainer of the Rock-s0, linked on the Armbian Info page for the s0 has not made any recent commits. The last Rock-s0 commit was where it was moved back to an older bootloader scheme. # Rockchip RK3308 quad core 512MB SoC WiFi BOARD_NAME="SV06 Ace" BOARD_VENDOR="sovol" BOARDFAMILY="rockchip64" BOARD_MAINTAINER="shep" BOOTCONFIG="sv06ace-rk3308_defconfig" BOOT_FDT_FILE="rockchip/sv06ace.dtb" KERNEL_TARGET="current" KERNEL_TEST_TARGET="current" DEFAULT_CONSOLE="serial" SERIALCON="ttyS0" MODULES_BLACKLIST="rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi gpu_sched lima hantro_vpu panfrost" HAS_VIDEO_OUTPUT="no" BOOTBRANCH_BOARD="tag:v2024.10" BOOTPATCHDIR="v2024.10" BOOT_SCENARIO="binman" DDR_BLOB="rk33/rk3308_ddr_589MHz_uart0_m0_v2.07.bin" BL31_BLOB="rk33/rk3308_bl31_v2.26.elf" FORCE_UBOOT_UPDATE="yes" OVERLAY_PREFIX="rk3308" function post_family_config__rocks0() { declare -g BOOTDIR="u-boot-${BOARD}" declare -g BOOTSCRIPT="boot-rockchip64-ttyS0.cmd:boot.cmd" family_tweaks_bsp() { #overrides rockchip64_common.inc #Install udev script that derives fixed, unique MAC addresses for net interfaces #that are assigned random ones bsp=$SRC/packages/bsp/rockpis rules=etc/udev/rules.d Specifically, where are following files, referenced in /build/boards/*.csc located? BOOTCONFIG=*.defconfig" BOOT_FDT_FILE="*.dtb" The declared boot scripts Thanks

What a nice picture! Would you be generous to post your NPU device info? I'm also looking for some w8a8 llm models working on NPU (the GEMM capability is perfect, isn't it).

I am not familiar with these images as I normally self build with the Armbian framework. A trade off of falling back to the old kernel, do you know the chipset of the WiFi dongle? I recall the old Realtek drivers being a complete pain Potentially as the USB iD pin is already exposed within the DTS, however the driver still currently ignores this. It is what requires the most work. The only thing I can think of that the dwc2 overlay initializes suxni-musb underneath along with setting some additional configurations. If you can find where it is actually stored on the image then we can see what pieces are missing then see if it is actually a driver issues or the DTS definitions have changed. Which version of Windows are you using? I can only guess that whatever windows components supporting g_mass_storage are legacy and being removed. Ryzer

Vendor kernel will stay for awhile (this year for sure) as mainline is not on this level yet. This part might not be part of the release - you can grab it from nightly release - but most likely it won't have any affect to this topic.

Welcome to the latest Armbian Newsletter, your source for updates, community highlights, and behind-the-scenes news from the world of open-source ARM and RISC-V computing. Streamlining the ecosystem This past quarter development has taken a significant step forward for Armbian. We've been busy cleaning up and optimizing our codebase, merging over 150 improvements primarily focused on advancing kernel support for Rockchip and Allwinner platforms. A significant secondary effort was dedicated to modernizing the project's infrastructure and build tools, driven largely by a core group of dedicated contributors. Hardware support continues to expand. We're thrilled to introduce new LTS kernel v6.18 based images and support for exciting new boards like the SpacemiT MusePi Pro, Radxa Rock 4D, Orangepi RV2, Odroid M2, ... We've also brought back KDE Neon desktop builds and added RISC-V XFCE desktop support for those exploring new territory. Our user tools have received major upgrades too. Armbian Imager now features faster decompression, enhanced security with code signing for macOS and Windows, AI-powered translations, and a new settings panel with developer options. Behind the scenes, we've strengthened our build infrastructure to keep everything running reliably as we grow. Whether you're trying the new stable kernel or experimenting with our latest builds, this update reinforces our commitment to delivering a professional, accessible Linux experience for ARM and RISC-V hardware. Join Armbian at Embedded World 2026. Meet us in Hall 3, Booth 3-556 (Seeed Studio), where we’ll be showcasing the Armbian build framework and how it powers reliable, production-ready Linux for ARM devices. Download the latest release and experience Armbian today. SPONSORED Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices. Release v26.2.1 · armbian/buildChanges sunxi: refactor full patchset. by @EvilOlaf in armbian/build#9219 “get completely rid of dead code toolchain stuff”, pt2. by @rpardini in armbian/build#9218 “get completely rid of dead cod…GitHubarmbianForget third-party utilities: meet Armbian ImagerArmbian Imager eliminates the guesswork from flashing SBC images. Real-time board detection, persistent caching, and built-in safety make installation fast, simple, and risk-freeArmbian blogDaniele BriguglioArmbian 2025: by the numbersOpen hardware is growing faster than ever and breaking in new ways. 2025 has been a productive year for the Armbian project. As the Single Board Computer ecosystem continues to fragment and expand, Armbian has consolidated its position as the universal glue holding the open-source hardware world together. Our missionArmbian blogMichael RobinsonThe Evolution of SBCsThe Evolution of SBCs: From Hobby Boards to Edge Computing Over the past two decades, single-board computers (SBCs) have transformed from experimental maker tools into the backbone of modern embedded and edge systems. What started as a handful of affordable hobby boards has grown into a diverse ecosystem powering automation,Armbian blogMichael RobinsonView the full article

Thanks to whom it may concern. I downloaded the today's version and it did connect..

Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 ed9827920 (https://ryanfortner.github.io/box64-debs/) + wine-11.3-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/11.3) + vkd3d-1.19 (wine's built-in) ~60fps@1024x576 (medium settings) Hades 2

Hi, I redownloaded the key and replaced it, and it works!

GPL requires source code be offered for any software distributed. Changes to the build system probably aren't covered, but a modified DTB probably is. The final image also has the Linux kernel and other GPL components, so that definitely is. Bottom line is that GPL is supposed to be permissive. DTS is easily gotten from DTB. And you're probably good as long as you're not being a jerk about it. If that bothers you, you could also make a overlay (dtbo) and just patch the DTB on boot. You'd avoid the custom image and also make it more clear that your DTB is tweaked.

I finally managed to boot in Maskrom mode by shorting the clock pin (red circle on the picture) to ground, then loading the loader (rk3528_spl_loader_v1.07.104.bin) and u-boot with rkdeveloptool.

Dear @Werner , I have just created an issue on Github to keep track of this discussion: https://github.com/armbian/build/issues/9446 Is it safe to try possibly unsupported images on the NanoPC-T6 Plus ? It's a relatively expensive piece of kit and I'd rather not take any chances (new LPDDR5 RAM: possibly new memory timings, etc.) Best regards, Samuel

... problem is elsewhere. This is running: sudo dpkg-reconfigure tzdata in CLI (Armbian Noble), choosing region Atlantic, then: