I was rechecked that openvfd works and get its config openvfd dtbo overlay fragment (decompiled on running system) It works, driver loaded and userspace software shows me current time on LED (some segments shows wrong, i think it result of wrong chars config) tm16xx: I've tried many values for GPIO line config, GPIO_ACTIVE_LOW (1), GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN (6), GPIO_ACTIVE_HIGH (0), GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN (7). It was no result at all, driver still says that cannot init controller. Also i was tried drivers fd6551, fd655 with different GPIO lines config. No success. I was rechecked LED controller chip on board, it is really FD6551. tm16xx dtbo overlay fragment (decompiled on running system) I have no ideas what goes wrong. When i was configure openvfd device tree, pointing gpio chip as &gpio was not works. Only pointing as "0300b000.pinctrl" was successful. Maybe, its important... Maybe, some features/conflicts at controller init needs debugging

Rock 5-whatever are really picky with power supplies. They are skipping like a school girl if the power supply is not right. I have for example one relative dumb little power supply with 2 outputs and using both outputs with Orange Pis works just fine. When I used one output with the Rock 5b+ I saw many crashes. It just hard reset at various stages. After connecting it to a usb output from a powerstrip it worked just fine. Radxas devices are really really picky is what everybody needs to keep in mind.

@humanus I would argue that if you build your own image with your own u-boot that uses the vendor versions of BL31 Elf and DDR Bin plus some rootfs, you can test very quickly different kernel versions to see if latest mainline kernel 6.18 or 6.19-rc is working. U-Boot is quickly to build # extract u-boot cd u-boot-2026.01-rc5 # Get bl31 and ddr. Maybe even try newer versions of BL31 and DDR curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/0b3e87afc2abd8dd6eb0052cd1be00de94a96637/bin/rk35/rk3528_ddr_1056MHz_v1.09.bin curl -LO https://raw.githubusercontent.com/rockchip-linux/rkbin/bf63f186b9d6ffeca758278f8cadb5d5e5dc7f86/bin/rk35/rk3528_bl31_v1.17.elf # Create the u-boot config make rock-2-rk3528_defconfig # Enable more config options like this, ONLY if really needed scripts/config --enable CONFIG_USE_PREBOOT scripts/config --set-str CONFIG_PREBOOT 'led green on; sleep 0.1; led green off' scripts/config --set-val CONFIG_LOGLEVEL '7' scripts/config --set-val CONFIG_SPL_LOGLEVEL '7' # If you enabled more than default, update the config make olddefconfig # Build u-boot make EXTRAVERSION=-MyAwesomeUboot-1 BL31=rk3528_bl31_v1.17.elf ROCKCHIP_TPL=rk3528_ddr_1056MHz_v1.09.bin # use u-boot files to flash - idbloader.img - u-boot.itb sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/idbloader.img seek=64 sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot.itb seek=16384 # or the combined file - u-boot-rockchip.bin sudo dd of=/path/to/rock-2f-archlinux.img bs=512 conv=notrunc if=/path/to/u-boot-rockchip.bin seek=64 This is just an idea to get you started and created relative quickly a base image for a boot test. If you have a process to build that quickly, flash it and try to boot. Hook up a serial console and if it boots interrupt the u-boot to get to the u-boot prompt. If you get there, you don't need to think about to much about the boot loader in the image. Because at that prompt you can test various boot options live, instead of editing something on the sdcard or to whatever medium you flashed it. Here are some thoughts and notes on how you can debug and try to boot from the u-boot prompt. # Lets assume device 1 is the SDCARD with the system on it # Check you disks (sdcard / emmc) mmc list mmc dev 1 mmc list mmc part # Maybe that will show you something like this. => mmc list sdhci@2a330000: 0 (eMMC) mmc@2a310000: 1 (SD) mmc@2a320000: 2 (SDIO) # 'dev part' will show you the partitions. # Lets assume you have 3 partitions on and part 3 is your system # Check if you can read files ls mmc 1:3 ls mmc 1:3 /boot/ # Now if you know your Linux kernel image, initrd and DTB name, you can try to boot load the files and boot # You get the PARTUUID from the 'mmc part' above load mmc 1:3 ${kernel_addr_r} /boot/Image load mmc 1:3 ${fdt_addr_r} /boot/dtbs/rockchip/rk3528-rock-2f.dtb load mmc 1:3 ${ramdisk_addr_r} /boot/initramfs-linux.img setenv bootargs 'root=PARTUUID=ab3ede6d-b4b9-4368-80a9-a029b67cca29 console=ttyS0,1500000 rootwait' booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Most important is you need to figure out what the serial console really is. If it is not ttyS0, try ttyS1 or ttyS2. The above "bootargs" at very basic. If you don't see much, try adding more. Here are some example you can add. Not all at ones! earlycon=uart8250,mmio32,0xfeb50000 console=tty1 console=ttyS2,1500000 console=both consoleblank=0 loglevel=7 panic=10 rootwait rw init=/sbin/init rootfstype=ext4 The "earlycon" parameter is also board specific. Not sure if it is valid for a Rock 2F or what the correct address would be. Again, this is not a working step by step guide but something that I would try to use for development and debugging. Once you have something working, I would think about integrating it into the Armbian config files.

Mainline 6.18 or 6.19 does only decoding accelerated, not encoding (yet) what is to great benefit of Jellyfin. Also for that transcoding, Jellyfin uses RKMPP, not V4l2. So 6.1.115 vendor kernel is what I use on the Jellyfin server (headless). For desktop RK3588, I use mainline 6.18.2 at the moment, brute force SW decoding, that works for me as content is max 1080p60 (HEVC or VP9 or H264).

Update 1. The LibreElec solution that Dante suggested works very well, if the only thing that is wanted is the video acceleration and kodi. Unfortunately, if one wanted to also add a Jellyfin server on the Nanopi R6S (which works well with video acceleration), then LibreElec is an issue because it won't allow installing that software. Nonetheless, right now, it appears to be the only option besides FriendlyElec. 2. The Armbian solution does not allow for stutterless playback of 2160 videos for some reason. Please see the logs below: https://paste.armbian.com/akudoyopas In general, I would much prefer a solution with Armbian which would allow a lot more flexibility with my setup.