All Activity

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.

@Ducdanh Nguyen I don’t write the mainline linux kernel or patches. You should ask the sunxi developers or Piotr Oniszczuk aka warpme. Allwinner does not support open source mainline Linux. Most of the work is reversed engineered by a very few smart people that give their free time to Linux community. Android uses a very old modified Linux kernel so it takes a lot of work to update drivers. Sometimes these drivers have no source code or documentation. tv boxes are a whole different beast. Components are cheap. If you buy the same model tv box they might have different wifi, memory, emmc chips and sometimes the cpu is not allwinner at all. if you want to have a perfect running tv box you’ll need to learn how to tweak the dts and edit the Linux kernel source code. https://oftc.catirclogs.org/linux-sunxi/2025-08-24 https://github.com/warpme

'for kernel in current edge vendor;do ./compile.sh BOARD=orangepi5pro BUILD_DESKTOP="no" BRANCH=$kernel RELEASE=noble KERNEL_CONFIGURE=no BUILD_MINIMAL=yes SHARE_LOG=yes;done' should do it, for example. That would get you an image with an Armbian-patched kernel of the current, edge and vendor flavor. It's really THAT simple :-D

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 everyone, Sorry to bother you with what may be a basic question. I’m not very experienced with the Armbian build system, and it’s been a while since I last built and deployed my own kernels. I’ve been trying to compile both the current and edge branches without success. I did get vendor working. I came across this post but I’m still unclear on the exact steps. Could someone please give me a simplified explanation of: What needs to be done to successfully compile these branches? Where I can get the latest patches, and how to apply them? Whether I also need to rebuild U-Boot with the Armbian build system. Thanks a lot in advance for your help!

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?

HDMI output might be broken on this kernel - mainline support is still fragile, perhaps for this board there is no device tree yet and it fails early.

Connected via SSH. DHCP client is automatically getting IP, so you should be able to find the device on network after few minutes ... in case HDMI output is really broken. I can't test that as device is stashed to some rack.

follow http://debug.armbian.de

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/

Hi, I have attempted to boot with edge and current branches with no success. I am now trying vendor since its what its running. My process is: ./compile.sh BOARD=orangepi5pro BRANCH=current kernel-config I enable tunneling GRE and some broadcom wifi drivers. ./compile.sh BOARD=orangepi5pro BRANCH=current kernel sudo dpkg -i output/debs/linux-image-*.deb sudo dpkg -i output/debs/linux-headers-*.deb sudo dpkg -i output/debs/linux-dtb-*.deb sudo reboot and after this the system does not boot or post through HDMI. I have to go back and erase /boot and restore a backup to be able to get it working again. What am I missing? P.S. I have /boot partition in SD card and the system partition is in an NVME drive.

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 have seen this many times on my ROCK3A and had to do with how the various 'PCI-E I/O' is operated. Some are multi-PHY SERDES, so can act also as SATA or USB3 or Mii. It very much matters which U-Boot and also overlays, which are kernel dependent. I now got 2-lane PCI-E for a Samsung 970 EVO 500MB (M-Key slot) and SATA3 (E-Key slot) working simultaneously. Is a Radxa U-Boot in SPI and vendor 6.1.115 kernel, else it won't work. For the RK3588 on my ROCK5B it works more flexible w.r.t. bootloader and kernel, 3 sets work, so also latest mainline generic distro Linux. The ROCK5Bplus has 2x M-2 M-key, so that is different from a ROCK5B. I am not sure how lanes are routed, but did once check a similar issue RK35xx board and there the bifurcation seemed to be the problem. There are options I think for lspci where you can see how many lanes and that should also be in kernel log. Might need loglevel=7 to see it. It might also be that the Crucial P310 just won't work reliably with the ROCK5Bplus, we have seen something this similar before for an other NVM-E + RK3588 SBC combinations (I think it was OPi5+ and same SSD as I have). Other NVM-E brand worked without issues.

./compile.sh And choose this:

Thanks for your replies! @Igor is that screen shot you've pastebinned from a connection to the usb TTY? I've ordered a new card reader / writer which should be here tomorrow. The only one I currently have is in my elderly System76 laptop and I'm not fully confident in its driver support (for example it doesn't eject or unmount, so my only recourse is to run sync a bunch of times and then shut the machine down). I don't think there's much point in building new cards with the Bookworm minimal version as that's what I currently have on my Cuboxes. I will report back. Thanks again!

@Chris C In case going's suggestion doesn't help, the kernel should be compatible with the Rock 5b. I don't think that you need to install the dtb if you're already running Armbian with vendor kernel 6.1.x. So just install with "sudo apt install ./linux-image*.deb and the headers if you need them to compile drivers that you need for testing. To be sure if the install went correct you should look if the symlinks are all to the correct kernel. "ls -l /boot" otherwise "sudo ln -sf correct-vmlinuz Image" and so on But adding a log is always helpful indeed. Send it after the nvme stopped working.

UART console log? In fact, only the u-boot version and the kernel version are interested. On my devices with rk3588 (s) chips, old versions of u-boot were originally installed and they did not allow loading Armbian images. I used the instructions from the manufacturer's official website and recorded the bootloader provided by Armbian on the SPI chip using special software. In other words, Armbian delivers his images from u-boot v2025.XX but my orangepi5plus was loaded using u-boot v2019 recorded on an SPI chip. And that may be the problem. After overwriting the new version, my device loads any images and PCI (NVME) devices register correctly. I checked several of these from different manufacturers. Hope this information helps with your problem.

Looking for Armbian_20.02.7_Cubox-i_bionic_current_5.4.28_desktop.7z – anyone can share a copy

Thanks @royk, Can you please elaborate a bit on how to try out the kernel you sent? Isn't it for orange pi 5? How do I build an image out of it for the rock 5b+?

@Chris C In the past there was a commit to fix sata issues with the Rock 5a, but this gave problems for nvme with Orange Pi. After that I also read some problems with nvme and the Rock 5B although I don't know if that was related. https://forum.armbian.com/topic/46601-2484-latest-apt-upgrade-breaks-multiple-things-including-the-gnome-desktop/?do=findComment&comment=204829 This is a bit older kernel with RT patch where I reverted that commit. If that works you could compile a "normal" kernel with that commit reverted. https://drive.google.com/drive/folders/1r76sUsfG_F8pq0pkzzPgEyzqdRG6fGcz?usp=drive_link

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?

So am I reading correctly from your post that separating boot and rootfs using armbianEnv.txt does work? Do you think the hardlink option inside the boot partition could work? I would most likely test this setup but would like to know before if there are issues why it never would work to avoid work, I know there are many other options including an initramfs with btrfs support to avoid partitions for different rootfs to then use subvolumes. Still I would like to stick for the time being with the original idea. Thanks.