All Activity

This mode needs 80MHz pixel clock which is not in the table for clk-rk3568.c driver. You need a patch similar to https://lkml.org/lkml/2025/3/18/1337 to add this rate. FWIW 1280x800@63.59Hz isn't a very common mode

@jwillb00In this patch. Try changing 16 to 0. In both locations. Maybe I uploaded the image with these changes. https://github.com/NickAlilovic/build/blob/v20250306/patch/u-boot/u-boot-h616/153-add-tanix_tx6s_axp313_defconfig.patch +&mdio1 { + rmii_phy: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; +}; +

/_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Ubuntu stable (noble) Support: DIY (community maintained) IPv4: (LAN) 192.168.***.*** (WAN) ***.***.***.*** IPv6: *** Performance: Load: 4% Up time: 16 min Local users: 3 Memory usage: 45% of 971M Zram usage: 47% of 485M CPU temp: 46°C Usage of /: 11% of 58G RX today: 98 MiB Commands: Configuration : armbian-config Monitoring : htop *** System restart required *** Some packages require a reboot (gnome-shell) orangepi@orangepizero3:~$

Kernel crash on freshly installed image for LonganPi 3H. Image downloaded from: https://www.armbian.com/longanpi-3h/ Ubuntu 24.04 Noble. Sometimes it will crash few seconds after boot, before logging or doing anything. Didn't install or do anything, just apt-get update and upgrade. logs: https://paste.next.armbian.com/ocofepenup [ 1511.118664] Internal error: Oops: 0000000096000044 [#1] SMP [ 1511.124251] Modules linked in: sunrpc rtl8xxxu mac80211 cfg80211 sunxi_cedrus(C) rfkill libarc4 v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videodev videobuf2_common polyval_ce sun50i_h6_prcm_ppu mc polyval_generic dump_reg cpufreq_dt zram zsmalloc binfmt_misc sch_fq_codel fuse dm_mod realtek sun6i_rtc_ccu dwmac_sun8i mdio_mux [ 1511.155156] CPU: 1 UID: 0 PID: 2658 Comm: sshd Tainted: G WC 6.12.23-current-sunxi64 #1 [ 1511.164459] Tainted: [W]=WARN, [C]=CRAP [ 1511.168292] Hardware name: Sipeed Longan Pi 3H (DT) [ 1511.173166] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1511.180124] pc : enqueue_timer+0x3c/0x150 [ 1511.184141] lr : __mod_timer+0x30c/0x370 [ 1511.188063] sp : ffff800085a13920 [ 1511.191376] x29: ffff800085a13920 x28: 00000000000005a8 x27: 0000000000000000 [ 1511.198514] x26: ffff8000821f6000 x25: 0000000000000001 x24: 0000000100049ec4 [ 1511.205652] x23: 000000000000000c x22: ffff0000ff760000 x21: 0000000100049ecc [ 1511.212789] x20: ffff0000ff760000 x19: 0000000100049ec4 x18: 0000000000000042 [ 1511.219926] x17: 85a0e7cbaf550a08 x16: 01010000d9864102 x15: 1880ada177e5cf73 [ 1511.227064] x14: 54c33ab316000103 x13: 6a5d85a0e7cbaf55 x12: 0a0801010000d986 [ 1511.234201] x11: 41021880ada177e5 x10: cf7354c33ab31600 x9 : ffff800080125244 [ 1511.241341] x8 : ffff800080b33870 x7 : ffff0000ff7600d0 x6 : ffff800082201980 [ 1511.248479] x5 : 000000000000000c x4 : 000000000000000c x3 : 0000000100049ecc [ 1511.255617] x2 : ffff0000ff760070 x1 : 0000000000000000 x0 : ffff0000ff760000 [ 1511.262756] Call trace: [ 1511.265204] enqueue_timer+0x3c/0x150 [ 1511.268868] __mod_timer+0x30c/0x370 [ 1511.272444] mod_timer+0x1c/0x30 [ 1511.275673] sk_reset_timer+0x28/0x98 [ 1511.279339] tcp_schedule_loss_probe.part.0+0x13c/0x270 [ 1511.284567] tcp_write_xmit+0x320/0x1390 [ 1511.288492] __tcp_push_pending_frames+0x44/0x108 [ 1511.293197] tcp_push+0xbc/0x168 [ 1511.296431] tcp_sendmsg_locked+0xa14/0xc38 [ 1511.300616] tcp_sendmsg+0x40/0x70 [ 1511.304021] inet6_sendmsg+0x4c/0x78 [ 1511.307599] __sock_sendmsg+0x64/0xc0 [ 1511.311265] sock_write_iter+0xa8/0x118 [ 1511.315102] vfs_write+0x334/0x3b8 [ 1511.318508] ksys_write+0xf8/0x120 [ 1511.321911] __arm64_sys_write+0x24/0x38 [ 1511.325835] invoke_syscall+0x50/0x120 [ 1511.329590] el0_svc_common.constprop.0+0x48/0xf0 [ 1511.334296] do_el0_svc+0x24/0x38 [ 1511.337615] el0_svc+0x30/0xd0 [ 1511.340675] el0t_64_sync_handler+0x120/0x130 [ 1511.345034] el0t_64_sync+0x190/0x198 [ 1511.348703] Code: a9025bf5 aa0003f6 aa0303f5 f8657841 (f9000261) [ 1511.354794] ---[ end trace 0000000000000000 ]--- [ 1511.359410] note: sshd[2658] exited with irqs disabled [ 1571.130516] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 1571.136471] rcu: 1-...0: (7 GPs behind) idle=ad6c/1/0x4000000000000000 softirq=10876/10876 fqs=6851 [ 1571.145603] rcu: (detected by 2, t=15004 jiffies, g=19153, q=1042 ncpus=4) [ 1571.152564] Sending NMI from CPU 2 to CPUs 1: [ 1581.152989] rcu: rcu_sched kthread starved for 555 jiffies! g19153 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=0 [ 1581.167420] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. [ 1581.176371] rcu: RCU grace-period kthread stack dump: [ 1581.181418] task:rcu_sched state:R running task stack:0 pid:17 tgid:17 ppid:2 flags:0x00000008 [ 1581.192290] Call trace: [ 1581.194738] __switch_to+0xe8/0x150 [ 1581.198235] 0x0 [ 1581.200080] rcu: Stack dump where RCU GP kthread last ran: [ 1581.205561] Sending NMI from CPU 2 to CPUs 0:

hey @Nick A, seems like when I build the image on my own the ethernet doesn't work? I tested with and without the modified kernel config and it happens either way. When I use the image you publish in the releases page, it works fine. Am i doing something wrong?

I would like to use my device as a VPN client, i.e. connect to a remote OpenVPN server. How can I enable the Tun/Tap module on my board?

Also need someone to test this: https://fi.mirror.armbian.de/incoming/igorpecovnik/orangepizero3/archive/

Thanks both!

Ok! Are you ready to test it?

Yes. And we will keep fork maintained as long as possible. https://community.home-assistant.io/t/feedback-requested-deprecating-core-supervised-i386-armhf-armv7/880968/313

Home Assistant supervised will be deprecated: https://www.home-assistant.io/blog/2025/05/22/deprecating-core-and-supervised-installation-methods-and-32-bit-systems/

Any up to date Armbian image using vendor kernel should include rknpu kernel driver oob. Mainline npu driver is still pending. You can try to backport it. Check rockchip kernel mailing list.

Hi We all started at some point. But overall prepare for some frustration We don't support this device. Support was added via community effort. May work, maybe not. We don't know nor do we track status of such configurations. Regarding OPi5+. It is using - in terms of ARM socs - a fairly recent SoC, the Rockchip RK3588. Mainline support is far from feature-complete. Will take a few additional years to complete. If you need an almost feature-complete kernel, you have to use vendor branch which is based on Rockchip BSP. current (Linux 6.12.y LTS at this time) has basic support for rk3588 and is good enough for general server application, though for your usecase might not be enough. This branch will receive fixes only but no new features. edge may be sufficient. When using some graphics related I suggest to use an image with mesa-vpu extension included. Also there a two ways to make use of it: - We backported the open source Panthor driver into vendor. Can be enabled via device tree overlay (check code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-config) - Using proprietary mali blobs is also possible. I think Jellyfin has a tutorial how to setup those: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/

Hello all, I'm also bought an orange pi 5 pro :-) I have red a little bit in the Forum (after i'm bought) and I'm a little bit confused now 🙂 I'm new in the embedded (arm) world but have some knowledge from the desktop/x86 windows & linux world. my first expirience with the device was also .... intresting. I'm installed the official (orangepi.org) debian-booksworm image with the 6.1.xx kernel .... and diddnt get the network interfaces to run, and no nvme device available ... next try was with debian-booksworm image and the 5.10..xx kernel and the networks just runned and the nvme showed up. But i think for my need this kernel is just old ... So now im trying armbian (iot version) ..... at the moment with an 6.1.99 vendor kernel. installed weston seatd & co for running some rudimentary OpenGL ES based tests .... but without success. glxgears / glxinfo failing EGLInitialize() cannot create context ... rknpuxxxx.so not found. i think thats the "which /dev/dri device is the right" issue. Have also red that some HW functionally is only available on full blown desktop environments 😞 What do I need: - i dont want to use the device as a desktop replacement - i want to use it as development board for tinkering around with OpenGL ES / OpenCL and get some experience with embedded development. - rudimentary boot2qt functionality based on wayland-egl or eglfs platform (running Qt apps in wayland cage or without window manager) - good opengl es 3.2 support - recent compiler support, gcc13(+) / clang 18 - boost / qt 6.7 + should available as devel packages (don't like to build it for my own, but if its necesarry ...) - opencl support would be nice - media / audio support (QMultimedia) - atm i dont need video acceleration, but maybe later .... So my question: with which Kernel / System should i start with ? is the device a good choice ? I bought it mainly because the 2 nics and the available storage options (nvme / emmc) makes it very flexible for another usage (router backup i.e) Soon or later i have to dig into yocto also maybe ....

I've extracted dtbs from my rooted device bqeel K12, could it be useful share them? @RuDy_74 I've used "Magicsee C400 Plus" dtb (I don't remember the exact name) and I got also wifi and bluetooth working. The only issue is ethernet working at 100Mbit instead of 1Gbit

Still the same with armbian 25.2.3 kernel: 6.12.22-current-rockchip64 #1 SMP PREEMPT Mon Apr 7 08:08:37 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux u-boot-version: # cat /dev/mtd/by-name/U-Boot | strings | grep -B1 "u-boot,version" 2025.01-armbian-2025.01-S6d41-P41ad-H4cab-V390e-Bb703-R448a u-boot,version WARNING: could not set u-boot,version %s. # iperf3 -R -c odroidm1 Connecting to host odroidm1, port 5201 Reverse mode, remote host odroidm1 is sending [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 79.2 KBytes 649 Kbits/sec [ 5] 1.00-2.00 sec 84.8 KBytes 695 Kbits/sec [ 5] 2.00-3.00 sec 206 KBytes 1.69 Mbits/sec [ 5] 3.00-4.00 sec 228 KBytes 1.87 Mbits/sec [ 5] 4.00-5.00 sec 115 KBytes 938 Kbits/sec [ 5] 5.00-6.00 sec 181 KBytes 1.48 Mbits/sec [ 5] 6.00-7.00 sec 163 KBytes 1.33 Mbits/sec ^C[ 5] 7.00-7.36 sec 9.90 KBytes 226 Kbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-7.36 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-7.36 sec 1.04 MBytes 1.19 Mbits/sec receiver when changing u-boot back to older u-boot (same kernel), it works as expected # cat /dev/mtd/by-name/U-Boot | strings | grep -B1 "u-boot,version" 2023.04-00035-g7dd5eb0228 u-boot,version WARNING: could not set u-boot,version %s. # iperf3 -R -c odroidm1 Connecting to host odrdoidm1, port 5201 Reverse mode, remote host odroidm1 is sending [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 110 MBytes 921 Mbits/sec [ 5] 1.00-2.00 sec 110 MBytes 926 Mbits/sec [ 5] 2.00-3.00 sec 110 MBytes 926 Mbits/sec [ 5] 3.00-4.00 sec 110 MBytes 921 Mbits/sec [ 5] 4.00-5.00 sec 111 MBytes 929 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 927 Mbits/sec [ 5] 6.00-7.00 sec 110 MBytes 919 Mbits/sec ^C[ 5] 7.00-7.79 sec 87.0 MBytes 925 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-7.79 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-7.79 sec 858 MBytes 924 Mbits/sec receiver iperf3: interrupt - the client has terminated ethtool output: ~# ethtool end0 Settings for end0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes

I upgraded my ROCK5B in-place from Armbian Bookworm beta to Armbian Testing/Trixie beta and it turns out that no Ambian packages are seen (so not updated). The Debian Trixie packages do upgrade, as for example I just saw while doing full-upgrade: libavif16:arm64 (1.2.1-1.2) over (1.2.1-1.1) ... I thought something with my install, but also downloaded 'Armbian_25.8.0-trunk.50_Rock-5b_trixie_vendor_6.1.115_minimal.img' yesterday and it has the same issue (quick test via systemd-nspawn container on loopdev mounted image). My goal is at least to figure out what is best bootloader and kernel for the ROCK5B. So far I simply copied/cloned Armbian Bookworm rootfs from ROCK3A+NanoPi-R6C and did some ROCK5B specific changes like U-Boot, but not much more and it actually is already good enough. But before the ROCK5B becomes a 24/7 headless workhorse with long uptime, I thought better to prepare/check for newer Linux or potential issues. I already upgraded some other devices from Bookworm->Trixie and that is quite an improvement, for example KDE 6 performs much better/nicer than KDE5 in Bookworm. It currently uses U-Boot 'edge' and 'current' kernel and very important for me, both the 'vendor' and 'mainline current/edge' overlay for SERDES multi-PHY SATA on the M.2 E-key work (and also the NVMe keeps working). I need to drill a hole in the Radxa aluminum cooling case for the SATA cable (and serial console cable), that needs some time first. I can build and install U-Boot and kernel etc manually of -course, but i wonder why Armbian packages are not visible. Is it as expected or is something wrong? I assume it is just too early yet and that it is work in progress. I think maybe policies are an issue, but don't understand what it could be. Maybe someone has a hint. root@rock-5b:~# apt policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://deb.debian.org/debian trixie/non-free-firmware arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=non-free-firmware,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/non-free arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=non-free,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/contrib arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=contrib,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/main arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=main,b=arm64 origin deb.debian.org 500 https://beta.armbian.com trixie/trixie-desktop all Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-desktop,b=all origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-desktop arm64 Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-desktop,b=arm64 origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-utils all Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-utils,b=all origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-utils arm64 Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-utils,b=arm64 origin beta.armbian.com 500 https://github.armbian.com/configng stable/main arm64 Packages release o=armbian.github.io/configurator,n=stable,l=armbian.github.io/configurator,c=main,b=arm64 origin github.armbian.com Pinned packages:

From the information of DietPi users, it appears that they have used UBoot v2025.04 for Orange Pi Zero 3 and it seems that the problem of incorrect detection of RAM size has been solved, especially in the version with 1 MB. It would be valuable if ArmBian was also transferred for Orange Pi Zero 3 to Uboot v2025.04, we could avoid complications during system updates and other processes that need a lot of RAM causing the system to hang up because they try to use memory addresses that are not physically there when the RAM size was incorrectly identified during booting. More info about UBoot v2025.04 with Orange Pi Zero 3: https://github.com/MichaIng/DietPi/issues/7242#issuecomment-2912290816

I am using rk3588-sd-debian-bookworm-core-6.1-arm64-20250123.img.gz It is excellent asides from lacking NPU support. Before I go down the path of learning kernel compilation and scanning poorly documented Rockchip repositories, has anyone got a current version of Armbian that includes NPU support? If not, is there any good guide to using a cross-compile system and integrating third part drivers?. On a slightly different topic I would prefer to not use fuse file systems and run off the NVME drive directly. Are there any resources on this?

the issue about can't be recognized has been fixed，but the p2p mode still can't work

I tried the image from "armbian.atomonetworks.com" and the exact same thing happens. Thanks, I'll compare the images.

I ran compile.sh and got an error message which looked weird It couldn't find the directory .tmp/work-3efc55a6-9478-4508-91c4-5637c4b1e593 and would stop all work I created the directory and then it worked What the heck is that about? My linux x86 system is gentoo and not debian. I do have debian in vmware fusion on my mac. I use it to chroot my gentoo arm systems since it is much faster than cross compiling. For fun I tried again on a different directory and got a new error message This time it is .tmp/work-032fc96c-9055-4b10-86a8-b46b65980a11 The board I try to work with is YY3568 The problem doesn't seem to appear if I don't ask to let me change the kernel configuration

I do not understand what is "not working". Please elaborate. Also, providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

are you sure all storage devices are working without issues?