All Activity

I don't know anything about this patch, but check this: * Linux version you are using, vs Linux version corneliius has used * Try deleting the hunk in the patch that caused the problem you saw, and see if other hunks cause patch failures * If it is only one hunk causing the problem, look at the file that is affected by the patch drivers/auxdisplay/Makefile: do the lines mentioned in the hunk exist in the Makefile? In the expected line number?

Well apparently it is an issue, as stated above by @JFL. Also, after a RECALL, I'm the one who did the PR to change it from =y to =m. https://github.com/armbian/build/pull/8300/commits/bb71177580b34c1aeaeb601696d603b6dc49d326 As for udev and delay, you could edit the udev system file; /lib/udev/rules.d/50-udev-default.rules The line you want to edit is about 15 lines down. Change from rtc0 to rtc1.

Interesting. I wonder how the FriendlyElec stock kernel is assembled, because according to the log the stock system doesn’t use any Rockchip clock—only the HYM8563.

No issue, because it would behave the same as the default Rockchip system clock. Moreover, by default `fake-hwclock` is running, so after connecting a battery the user would just need to uninstall `fake-hwclock`. That shouldn’t be a problem.

I am trying building image natively on orangepiplus, but the scripts are not designed to complete it. System incompatibility, lack of packages for this distribution etc make it fail. How do you manage building it with this Armbian's official building tool ? I am very curious to discover the right approach as I need adding in-kernel modules, which you can't build as stand alone. At the same time, where can u-boot be downloaded from? I understand, that it was updated in 2024 : [🌿] {u-boot:1} Preparing u-boot targets packaging [ 2024.01 ] [🌿] {u-boot:1} Deploying u-boot binary target [ 2024.01 :: u-boot-sunxi-with-spl.bin ]

Hello again, Yes, I read the documentation, that's why I said my UART adapter doesn't work and I ordered a compatible one which is on its way. I managed to somehow solve my issue. Luckily I had another SSD lying around (Kingston) which works without any issue and is recognized every time and bootable. My original SSD (Crucial) has no hardware problems though, because I used it in an x86 Ubuntu machine and works without any problem whatsoever. So although I managed to solve my situation, the underlying problem is still there and may re-surface to someone else. I would like to re-state that the 25.5.1 armbian desktop does not even boot (edge or vendor) and the 25.2.2 boots but barely works on my board. Thanks for the time. PS. I ended up using JR ubuntu, because although non-supported anymore, it was the only one working. If you find my situation is worth further investigation and you would like to look into it, I can send you the serial logs once I get the proper adapter.

Same issue on Orange Pi 5, it used to start fast then hangs for ~ 1mn after some upgrades. systemd-analyze blame 1min 31.472s plymouth-quit-wait.service 25.068s apt-xapian-index.service 2.713s NetworkManager-wait-online.service 1.086s xrdp.service 1.074s NetworkManager.service 604ms snapd.seeded.service 538ms dev-nvme0n1p1.device 501ms snapd.service

On orangepi-5-plus without RTC battery setting `CONFIG_RTC_DRV_HYM8563=y` will cause the CPU Loadaverage to be always greater than 1. The rockchip64 kernel currently use `CONFIG_RTC_DRV_HYM8563=m` and blacklist rtc_hym8563 resolved the high CPU loadaverage.

Hi! Great to see Odroid C1 is being maintained again! Since I am using C1 for many years in my homelab I've given it a try. Unfortunately, after some time under heavier load I start to receive errors, system files becomes unreadable or straight kernel panic: The SD card is all right, tried different ones, checked cooling, applied fresh paste etc. Nothing. On the other hand, I've run this board for years with uptimes measured in months with rocksolid 5.11 build by @balbes150 from this thread: Since download links there are not available anymore, I share mine /boot/ here, maybe it will help somebody: https://mega.nz/file/nVdjFKSD#zGGyDAJ5YHEY3clyezbHUHMhsItgpzTyvW0Y9uKFVNQ I've went back to this kernel and it is stable again. Doing well with current stable trixie even. Could you use it to investigate stability issues? Or maybe @balbes150 could share his old patches with current maintainers? Thanks for your hard work, I appreciate it!

Has anyone been able to use the remote control that comes with the tv bos under Armbian? Does it reqire additional driver(s)? I want to run Kodi (or any better mediacenter) under Armbian.

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.