Active threads

moved

@Dravens Wayland compositing was broken on this Panthor/Mali-G610 stack. KWin-Wayland crashed when I tried it, and I never really looked into it any further. X11 is the session I ran with, and what the desktop hooks use. Nested Wayland works ok. I ship `cage`/`gamescope` running as a client inside the X11 desktop. This app gets a Wayland socket and PanVK Vulkan, no conflict with X11 alongside it (that's what my gaming/kiosk modes use). TLDR: Full Wayland has a known unfixed crash on this GPU stack. Checked the image, and the ophub kernel this build ships (6.1.141-rk3588-ophub) already has it compiled in (`binder.ko` in modules.builtin, so `CONFIG_ANDROID_BINDER_IPC=y`). So nothing needs rebuilding on my side. ashmem isn't needed either, Waydroid uses memfd since 1.2.1. Which means you can just try it: install `weston` + waydroid, run `weston --xwayland`, set `WAYLAND_DISPLAY`, and launch waydroid into it. Ready-made scripts: [waydroid-x11](https://github.com/mid-kid/waydroid-x11), [waywes](https://github.com/KSMaan45/waywes). Note it's Weston, not the cage/gamescope I ship. Warning on the GPU though: [waydroid#760](https://github.com/waydroid/waydroid/issues/760) is a Rock-5b (same RK3588/Mali-G610) that only boots with GPU disabled, [#776](https://github.com/waydroid/waydroid/issues/776) is "rockchip-rk3588 GPU unsupported", and [#2087](https://github.com/waydroid/waydroid/issues/2087) reports Panfrost/Panthor perf way below host. That's upstream Waydroid's passthrough, not something I can fix here. Expect software rendering... which could make other things run kinda rough.

@AurealNix - I realised I meant to say "NVMe is recognised now" so was getting a little ahead of myself so felt i should at least give the SSD a bit more exercise. cue: f3write/f3read on the entire 256GB + rinse/repeat a few times worked ok with nothing appearing in the dmesg to indicate it trips up etc. Regarding running rootfs on I'll see if I can squeeze that in (maybe Tuesda) as i will need to dd my sd and then image onto the NVMe and tweak /boot/boot.cmd /boot/orangepiEnv.txt accordingly - I can't just use your image on the NVMe as it starts at 2GB and then stretches out at first boot. If this is what you are looking to do/get-tested or maybe something else ? Also (low priority request), if you could add/install iproute2 onto the minimal image that would be handy! Cheers

It is not early fix, but now it should work as expected on non-vendor kernels https://github.com/armbian/build/pull/10289 Also it works flawlessly on vendor kernel with previous overlay

i have r2-pro banana pi with 3568. tell what i need to do?

Because that's what Petitboot uses for its rootfs, and that's why it's not enabled in my build either since there's no Petitboot payload. Just pure U-Boot payload. I’m running this system on all my devices: My latest system resides on a USB-connected selfpowered storage device, so I can use it with all my devices since a USB port is basically standard nowadays. No hassle with proprietary eMMC module connectors or a potentially unavailable NVME slot. Speed-wise, it's on par with an eMMC in any case, but the GB/EUR ratio clearly speaks in favor of an NVME. Since the necessary firmware for system startup is always located on a storage device supported by the MASKROM code (SPI flash preferred, but eMMC or microSD is on par), the operating system can be used unmodified in the same way on all devices. Just plug-in and reboot to run it instead of its usual operating system. By the way, the screenshot was taken on my only remaining device in my collection with an Amlogic SoC. As you can see, I just updated the firmware to the state of my last build. It uses the same U-Boot binary payload as the HC4, C4 and N2, just the closed source bloobs and the DTB differs in the firmware compose. U-Boot detects at runtime which of the four devices it's running on and acts accordingly.

hi, I've been running Armbian on my TV box for a few weeks now as a little server and it works great, but I noticed a few problems: 1. wifi never seems to work regardless of led-conf settings. best I've gotten so far is led-conf4 and led-conf7 letting me scan networks, but connecting always fails (SSV6051P) 2. not only does bluetooth not work in any led-conf, it seems to be stuck in a weird state where it tries to aggressively connect to anything it sees, disrupting things like bluetooth speakers around my house how should I troubleshoot these? my box is an old model I found collecting dust in my house, branded "A6 8K". apparently so rare I can't find exact photos or listings of it online rk322x-config says: Chip type: RK3228A/B - Serial: URKU40011 00000000102437 CPU Leakage: 0x07 - Logic Leakage: 0x05 Internal flash: eMMC see attached photos for motherboard pics and rk322x.txt for descriptions of behavior with each led-conf I can provide a backup of its original android install privately if needed tested on edge kernel: Linux rk322x-box 7.1.4-edge-rockchip #1 SMP Sat Jul 18 14:55:52 UTC 2026 armv7l GNU/Linux with overlays: cpu-hs emmc emmc-ddr-ph45 ddr3-800 + each led-conf rk322x.txt

Hi, Finally, I made some good progress. I updated the DTS by starting with the DTS from Armbian 26.5.1 for current 6.18.x kernels and then merged the missing NPU and Power Domain nodes from the original DTS provided by @m1zfs. While comparing the original DTS with the current Armbian DTS, I also found that one of the phandle references in the NPU power-domain definition needed to be adjusted to match the phandle numbering used in the current Armbian DTS. After fixing that, the system booted successfully and the NPU was detected correctly. I'm now testing it with rknn_toolkit2 to verify that the NPU is fully functional. root@odroidtest:~# uname -a Linux odroidtest 6.18.35-current-rockchip64 #2 SMP PREEMPT Tue Jun 9 10:28:53 UTC 2026 aarch64 GNU/Linux root@odroidtest:~# root@odroidtest:~# lsmod | grep -E '^(rknpu|dma32_heap)\b' rknpu 94208 0 dma32_heap 12288 0 root@odroidtest:~# root@odroidtest:~# ls -l /dev/rknpu /dev/dri/by-path/platform-fde40000.npu-render /dev/dma_heap/system /dev/dma_heap/dma32 crw------- 1 root root 251, 3 Jul 25 21:19 /dev/dma_heap/dma32 lrwxrwxrwx 1 root root 19 Jul 25 21:19 /dev/dma_heap/system -> /dev/dma_heap/dma32 lrwxrwxrwx 1 root root 13 Jul 25 21:19 /dev/dri/by-path/platform-fde40000.npu-render -> ../renderD128 crw------- 1 root root 10, 261 Jul 25 21:19 /dev/rknpu root@odroidtest:~# root@odroidtest:~# dmesg | grep -i rknpu [ 6.108962] [drm] Initialized rknpu 0.9.8 for fde40000.npu on minor 1 [ 6.110169] RKNPU fde40000.npu: RKNPU: DKMS: /dev/rknpu registered (DMA-BUF import only) [ 6.132583] RKNPU fde40000.npu: RKNPU: SCMI clock 198 MHz [ 6.133433] RKNPU fde40000.npu: RKNPU: devfreq active (SCMI-only, OPP 200-1000 MHz) [ 6.134599] RKNPU fde40000.npu: RKNPU: thermal throttling enabled [ 6.139965] RKNPU fde40000.npu: RKNPU: sram region: [0x00000000fdcc0000, 0x00000000fdccb000), sram size: 0xb000 root@odroidtest:~#

So, For some Months I was trying to Use Latest Armbian on My Tx6S , First I found Nick Avollic's (Nick A) Armbian build that has my tx6s version supported the axp313 one but it was old (I can work with that though) but I wanted something that would support armbian latest.At first I tried to import directly from his repo but as he used miniarch patches it was difficult but somehow with some of ai assistantance I managed to made latest one but it was not on the latest stable kernal I used it for some time than now I thought why not get lastest kernal so After a lot of trail and error I finally managed to get latest Armbian and latest stable kernal working on my Tx6s.Its Also syncable to official armbian without issues . Github What's Working: Ethernet WiFi USB Ir-Receiver What's Not Working: Nothing,Right Now. Untested: Bluetooth (As my TV Box Doest Have Bluetooth So Its not possible for me to test) Downloads: Minimal Server [I do recommended people to build/compile their own image from sources and not to trust any random build on internet. You can build your own image from my forked githubs add-tanix-tx6s-axp313 branch your own image] In my test in CLI I found almost all the things working correctly.I will test the GUI/Desktop Interface later.

moved to tvboxes

Currently i need to find someone to be able to make a new driver stack for this box, I had already once ran weston successfully, got emmc boot but i didnt image the system, so it's now gone after i use apt commands(it replaced most of the files). I hope we will be able to fully utilize this box after someone made driver stack or ported drivers that are more compatible, I'll move on and leave this project behind, I will spend some of my free time to work on this, I'll update in the future. Maybe contact me if you want to help working on this. Software rendering works fine(kinda), it got bugs rendering and things on xfce, also fpt(the manufacture) only left some drivers for weston, maybe we can get other drivers for gpu acceleration from somewhere else, i dont really know. That's all i know for now

I created a fully automated TTN UDP Gateway installer for the Bobcat 300 (G285/G29X). Prerequisite: First install Armbian by following the instructions in the Bobcat-Armbian project: https://github.com/sicXnull/Bobcat-Armbian After Armbian has been installed, use the installer from my repository: https://github.com/AdvdLaar/Bobcat300-TTN Note: This installer is intended for TTN UDP Gateway operation only. It does not install or configure Helium. Features: Automatic detection of G285 and G29X hardware. Selectable TTN region (EU868, US915, AS923, AU915, IN865, RU864, CN470, JP923, KR920). Automatic Gateway EUI generation from the MAC address. No git clone required (downloads the repository as a ZIP using wget). Cleans up previous installations before installing. Verifies the SPI device and required files before continuing. Configures the packet forwarder automatically. Includes a showgatewayinfo.sh utility to display the configured Gateway EUI and TTN server. The installer has been tested on my Bobcat 300 G285 and performs a clean installation on an Armbian system without requiring any manual configuration. Many thanks to sicXnull for making the Armbian port possible. Without that project, this installer would not have been possible. Hopefully this is useful for others who want to convert their Bobcat into a TTN UDP Gateway. Have fun with your TTN gateway. Best regards, Ad

Great job. I have the same OPI5+. The fan has 3 pins. Can you tell me how to desolder the wires?

As for wifi, here's what I observe when the device is idle and being pinged from a laptop also on wifi. ``` 64 bytes from 192.168.68.66: icmp_seq=0 ttl=64 time=3182.692 ms 64 bytes from 192.168.68.66: icmp_seq=1 ttl=64 time=2182.085 ms 64 bytes from 192.168.68.66: icmp_seq=2 ttl=64 time=1181.659 ms 64 bytes from 192.168.68.66: icmp_seq=3 ttl=64 time=179.310 ms 64 bytes from 192.168.68.66: icmp_seq=4 ttl=64 time=3475.474 ms 64 bytes from 192.168.68.66: icmp_seq=5 ttl=64 time=2471.529 ms 64 bytes from 192.168.68.66: icmp_seq=6 ttl=64 time=1467.670 ms 64 bytes from 192.168.68.66: icmp_seq=7 ttl=64 time=463.009 ms 64 bytes from 192.168.68.66: icmp_seq=8 ttl=64 time=776.850 ms 64 bytes from 192.168.68.66: icmp_seq=9 ttl=64 time=10.257 ms 64 bytes from 192.168.68.66: icmp_seq=10 ttl=64 time=3492.560 ms 64 bytes from 192.168.68.66: icmp_seq=11 ttl=64 time=2491.066 ms ``` It repeats that fairly consistently, and has lower values when the device is actively doing something, eg: sending out pings to the router. It's like it only processes packets every 4 seconds. Best guess for now is some power management setting buried deep within the kernel and driver. Possibly only affecting my specific setup.

That is interesting, I would expect the other way around. I use 'btop' to watch clocks and load. On some systems, it also show GPU load and power consumption. Anyway, there is also the edge kernel (7.1.0-edge-rockchip64😞 linux-image-edge-rockchip64/trixie,now 26.5.1 arm64 [installed]

Apologies this seems to have posted twice could admin please delete one of them Hi all, I built an image for my new Odroid M2 16 GB board using the parameters in my config-odroid.conf BOARD=odroidm2 RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no Issued compile.sh odroid It built and booted first time I configured it using armbian-install to boot from the emmc and use a 1tb Samsung nvme as the system disk Rebooted after removing the sdcard Everything seemed to work until I tried to flash another image to the sdcard with dd The flash immediately stalled and killed my windows Putty session Some of the errors from dmesg mmc1: Card stuck being busy! __mmc_poll_for_busy dwmmc_rockchip fe2c0000.mmc: Busy; trying anyway mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80200000) GPT PMBR size mismatch (7675903 != 62333951) The primary GPT table is corrupt, but the backup appears OK. I have no idea what to do My intention was to try different images to ascertain which worked best which I can still do but i have to flash the card on another box I hope this makes sense Kind regards Pete Kane

Hi all, I built an image for my new Odroid M2 16 GB board using the parameters in my config-odroid.conf ``` BOARD=odroidm2 RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no ``` And issued compile.sh odroid It built and booted first time I configured it using armbian-install to boot from the emmc and use the 1tb Samsung nvme as the system disk Rebooted after removing the sdcard Everything seemed to work until I tried to flash an image to the sdcard with dd The flash immediately stalled and killed my Putty session Some of the errors from dmesg ``` mmc1: Card stuck being busy! __mmc_poll_for_busy dwmmc_rockchip fe2c0000.mmc: Busy; trying anyway mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80200000) ```

i got the same problem my ethernet is gone. how does one downgrade i cant figurer it out at all

More likely: friendlyelec is maintaining a separate patch (source code additions to the official ffmpeg), that allows it to do it. The code should be available in the friendlyelec github, to be shared with the public. "No v4l2request"... that means that they implemented another protocol and/or another kernel module to work with the video decoder.

Thank you for your reply. My H96 Max M9 is running Android 14 with the original stock firmware. I have not installed Armbian or any Linux-based operating system. Therefore, I don't think I can run sudo armbianmonitor -u on the TV box. Is there an equivalent way to collect and share the Android system logs, for example using ADB and adb logcat or dmesg? The problem appears when Android's system file picker/Storage Access Framework is used by applications such as PPSSPP and Dolphin Emulator.

moved to tvboxes

The board should have RT8821CU as wifi chip. Since Linux 6.17 there is no out of tree driver necessary anymore, mainline i used. So perhaps this is a an issue or regression upstream. You can try to switch to edge kernel, perhaps this has been addressed but not back-ported.

OK great that you got it working now! 2GB RAM works fine for HA, at least when running Supervised. I am not sure if Armbian can improve more when Supervised, as this is not supported anymore from the providers/developers of Home Assistant. I think a reason people go from SBC to Intel NUC is because there are things like VMware that IT pros might know from their profession/company. And RPL very long by default had/advised to use 32-bit also on more capable devices like RPi4 with 2GB RAM or even more. And also running from SD-card, and those wear out under high load and many writes. The whole problem with 'traditional RPi' is that it is unusual 32-bit ARMv6 build and not the standard 32-bit ARMv7 which is the minimum for support from Debian and most other distros. And in addition, 32-bit builds do not support the standard Linux Kernel Virtual Machine HW, standard in all 64-bit capable CPU's. Intel/AMD CPU's have support for HW virtualization also for 32-bit and much more known and commercial (also closed-source) hypervisors like VMware are pushed a lot more then the standard Linux build-in QEMU/libvirtd/KVM. So with 64-bit Linux, especially also on ARM, you get it by 'apt install virt-manager' and then you can run other OSses/images at full HW speed and is separated from the host OS, e.g. Armbian. Because images, many files or bigger databases are a burden for simple SD-card. Also because multiple OSses at the same time, it easily needs more RAM than the usual 1GB on SBC's like RPI3. Via virt-manager GUI and also CLI tool virsh, you can then run the generic UEFI bootable HAOS. For long-term and decent 24/7 operation, you will need SSD for storage. RPi's don't have that, you need adapters and HATs etc. But many other SBC's do have, so if you have an unused NVME for example, it fits perfectly in RK388 boards like ROCK5B for example. It is 4-lane PCI-E v3, so similar speed as Intel miniPC's. And most important, lower power consumption for similar total system price, at least before the RAM+storage prices went sky high. I measured my NanoPi-R6C with Samsung 970 NVME and Armbian Trixie (6.1.115 kernel) and is about 1.5 Watt when idle or doing some light tasks like running simple initial HAOS as Virtual Machine. See also:

You are not the 1st to do this: Let me explain the problem first. The CPU itself, without any storage attached, has a built-in U-Boot. However, this U-Boot does not initialize video output, so you won't be able to see it on an HDMI screen. (The good news is that it usually initializes the serial port.) This U-Boot reads environmental data from a data blob on the MMC (usually within the first 10 MB of the disk). This environmental data tells the U-Boot the sequence of commands needed for the MMC/USB U-Boot to boot. Once the MMC/USB U-Boot boots, you get video output. The problem is that you deleted the data blob containing the environmental data from the MMC, so the CPU's U-Boot does nothing. It just loops, saying that it found no device to boot. If you have a serial adapter, it is possible to interact with this CPU U-Boot. Pressing Ctrl+C (in a terminal that does not intercept Ctrl+C—my advice is to use PuTTY, even on Linux) should stop whatever it is doing. By interacting with this CPU U-Boot, you can instruct it how to boot your MMC or USB U-Boot. However, you will have to do this manually every time you boot. To fix the issue, you need to restore that data blob containing the properties to its specific location on the MMC. I don't know where it starts or what format it uses, so I was unable to recreate one from scratch. My way of fixing this was to find a backup of the original MMC and restore the first GB. So, did you make a backup? If yes, you can restore it with some serial magic. If you did not make a backup, you can search for one or ask someone who has one. (check that this thread for the other guy's solution)

Yes. commit 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 Author: EvilOlaf <werner@armbian.com> Date: Thu Feb 26 18:09:38 2026 +0000 rockchip64: 7.0: Rebase on top of main diff --git a/patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml b/patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml rename to patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml diff --git a/patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch b/patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch rename to patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch :