All Activity

For those without a battery connected wouldn't this be an issue?

This device is community-maintained. Armbian core team does not monitor its status nor gets involved into development here. However anyone from the community can step up and send fixes. I saw some stuff upstreamed from time to time for 5 ultra and max, hit somewhere between 6.16 and 6.18 I guess. When rockchip64 gets bumped further they will be available for these boards. Since mainline is still under development though sticking with 6.1.y vendor kernel isn't a bad option since most things work here.

Quite possible, actually expected as there is no support for current kernel: https://github.com/armbian/build/blob/main/config/boards/orangepi5pro.csc#L8 and build target is not maintained by core Armbian team https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained

We have been stuck on version 6.1 for almost half a year ever since the initial attempt to migrate to 6.12 caused some issues with HDMI if I remember correctly. Anyone knows if 6.12 or 6.14 are still in the works for this SBC? Thank you!

I have a different Orange PI board, but I have two partitiions of Armbian installed (25.8.1), one with the edge kernel, the other with the current (mainline) kernel. I checked my /boot/dtb/rockchip/ directories in each for the Orange PI 5 Pro, and there is a device tree for it with the edge kernel (rk3588s-orangepi-5-pro.dtb), but not with the current kernel. Perhaps a question would be: Is that devicetree (.dtb file) being utilized with the edge kernel? Might be worth looking into.

Thanks for the help. But the moment when the RTC is symlinked does matter. I mean, if the symlink changes too late, some services (for example, NTP synchronization) may be affected. I use specific software that starts as a service and immediately begins logging its activity. So if the system time changes significantly during boot, it causes problems for this software. I think this is a much better and more proper solution

sources are defined per board family, in your case sunxi:https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc Before attempting u-boot for a whole family I suggest to do some small scale tests at board level first by setting an override in the board config file. Example for a different board:https://github.com/armbian/build/blob/a7c19f1e35a65daf42f090ecc34ee1151ee6db23/config/boards/orangepi5-plus.conf#L31-L52

Finally able to solve the problem. The aic8800 wifi modules and others associated with the wifi driver are deleted when upgrading the kernel. I found Debian packages on radxa's github site downloaded the firmware and usb modules and then reinstalled them from the /tmp directory after kernel upgrade but before rebooting. While this does work, it is a sloppy hack. It seems to me that there ought to be some way to retain the wifi drivers on upgrade, but it will take a more knowledgeable person to do that. The same hack allows the wifi on the Rock-2A to survive a kernel upgrade. Wired Ethernet of the Rock-2A survives a kernel upgrade without issue.

I further expanded kernel because VPN clients like twingate needed a module `tun` more on this here https://github.com/defencedog/orangepi4A/tree/main/kernels#update-2

When tweaking Armbian’s Build System I understand that it also builds u-boot and updates it when new sources are available. I understand, that the last one was updated on : [🌿] {u-boot:1} Cleaning u-boot tree [ u-boot-worktree/u-boot/v2024.01 for '' ] [🔨] [Mon Aug 25 11:11:25 PM CEST 2025] Running: git --no-pager clean -xfdq [🌱] Calling Python patching script for U-Boot: [ https://github.com/u-boot/u-boot - tag:v2024.01 ] [🌱] Using U-Boot patch dir: [ u-boot-sunxi ] Where is the latest build could be downloaded from and what is its flash procedure and recovery (if necessary) ?

Keep up the fight, good luck!

I am glad to hear of your success Beware that edge is the bleeding edge and where we break things. Vendor is the one the board maker supplied you with, most likely outdated and hacked up. You are usually best off with the current kernel, except of course when there was some recent hardware enablement work going on in the edge kernel for your work.

@Nick A Thanks for bringing that to my attention, I'll try that!

Please read the documentation on the manufacturer's website (radxa). It really works.

If you want to find a request, please publish the UART log. maybe after that we can say recommendations.

Thank you @royk, @going, @eselarm for your time and suggestions. I really appreciate it. I tried a lot of things, you mentioned, out of which none was working. Again, ultimately I wanted to install noble gnome, but the 25.5.1 image doesn't boot at all. So I found the older 25.2.2 noble gnome and that did indeed boot and I was able to proceed. Interestingly this image seems to consistently detect the nvme every time. That being said, it acts very weirdly. it's extremely slow to the point that you can barely open any app, it takes a minute to change a page in settings, and sudo basically is not working (hangs indefinitely). The desktop / workspaces / app launcher are very smooth though and htop shows all 8 cores practically at idle. Also when I boot, it first shows the splash screen (armbian loading), and then goes black indefinitely and I have to press the power button to go to the login screen (looks like it suspends after boot immediately). Poweroff doesn't work either, it hangs. With this weird situation I was able to install the bootloader into the SPI, but I wasn't able to do an upgrade or install the full system on the nvme. Do you have any input on this? Some additional notes: - All of the tests above were done with a brand new sandisk 64gb SD + balenaetcher with verify on macos. - I've also tried Joshua Riek's 24.04 image and although it has the nvme issue, the OS runs very smoothly without any lag. - Although the noble gnome image seems to consistently find the nvme, the minimal 25.5.1 image does not. - My UART adapter doesn't work and a CH340 one is on it's way for boot logs.

That would be good. Cubox-i has standard microUSB connector for serial console, so its easy. That would give some insights on what is happening.

@Igor thanks for the reply. In my case, I can't even ping the Cubox much less connect to it. I'm pretty sure something is failing as the device reboots itself every ~ 2 minutes; each time I see the initial boot with logo on the HDMI, then the screen goes blank, then my monitor claims that HDMI signal is lost, then nothing (including no successful pings) for a couple of minutes, then around again. I've ordered some new SD cards and a USB SD card reader writer which should arrive Wednesday. Maybe things will improve after that. If not I will try a serial connection via USB. I will report back.

This solution feels janky [specifically, netplan-runner.service shouldn't be needed] But... it works. netplan-macaddress-watcher.path [Path] PathChanged=/run/systemd/network/ Unit=netplan-macaddress-watcher.service [Unit] Before=systemd-networkd.service #[Install] #WantedBy=systemd-networkd.service netplan-macaddress-watcher.service [Unit] Description=Rewrites /run/systemd/network PermanentMACAddress to MACAddress Before=systemd-networkd.service network-pre.target [Service] Type=oneshot User=root ExecStart=/bin/bash /usr/local/bin/netplan-macaddress-mangler.sh netplan-runner.service - it runs netplan as late as possible... [Unit] Description=Runs netplan right after boot After=multi-user.target [Service] Type=oneshot User=root ExecStart=/usr/sbin/netplan apply [Install] WantedBy=multi-user.target netplan-macaddress-mangler.sh - This will need to be renamed if published/packaged. #!/bin/bash -x # can we use $TRIGGER_PATH ? https://man.archlinux.org/man/systemd.exec.5.en # no, we can't, it only tells us the directory, not which file was changed. #FIXME: can we skip this for initial boot? sleep 5; # coalesce the calls /usr/bin/sed -i -e 's/^PermanentMACAddress/MACAddress/' /run/systemd/network/*netplan*.{link,network} #echo -n "networkd is: " if systemctl is-active systemd-networkd >/dev/null; then networkctl reload fi

@OleksandrK Would changing the symlink suffice? ls -ls /dev/rtc* 0 lrwxrwxrwx 1 root root 4 Aug 25 11:14 /dev/rtc -> rtc1 0 crw------- 1 root root 252, 0 Aug 25 11:14 /dev/rtc0 0 crw------- 1 root root 252, 1 Aug 25 11:14 /dev/rtc1 echo 'SUBSYSTEM=="rtc", KERNEL=="rtc1", SYMLINK+="rtc" OPTIONS+="link_priority=-100"' | sudo tee /etc/udev/rules.d/10-hym8563-rtc.rules This way both get loaded, but /dev/rtc is linked to rtc1 "hym8563".

Hi, I can confirm I got a booting SD card with the suggested command. I ended up using the following: ./compile.sh BOARD=orangepi5pro BUILD_DESKTOP=no BRANCH=edge RELEASE=bookworm KERNEL_CONFIGURE=no BUILD_MINIMAL=yes SHARE_LOG=yes Thank you very much @laibsch. Cheers! P.S. I ended up buying a USB-UART adapter as you suggested in another thread to test another orange pi 5 board I have but it seems that one is dead.

Any chance to get this new and great version on Oragepi3LTS working? I've got armbian-config.sources identical to what is described in user documentation above but still get probably old script version installed - with no additional menu items and, particularly, different name of Disable upgrades as follows: which, in turn, doesn't work for me anymore - nothing changes after I choose "Yes" at question "Disable?" and system has (according to apt-mark showhold) quite old kernel images holded while new updates keep coming and install... Thank you in advance for any suggestions. I know it's community-maintained image for Oragepi3LTS but hope there is some workaround for armbian-config

Philosophy behind installations via armbian-config is that install is simple as possible, thus options are limited and hard-coded. Main folder for SW data is /armbian and there you mount additional space, if needed. If this way is not acceptable, you need to go manual way. Installing Redis, PostgreSQL and Immich, then link then together. It will be some work and there will be some troubles. Official: https://immich.app/docs/install/requirements Unofficial: https://github.com/imagegenius/docker-immich Armbian way: https://docs.armbian.com/User-Guide_Armbian-Software/Media/#immich

@Nick A thank you for your advice

On other platforms we can usually set an alias in the DTS for the rtc. On RK I'm not seeing that as an option, but what we can do is make it so one module loads before the other. In short, we set `CONFIG_RTC_DRV_HYM8563=y` and leave `CONFIG_RTC_DRV_RK808=m`. Which will force a hierarchy in the way things load. Case in point; patrick@nanopir3s:~$ dmesg | grep rtc [ 4.646223] rtc-hym8563 1-0051: registered as rtc0 [ 4.647295] rtc-hym8563 1-0051: setting system clock to 2025-08-25T01:34:16 UTC (1756085656) [ 5.548534] rk808-rtc rk808-rtc.5.auto: registered as rtc1 [ 5.605731] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 5.605810] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes We may also be able to achieve this with a udev rule? I'll do a PR after further testing.