Active threads

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

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.

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

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

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!

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.

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

Sorry for being late to the party on this, but I can confirm that rockchip is better supported than Amlogic. My old Android 7 1GB/4GB MXQ TV box works great out of the box with the latest build after installing the step-nand loader.This is a rockchip 32xx build, great menu-driven setup tools, literally working within 15 minutes. Kudos to Jock and co. This is a hobby for me, I'm more interested in learning Linux than having a home server doing real work, I thought about SBCs but pi looked like a boy scout project and other SBCs too expensive with features I don't need. Modern MXQ boxes are cheap and my online vendor has a great return policy, so why not? I just ordered an updated box with 4GB ROM for $10. Running with a class 10 64GB SD card, this will be another fun opportunity. Take care!

Hi all, I’m working with an RK3588-based board and running into a frequency scaling issue. All cores (cpu0–7) are stuck at 408 MHz, despite available OPPs going much higher (up to 2.35 GHz on the big cores). Attempts to raise frequencies via scaling_setspeed or userspace governor have no effect. The image I'm using is: https://www.armbian.com/nanopc-cm3588-nas/ (https://dl.armbian.com/cm3588-nas/Bookworm_vendor_minimal-omv) Device tree file is: fdtfile=rockchip/rk3588-friendlyelec-cm3588-nas.dtb # for cpu in /sys/devices/system/cpu/cpu[0-9]*; do echo "== $(basename $cpu) ==" cat $cpu/cpufreq/scaling_available_frequencies cat $cpu/cpufreq/cpuinfo_max_freq done == cpu0 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 1800000 == cpu1 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 1800000 == cpu2 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 1800000 == cpu3 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 1800000 == cpu4 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000 2352000 == cpu5 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000 2352000 == cpu6 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000 2352000 == cpu7 == 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000 2352000 root@cm3588-nas:/# Getting DVFS/EM kernel message about inefficient OPP: [ 14.038585] cpu cpu0: EM: OPP:816000 is inefficient [ 14.048575] cpu cpu4: EM: OPP:1008000 is inefficient [ 14.048584] cpu cpu4: EM: OPP:816000 is inefficient [ 14.060709] cpu cpu6: EM: OPP:1008000 is inefficient [ 14.060718] cpu cpu6: EM: OPP:816000 is inefficient PVT readings [ 14.002363] cpu cpu0: pvtm=1425 [ 14.002523] cpu cpu0: pvtm-volt-sel=1 [ 14.011254] cpu cpu4: pvtm=1645 [ 14.015591] cpu cpu4: pvtm-volt-sel=3 [ 14.025824] cpu cpu6: pvtm=1665 [ 14.030065] cpu cpu6: pvtm-volt-sel=3 Attempting to raise speed: # for cpu in /sys/devices/system/cpu/cpu[0-9]*; do echo 1800000 | sudo tee $cpu/cpufreq/scaling_setspeed; cat $cpu/cpufreq/scaling_cur_freq; done 1800000 408000 1800000 408000 1800000 408000 1800000 408000 1800000 408000 1800000 408000 1800000 408000 1800000 408000 Why might all cores be capped at 408 MHz despite available OPPs and voltage steps?

might be hard to find such an old image even from the archive why not one of the newer ones? https://www.armbian.com/cubox-i/

armbianEnv.txt sets parameters for the U-Boot bootloader. In theory you can also manually type it all via serial console at U-Boot prompt. Separating boot and rootfs is independent of that. If you use Ext4 for bootfs, you can make hardlinks (or symlinks). That is also what is done by kernel install script if /boot is on Ext4, else copies are done (when FAT).

I've now exhausted all practical options. I guess that the 6.15.4-edge-sunxi kernel was built with GCC plugins and BTF settings that cannot be reproduced with out-of-tree module builds. Even using the cross-compiler (arm-linux-gnueabihf-gcc-13) did not help — because the issue is not the compiler binary, but the entire build environment: CONFIG_DEBUG_INFO_BTF_MODULES=y GCC_PLUGIN_RANDSTRUCT or STRUCTLEAK ftrivial-auto-var-init=zero TLS guard offset (-mstack-protector-guard-offset=1464) Kernel symbol versioning These change the binary layout of struct module, making any externally built module incompatible. The question now, how could a missing module be added to a running system ! It is almost improbable, that development path is completely blocked and requires tedious efforts for adding a simple already existing module. In the meantime, while the right approach is being looked for, could somebody point to a "pull request" procedure?

Find a DTS that uses compatible="waveshare,rpi-lcd-35" and try again (I don't use that LCD, so I am not sure... but I know it is special because it contains a SPI-to-parallel chip)

https://linux-sunxi.org/Tanix_TX1 Piotr's github is easy enough to google for those who need it.