Active threads

nice work @Eks Ma thanks for sharing!

Open the box, read the silkscreen on the board, run rk322x-config and configure according to silkscreen name. Probably you have a r29/h20 board

h96-m9s-rk3576_defconfig rk3576-h96-m9s.dts rk3576-h96-m9s1.dts rc.local h96-m9.config rk3576-h96-m9s.dts h96-m9.tvb Compile-configuration.zip

thank you so much for the link, after trying some of the older tinkerboard .deb archives from there I was able to install one that didn't have the two missing deps eventually and, lo and behold, I could even feel the accelerated desktop from the login window, even before confirming it with the much snappier webgl aquarium test, that jumped from about one fps to almost 60 there are still some kinks, like h264ify being installed but not doing squat (youtube is still av1 and hangs the whole system), but I'll take what I got for now as for the SOC being 2017....I'm fully aware that like everything Asus makes, it becomes e-waste after 2 years, I could probably try to flip this board online for $1 and no one would buy it, but I still believe it should be enough for me to stream video from my NAS on my secondary TV using 5-15W, kind of like those crappy Android sticks that plug into HDMI and an extra USB port I have yet to decide if my next SBC should be a rk3588 board or just bite the bullet and get some N100 SBC that's probably cheaper (I live in Europe, Orange Pi 5 probably goes for more than a used PS5 with all the taxes), can run anything and won't be forever stuck on whatever this year's trending distro is

Hi ! @jpm how exactly did you solve 2) Fixed cedar_ve compilation issues / kernel name ? I'm gettinf the same "modprobe: ERROR: could not insert 'cedar_ve': Exec format error" T.

Since it's an external driver, @Vincenzoernst1 you will still need to do all the process: Edit /boot/armbianEnv.txt to load the overlay user_overlays=tm16xx sudo apt install linux-headers-$(uname -r) # if it works, thats nice #if it doesn't you're cocked: sudo apt-get install linux-headers-current-rockchip64 sudo ln -s /lib/modules/6.12.44-current-rockchip64/build /lib/modules/6.12.48-current-rockchip64/build #if it doesn't you're cocked: follow the step by step: ## 🔧 Step by Step ### 1. Find the exact kernel version Confirm the version you're running: ```bash uname -r ``` 👉 You should see something like: ``` 6.12.48-current-rockchip64 ``` --- ### 2. Install necessary packages You will need build tools and utilities to build the kernel: ```bash sudo apt update sudo apt install build-essential bc git wget flex bison libssl-dev libncurses-dev ``` --- ### 3. Download the kernel sources ```bash git clone --depth=1 --branch linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git cd linux ``` > ⚠️ Here I used `linux-6.12.y` because it covers the `6.12.x` series. > If you want to be even more precise (and the branch exists), you can change it to `v6.12.48`. --- ### 4. Prepare the configuration Copy the configuration of the kernel you're already running: ```bash cp /boot/config-$(uname -r) .config ``` And prepare the headers: ```bash make olddefconfig ``` --- ### 5. Generate the headers Now let's create the files in `/usr/src`: ```bash make prepare make modules_prepare ``` This generates the files needed to compile external modules (`Module.symvers`, `modules.order`, etc.). --- ### 6. Install the headers on the system Copy the headers to the correct location: ```bash sudo mkdir -p /usr/src/linux-headers-$(uname -r) sudo cp -r . /usr/src/linux-headers-$(uname -r) ``` Create the symbolic link for `make` to find: ```bash sudo ln -s /usr/src/linux-headers-$(uname -r) /lib/modules/$(uname -r)/build ``` --- ### 7. Compile your module Now go back to the `tm16xx-display` directory and run: ```bash git clone https://github.com/jefflessard/tm16xx-display.git cd tm16xx-display make sudo make install ``` --- ## ✅ Expected result After this, you should have the `.ko` module successfully compiled and installed in `/lib/modules/$(uname -r)/extra/`. And you can load it with: ```bash sudo modprobe tm16xx-display ``` --- Kernel module and display service Option 1: build and install in a single command Builds then installs module and service git clone https://github.com/jefflessard/tm16xx-display.git cd tm16xx-display make install Option 2: step by step commands make clean make module sudo make module-install sudo make service-install Check your display configuration display-service -c 3 phase display check Check that all leds are ON Check the order of digits and segment mapping (you should see "1234") Check each led name (ex: LAN icon is ON while "LAN" text is shown on the digits) I will include this section into a pull request: /dts-v1/; /plugin/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> #include <dt-bindings/pinctrl/rockchip.h> &{/} { i2c-display { compatible = "i2c-gpio"; sda-gpios = <&gpio0 RK_PB4 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; scl-gpios = <&gpio0 RK_PB3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; i2c-gpio,delay-us = <5>; #address-cells = <1>; #size-cells = <0>; display@24 { compatible = "fdhisi,fd6551"; reg = <0x24>; digits { #address-cells = <1>; #size-cells = <0>; digit@0 { reg = <0>; segments = <1 3>, <1 1>, <1 2>, <1 6>, <1 4>, <1 5>, <1 0>; }; digit@1 { reg = <1>; segments = <2 3>, <2 1>, <2 2>, <2 6>, <2 4>, <2 5>, <2 0>; }; digit@2 { reg = <2>; segments = <3 3>, <3 1>, <3 2>, <3 6>, <3 4>, <3 5>, <3 0>; }; digit@3 { reg = <3>; segments = <4 3>, <4 1>, <4 2>, <4 6>, <4 4>, <4 5>, <4 0>; }; }; leds { #address-cells = <2>; #size-cells = <0>; led@0,0 { reg = <0 0>; function = LED_FUNCTION_ALARM; }; led@0,1 { reg = <0 1>; function = LED_FUNCTION_USB; }; led@0,3 { reg = <0 3>; function = "play"; }; led@0,2 { reg = <0 2>; function = "pause"; }; led@0,4 { reg = <0 4>; function = "colon"; }; led@0,5 { reg = <0 5>; function = LED_FUNCTION_LAN; }; led@0,6 { reg = <0 6>; function = LED_FUNCTION_WLAN; }; }; }; }; };

thanks for all the work you put in to this application. i've done this on most all of my systems and it was a bit tedious and fiddley. with just a few tweeks it ran through with no errors on my hc4 with bookworm. one question, why remove bash-completion and command-not-found packages?

Linux 6.1.31-sun50iw9 #1.0.4 SMP Wed Aug 6 19:06:53 UTC 2025 aarch64 GNU/Linux I couldn't find any known kernel issues.

A crash in the Linux kernel's module loader is not really ZFS's fault, though, right? There's nothing about `resolve_symbol` that's part of ZFS.

Would you mind sending this as pull request? https://github.com/armbian/build/pulls

You need to install rkdeveloptool on your PC. Connect the board to your PC using a USB-C to USB-A cable. Before powering the board, press and hold the mask button, then plug in the power cable. Once this is done, your PC should detect the device, and you can verify it with: rkdeveloptool ld You can follow this guide: https://docs.armbian.com/User-Guide_Getting-Started/#rockchip

moved Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

I don't see anything above about your boot-loader being updated. i.e. u-boot or grub. If you're using u-boot, was your uInitrd in your /boot directory updated? The initrd-image needs to be converted to its u-boot format of uinitrd. Instructions for how to do that are located at the bottom of your boot.cmd file (using the mkimage command from the u-boot-tools package). Though that may be a generic example that you'll have to update for your system. Also if you have an armbianEnv.txt (or an equivalent) in your /boot directory, be sure it's up to date for your current kernel's devicetree file location and name. If that doesn't solve it read on.... I keep seeing everywhere that kernel 6.12 is broken. Not sure if that applies to all systems. I use the edge kernel (6.16) in my OrangePI-5-Plus. I've found that to work much better than Vendor (6.1). To chroot in from an another identical system. This works on Debian Trixie. I'm not sure about other OS's. Note: I don't know much about this, I recently found this from searching and used it myself. I found it works great to install new packages and also to run update-initramfs. mount -t proc proc /mnt/proc mount -t sysfs sysfs /mnt/sys mount -t devtmpfs devtmpfs /mnt/dev mount --bind /dev/pts /mnt/dev/pts # If you need for the chrooted system to be able to access the internet, the link at its: (/etc/resolv.conf) must be valid, so add this as well: mount --bind /run/systemd /mnt/run/systemd Then chroot in (I'm not sure if the /bin/bash) is necessary - or if you're using something else than bash, put that there instead?) chroot /mnt /bin/bash [Do what you need to do in there] i.e. install a different kernel, and be sure update-initramfs has been run or run it yourself, and the u-boot (or grub) is updated. Whenever you're installing a new kernel, it's a good idea to leave the old one there. Once you get it working, it might then be a good idea to remove any non-functioning kernels (like that 6.12), and leave any functioning kernels in. Then to back get out of chroot and return undo the above mounts: # Exit chroot exit # This line is only necessary if you mounted it to use the internet while chrooted: umount /mnt/run/systemd # Unmount the rest umount /mnt/dev/pts umount /mnt/dev umount /mnt/sys umount /mnt/proc umount /mnt

Thanks for this info, just wanted to share that the image for the "Linux v6.1 vendor IOT image for the 5 "Max" model" you linked to also worked for me on my Orange Pi 5 Ultra with no modifications needed. I haven't tested wifi or any use cases besides some simmple stuff over ssh so far, I did get a warning on first boot that it's a developer version of Armbian and shouldn't be used for production, but I suppose that's the case for all "community" builds? I also found this gist with steps to build Armbian from scratch for the 5 Ultra, but I haven't tried this yet. In case anyone else is looking for related info this PR also is also relevant: https://github.com/armbian/build/pull/8252 I still regret not buying a better supported board like the 5 Max board instead but hopefully better support will come for the 5 Ultra with time.

Thank you, it looks like my Nvme was bad. It works now!

I switch to vendor kernel 6.1.115 - its work

Hi All Well I am getting nowhere fast. When plugging the board into a Rpi Zero 2w , i2cdetect -l shows i2c-1 and i2c-2 i2cdetect -y 1 shows 00x48 i2cdetect -y 2 shows oox49 (my second board) and a few others like 3a,50,59 Re-wrote the image on the Opi Zero 2w to Debian as I was getting tired of the booting problems with ArmBian. Followed the manual on ALL the instructions. i2cdetect -l shows i2c-0 i2c-1 ,i2c-2 and i2c-3 i2cdetect -y 0 does not show any adapters connected i2cdetect -y 1 shows UU on 36 i2cdetect -y 2 shows 30 and 50 i2cdetect -y 3 does not show any adapters VERY SLOWLY. Orangepi-config /system/Hardware has been tried with just i2c-0 ticked or all three ticked. Tried ticking phi2c-0 to 3 but that made no difference, still no 00x48 visible anywhere. I have tried about 6 different OS Images, all to no avail. Even tried the Rpi image shown on the Opi site. So, I have to conclude (unless someone corrects me) that it is the board that is the problem or some firmware on the board. Not sure if I should learn how to upgrade the firmware. Regards

@Igor When I first start it up, I get an error! Even if I install the packages manually, the GNOMRlE interface does not switch to Portuguese! That's strange!

I recently had to modify a device tree file for a different reason. I showed what I did (and how I did it) here: https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/?do=findComment&comment=224923 To summarize, I used the device-tree-compiler package (command line: dtc) to convert the device tree binary (.dtb) file to a device tree source (.dts) file. Then I edited the .dts file, then converted it back. The process won't show you all the variable names, but the resulting .dts is readable enough to likely see what and where you need to change... and even moreso if you have the original (pre-compiled) .dts file to compare it with. If you need to match variable names with specific numbers, they will likely be #defined in the #includes at the top of the original .dts file.

This will cause update-grub to add the following a devicetree line to all menu entries. This example is based on Debian Trixie's grub-efi. This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels: -rw-r--r-- 1 root root 336036 Aug 27 04:10 config-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 343394 Sep 6 12:48 config-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ lrwxrwxrwx 1 root root 43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/ lrwxrwxrwx 1 root root 42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ drwxr-xr-x 3 root root 4096 Sep 20 15:13 efi drwxr-xr-x 5 root root 4096 Sep 20 16:26 grub lrwxrwxrwx 1 root root 29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64 -rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64 -rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 83 Aug 27 04:10 System.map-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 92 Sep 6 12:48 System.map-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64 -rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 41507328 Sep 6 12:48 vmlinuz-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64 Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does. For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/10_linux 2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189) linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args} 3. Just above it, add your own system's version of this line: devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus: devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/30_os-prober 2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297) linux ${LKERNEL} ${LPARAMS} 3. Just above it, add your own system's version of this line: devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg

Yes, current broke at some point. More up to date packages should be available via apt. In general the support for rk3588 in 6.12 (current as of today) is barely there but there won't be updates regarding that matter, bug fixes only due to its LTS nature. Better use vendor or edge.

Great, svvolf! This fix boot problem on OPI Zero v1 (Armbian v25.8.1, Linux 6.12.43-current-sunxi) 😁 Thank you!

T'is one reason to prefer boards that take 12V power. and yes, barrel-connectors, but I can't think of any recent boards that use 5V and barrel connectors. NanoPi-M4 vs NanoPC-T4, with a WD Blue SN500, the T4 was stable. the M4 was not. yes, the M4 used the official power supply.

As far as I know, the permissions of /var/log/postgresql after a reboot are recreated from those on /var/log.hdd/postgresql. So if you modify those as well (remove the sticky bit), the workaround should be permanent. Thanks for highlighting this problem, I've encountered the very same issue, but didn't realize it was caused by this somewhat peculiar directory permission. So I just applied your workaround (plus my extension) and hope it will fix this once and for all.

I think there are some userspace drivers needed as well. Armbian provides the kernel module only. Not exactly sure what's needed but I think the stuff is from here: https://github.com/airockchip/rknn-toolkit2/tree/master/rknpu2