Active threads

Sorry I forgot to mention, I have used dts from Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server.img.xz version to make the 2nd USB working.

Yeah no problem, heading to GitHub. No forum for Ubuntu and you are not covering the 5b so I tried. They will care about solid performance. defcom5

> My ROCK5B was ordered as a 'blue one' on Aliexpress a year ago Mine has green PCB with some text: Rock 5B v1.42022.08.29 U-boot at sector 64 is SPL or standard U-boot? From what I've read online it looks like if it was a power supply issue I would get a boot loop but my board never reset... It looks like U-boot has support for fusb302. I will build a U-boot with more logs to see if there is any negotiation going on. I've built a Nixos Image. I'm able to go up to U-boot console, start linux via extconfig then get some Linux logs but at some point it just stops without errors on some random log.

Hello, has anyone figured out how to get the ethernet working? I have only gotten the ethernet port to work with 100mbps.

Hi @sven-ola, first of all a huge thank you for maintaining this image — the work you're doing for the Orange Pi RV2 is genuinely appreciated, especially given how early the SpacemiT/K1 ecosystem still is. I'd like to kindly request enabling a few kernel config options in the next build. I'll split them by priority: Request 1 — TechniSat SkyStar USB 2 HD (simple, guaranteed fix) CONFIG_DVB_B2C2_FLEXCOP_USB=m The FlexCop core (CONFIG_DVB_B2C2_FLEXCOP=m) and all its dependencies are already enabled in the current kernel. This is a one-line addition that will make this DVB-S2 USB receiver work out of the box with no further changes needed. Request 2 — TBS DVB cards via out-of-tree media_build (best-effort) CONFIG_DVB_USB=m CONFIG_DVB_USB_V2=m CONFIG_MEDIA_CONTROLLER_DVB=y These are the required kernel-side foundations for the TBS linux_media out-of-tree driver tree to compile and load. All dependencies are already satisfied in the current config (DVB_CORE=y, MEDIA_USB_SUPPORT=y, MEDIA_CONTROLLER=y). I say "best-effort" because the TBS media_build source has compatibility issues with kernel 6.18 APIs that require manual patching regardless of kernel config — so these options are necessary but not the whole story on my end. That part is on me to sort out, not on you. Environment for reference: Board: Orange Pi RV2 (orangepirv2) Kernel: 6.18.33-current-spacemit Armbian: 26.8.0-trunk.61 (BRANCH=current) Thank you again for your time and effort — genuinely appreciated! 🙏

Thanks for the replies. I understand that native UFS boot support is still very new, and that ext4 is currently the safest and expected path. After some more testing, I managed to get a separate ext4 /boot + btrfs / layout working on my NanoPi M5 with the onboard 64GB UFS. This is not a request for official support, and I do not want to imply that this is a recommended or fully tested solution. I am only sharing it as an experimental helper script for users who may want to test a similar layout. ============================================================ WORKING LAYOUT ============== The layout I tested successfully is: * /dev/sda1: ext4, mounted as /boot, LABEL=BOOT * /dev/sda2: btrfs, mounted as /, LABEL=ROOT * btrfs subvolume @ mounted as / * btrfs subvolume @snapshots mounted as /.snapshots The reason this works is that U-Boot only needs to read /boot from ext4. The Linux kernel and initramfs can then mount the root filesystem as btrfs. ============================================================ WHAT THE SCRIPT DOES ==================== The attached script does the following: 1. Checks that it is running as root. 2. Checks that the system is not currently running from UFS. 3. Checks that the expected UFS LUN devices exist. 4. Mounts an official Armbian NanoPi M5 image read-only through a loop device. 5. Creates a minimal safety backup. 6. Wipes and repartitions the UFS General LUN. 7. Creates an ext4 /boot partition starting at 32MiB. 8. Creates a btrfs root partition after /boot. 9. Creates btrfs subvolumes @ and @snapshots. 10. Sets @ as the default btrfs subvolume. 11. Copies the root filesystem from the Armbian image to the btrfs root. 12. Copies /boot from the Armbian image to the ext4 /boot partition. 13. Writes /etc/fstab. 14. Updates /boot/armbianEnv.txt with: rootdev=LABEL=ROOT rootfstype=btrfs 15. Ensures btrfs support is included in the target initramfs. 16. Regenerates /boot/boot.scr. 17. Uses the official write_uboot_platform_ufs() function from the image to write the UFS bootloader. 18. Performs some basic validation before finishing. The script does not patch boot.cmd. Instead, it relies on: * rootdev=LABEL=ROOT * rootfstype=btrfs * btrfs default subvolume set to @ This keeps the boot script closer to the official Armbian files. ============================================================ IMPORTANT NOTES =============== This script is destructive. It wipes the UFS General LUN. It assumes the usual NanoPi M5 UFS mapping: * /dev/sda = UFS General LUN * /dev/sdb = UFS Boot LUN A * /dev/sdc = UFS Boot LUN B * /dev/sdd = vendor/config LUN It was only tested on my NanoPi M5 with onboard 64GB UFS. Please review the script carefully before running it. I am attaching it only as an experimental helper for testing, not as an official solution. ============================================================ BASIC USAGE =========== Boot from an SD card maintenance system first. Make sure the Armbian image is already decompressed to .img. Example: sudo ./flash-nanopi-m5-ufs-btrfs.sh --image /path/to/Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img For a dry run: sudo ./flash-nanopi-m5-ufs-btrfs.sh --image /path/to/Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img --dry-run --yes-i-understand The script requires typing: YES_FLASH_UFS before it performs the destructive flashing operation, unless --yes-i-understand is used. ============================================================ RESULT ====== With this layout, the system boots successfully from UFS on my NanoPi M5 with the BOOT switch set to UFS/SD. After booting, I verified that: * / is btrfs from LABEL=ROOT * /boot is ext4 from LABEL=BOOT * /.snapshots is a btrfs subvolume * the system boots without requiring U-Boot to read btrfs directly I hope this may help other users who want a btrfs root filesystem on UFS while keeping /boot on ext4. flash-nanopi-m5-ufs-btrfs.sh

Radxa-e54c - tested okay please move to dl: Armbian_26.5.1_Radxa-e54c_resolute_vendor_6.1.115_gnome_desktop Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 USB Reboot Shutdown HDMI video HDMI audio Armbian_26.5.1_Radxa-e54c_resolute_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 (needs manual config) USB Reboot Shutdown Armbian_26.5.1_Radxa-e54c_trixie_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 (needs manual config) USB Reboot Shutdown

The first iteration of mainline kernel driver support has just been posted. So a kernel build with this patch set applied should give a playground for initial experiments.

Hi, I need help with flashing my tv box or installing it on linux. I would also be happy if you could run an armbian or similar minimal system. I would like to run a website on it at home. I already did it for an old venz v10 for a friend and installed armbian on it and he really liked it, but my couldn't install it with a memory card, the on new box 1. System Information Google Android Tv Box - Android 14 Android Version: 14 (Upside Down Cake) API Level: 34 Android Security Patch Level: 2025-01-01 Rooted Device: No Android ID: 5c4aa62950194797 Build ID: rk3528_box_32-userdebug 14 UTT2.241219.001 eng.hxws.20260124.163421 release-keys Codename: REL Fingerprint: google/blueline/blueline:14/UTT2.241219.001/eng.hxws.20260124.163421:userdebug/release-keys ID: UTT2.241219.001 Incremental: eng.hxws.20260124.163421 Java Runtime Version: Android Runtime 0.9 Java Virtual Machine Version: ART 2.1.0 Java Virtual Machine Heap Size: 128 MB Kernel Architecture: armv7l Kernel Version: 6.1.118 (hxws@PowerEdge-R720-8) (Android 10087095, +pgo, +bolt, +lto, -mlgo, based on clang 17.0.2 of r487747c (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362), LLD 17.0.2) #124 SMP PREEMPT Wed Jan 21 10:25:12 CST 2026 Tags: release-keys Type: userdebug Google Play Services Version: < None > Huawei Mobile Services Version: OpenSSL 1.1.1 (compatible; BoringSSL) OpenSSL Version: 1.2.13 ZLib Version: 1.2.13 2. Hardware and Processor (CPU/Device) Device Type: TV Manufacturer: Google Model: android_tv_box Brand: google Motherboard: RK3528 Device: blueline Hardware: rk30board Platform: rk3528 Product: blueline Processor: RK3528, 4 cores SoC Model: RockChip RK3528 Core Architecture: 4x ARM Cortex-A53 @ 2016 MHz Instruction Set: 64-bit ARMv8-A (32-bit mode) CPU Version: r0p4 CPU Cores: 4 CPU Clock Range: 408 - 2016 MHz CPU Utilization: 5% Scaler Controller: Interactive Supported ABIs: armeabi-v7a, armeabi Supported 32-bit ABIs: armeabi-v7a, armeabi AES/ASIMD/NEON/PMULL/SHA1/SHA2: Supported 3. Memory and Storage (RAM/Storage) Installed RAM: 2 GB Total Memory: 1920 MB Available Memory: 1221 MB Memory Used: 707 MB (36% of 1.9 GB) Total Internal Storage: 11.00 GB Free Internal storage: 10.11 GB Storage usage: 914 MB (8% of 11 GB) 4. Display and GPU (Display) Display: 1920 x 1080 (Full HD, 16:9) Screen resolution: 1920 x 1080 xdpi / ydpi: 320 / 320 dpi GPU manufacturer: ARM GPU renderer: Mali-450 MP Refresh rate: 60 Hz Default orientation: Landscape OpenGL ES version: 2.0 GPU version: OpenGL ES 2.0 OpenGL ES extensions: (List: GL_EXT_debug_marker, GL_OES_texture_npot, GL_OES_vertex_array_object, GL_OES_compressed_ETC1_RGB8_texture, GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_OES_standard_derivatives, GL_OES_EGL_image, GL_OES_depth24, GL_ARM_rgba8, GL_ARM_mali_shader_binary, GL_OES_depth_texture, GL_OES_packed_depth_stencil, GL_EXT_texture_format_BGRA8888, GL_OES_vertex_half_float, GL_EXT_blend_minmax, GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_rgb8_rgba8, GL_EXT_discards_framebuffer, GL_OES_get_program_binary, GL_ARM_mali_program_binary, GL_EXT_shader_texture_lod) 5. Network and Connections (Network/Bluetooth/USB) Network: WiFi Telephony: None Wi-Fi Status: Enabled SSID: BSSID: 02:00:00:00:00:00 Hidden SSID: No IPv4 Address: 192.168.1.35 IPv6 Address: fe80::5ef3:83b1:27d0:574a Signal Strength: -46 dBm (Excellent) Link Speed: 54 Mbps Frequency: 2427 MHz Gateway: 192.168.1.254 Netmask: 255.255.255.0 DNS1: 192.168.1.254 DHCP Lease Time: 24 hours 5 GHz Band: Supported Wi-Fi Aware: Not Supported Wi-Fi Direct: Supported Bluetooth: Enabled Bluetooth Version: 4+ USB Device - Linux 6.1.118 ehci_hcd EHCI Host Controller: (Serial Number: ff100000.usb, ID: 1D6B-0002, Class: 09/00, Speed: 480 Mbps) USB Device - Linux 6.1.118 xhci_hcd xHCI Host Controller: (Serial Number: xhci-hcd.4.auto, ID: 1D6B-0002, Class: 09/00, Speed: 480 Mbps) USB Device - YICHIP Wireless Device 6. Other Data Audio: HDMI 7.1 Codecs: Widevine L3 (SD only) Wireless Debugging: Enabled IP Address and Port: 192.168.1.35:40729 Wi-Fi pairing code: 642947 IP address and port (for pairing): 192.168.1.35:40035 Device features: (List: android.hardware.audio.output, android.hardware.bluetooth, android.hardware.bluetooth_le, android.hardware.camera, android.hardware.camera.any, android.hardware.camera.external, android.hardware.camera.front, android.hardware.cetherandroid.hdware.mi android.hardware.keystore.app_attest_key, android.hardware.location, android.hardware.location.network)

Thank you @Revellion I just did ``` sudo apt-mark unhold armbian-firmware sudo rm -rf /lib/firmware/qcom/sm8550/ayn/ sudo apt update && sudo apt upgrade ``` and it worked fine

I just ran into the same issue on a FriendlyARM RK3588. Wanted to swap it out with FriendlyWRT to turn it into a router, but now only Armbian SD cards boot. Even after a vendor supported 'factory reset' process via USB. While it may not be intended to be a lock down and just due to poor testing/planning/silo effect, this is really uncool and should either be fixed or a better way to back out than having to manually pull pieces out and DD them over..

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. Armbian v26.5.1 delivers another strong round of improvements across the project, focusing on expanded hardware support, desktop and userland refinements, build framework modernization, and infrastructure enhancements. This release introduces new board images and platform updates, improves Ubuntu 26.04 "Resolute" integration, refines Bianbu desktop support, adds firmware and driver updates including AX210 wireless support, and continues ongoing work to strengthen the build system, CI pipelines, and developer tooling. Numerous kernel, bootloader, and device tree updates further improve stability, compatibility, and performance across a wide range of ARM and x86 platforms, reinforcing Armbian's commitment to providing a reliable and flexible Linux distribution for single-board computers, embedded devices, and edge computing deployments. 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 Armbian Quarterly digest · armbian/buildThis quarter’s work centers on three priorities: kernel modernization across SoC families, a redesigned desktop subsystem driven by armbian-config, and substantial expansion of board and platform c…GitHubarmbianNative UFS boot lands on the NanoPi M5Armbian’s next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage classArmbian blogDaniele BriguglioWe rewrote how Armbian installs desktops. Here’s what changedA friendlier, faster, snap-free desktop install in armbian-config If you’ve installed a desktop environment with armbian-config over the last few months, you may have noticed things feel different: there’s a tier you can pick, the browser actually works on every arch, uninstall doesn’t take half your system with it, andArmbian blogIgor PecovnikView 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. Armbian v26.5.1 delivers another strong round of improvements across the project, focusing on expanded hardware support, desktop and userland refinements, build framework modernization, and infrastructure enhancements. This release introduces new board images and platform updates, improves Ubuntu 26.04 "Resolute" integration, refines Bianbu desktop support, adds firmware and driver updates including AX210 wireless support, and continues ongoing work to strengthen the build system, CI pipelines, and developer tooling. Numerous kernel, bootloader, and device tree updates further improve stability, compatibility, and performance across a wide range of ARM and x86 platforms, reinforcing Armbian's commitment to providing a reliable and flexible Linux distribution for single-board computers, embedded devices, and edge computing deployments. 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 Armbian Quarterly digest · armbian/buildThis quarter’s work centers on three priorities: kernel modernization across SoC families, a redesigned desktop subsystem driven by armbian-config, and substantial expansion of board and platform c…GitHubarmbianNative UFS boot lands on the NanoPi M5Armbian’s next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage classArmbian blogDaniele BriguglioWe rewrote how Armbian installs desktops. Here’s what changedA friendlier, faster, snap-free desktop install in armbian-config If you’ve installed a desktop environment with armbian-config over the last few months, you may have noticed things feel different: there’s a tier you can pick, the browser actually works on every arch, uninstall doesn’t take half your system with it, andArmbian blogIgor PecovnikView the full article

Finally this board works. But it doesn't boot from eMMC onboard when flashing it. I used both dd on the Armbian image (Trixie), or the armbian-config and official download and flash image into eMMC. The error is: U-Boot SPL 2024.10_armbian-2024.10-Sf919-P0490-Hc6a9-V4f26-Bd0d2-R448a (May 11 2026 - 06:14:06 +0000) DRAM: 4096 MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device 1. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### It seems into the SPL bin file there's no eMMC activation code.

@Marvin-03 You're probably right—it may be worth checking the FPC connection. A timeout usually only occurs when the PCIe/NVMe board is not being detected. I'm currently using an early MCUZone NVMe 2230 HAT. I recently ordered a new Waveshare AIO HAT as well, so once it arrives I'll be able to do some additional testing.

its not 905 its 805x android 7 i am working on same board contact me i can help

Armbian 26.2.1 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - 26.2.0~git2605212123.7b286abe336 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.3 42ae8b818 (https://ryanfortner.github.io/box64-debs/) + wine-proton-11.0-beta1-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/download/proton-11.0-beta1/wine-proton-11.0-beta1-amd64-wow64.tar.xz) + DXVK-stripped v2.7.1 ~40fps@720p Grand Theft Auto IV - The Complete Edition

Hi, I can't find an image for my TV box and I was wondering if anyone has one that I could use on the device. Thanks for your help

Great job I don't have time to replicate this, but I would like to see more photos, screenshots, and what you can do with so many SDRs It's perfect to use an older kernel, if you don't need anything from a newer Linux (for example more stable Wifi, and resistive LCDs with Wayland)... In your writeup, you could have included the dmesg or journalctl messages, just prior to the crash. Sometimes, there's a confict between a new or changed kernel module and the module you want to use, and it causes crashes, or not being able to start Linux. Then you deactivate the module that gives you the problem. Which services were disabled with sudo systemctl mask systemd-networkd-wait-online ? It sounds like you never want to start a network service automatically on boot. I hope that the SoapySDR developers can fix the root issue, so that you don't need to lock a library .SO like that I made a thread showing how to control GPIO with Python gpiod https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio/#findComment-181191 Instead of using Opi.GPIO, which relies of sysfs (deprecated, and you can't use it in newer Linux)

I had no idea that there's an OpiZ3W Just in case, it is nothing at all like the Orange Pi Zero 3, which has a lot in common with the OpiZ2W. Yeely: what are your first impressions about this board? Are there demos for the NPU? Are the video encoders and decoders working with the Orange Pi Linux OS? Bring up verifiable (open source) examples of AI generated code, making an improved program.

Ok thanks my apologies. Oh thanks, I missed that point. This box should've been ewaste long ago I gotbthe bright idea.of using it as a low power 'digital sign' driver for my wife's store . I started with ohub bookworm server for the board. I couldn't get the boot toothpick to read cards or usb. It wasn't until I flashed CoreELEC to a card and was trying to see if it was a distro issue that I realized the box was trying to go into android recovery with the toothpick not looking for boot drives. I put aml_autoscript from the CoreELEC root folder and zipped it then I used android recovery mode to clear the cache and update from card pointing at the zip file. Even though the final output was that it failed it actually loaded CoreELEC autoscript and when I rebooted it read the bootloader on sdcard. After discovering that little nuance I did the same for the flashed Arabian distro but it didn't seem to catch the bootloader on sdcard. I assumed I wasn't getting the right dtd.img copied so I tried the most likely for the chip and when I.asked ai it thought I needed a legacy version. When I throw the CoreELEC in now it still boots from the card. I made the assumption that the modifications to android boot would work accross distros so it didn't seem strange that CoreELEC might boot even if it was the bookworm autoscript being used by android. Thanks for taking the time to reply even though it's the wrong forum and my apologies I should've thought that through. Looking at the hub forum it didn't seem like there was much in the way of replies happening. Cheers

Hello, After more research it seems that despite the Wikipedia screenshot, M2 Ultra & M2 Berry do not really have the same CPU : M2U uses R40 and M2B uses V40 This is most probably why it does not work. After checking watchdog & sysrq, I almost rebooted with : echo 1 > /proc/sys/kernel/sysrq echo b > /proc/sysrq-trigger but still hung in the end. I was about to throw the Banana PI away, and I finally found this website which provides a (very) raw debian image for the M2 Berry, and it works correcty including reboot. Sharing the link in case it helps other people with M2B : https://sd-card-images.johang.se/boards/banana_pi_m2_berry.html Thanks for your help Regards

Hello Aniket, as i mentioned the armbian is not working because of the different DRAM Voltage setting in uboot. The board was running with original debian version from RADXA https://github.com/radxa-build/radxa-cubie-a5e/releases. If you check the log you see the dram voltage settings and training. For me i'm waiting until a board with 2/4GB which hopefully runs with armbian. Rolf

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