royk

@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.

@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

You could try to add one of these in armbianEnv.txt extraargs=pci=pcie_gen2 extraargs=nvme_core.io_timeout=4294967295 extraargs=nvme_core.default_ps_max_latency_us=0

Try to upload the old and new driver to an AI with you overlay included. Here it gives some suggestions for what you can try. The power sequence seems to be changed with the new driver and it might be too fast for your display. It suggests to put some parameters in the overlay to delay some parts, with higher chance with the first 3: Under "dsi0_panel: panel@0 {" prepare-delay-ms = <120>; reset-delay-ms = <50>; init-delay-ms = <150>; enable-delay-ms = <50>; disable-delay-ms = <50>; unprepare-delay-ms = <120>;

What does the following command show? sudo fdtoverlay -v -i /sys/firmware/fdt -o /dev/null /path/to/your_overlay.dtbo panel-simple-dsi ... Expected bpc in {6,8} but got: 0 So possibly the default with the older kernel was by accident correct and now you should define it. And it seems that you use an overlay meant for the 5a on a 5c?

@laibsch It seems that if you set the pixel clock or refresh rate too high that you can shorten its lifespan. But when you use extreme values and the display doesn't have any protection in rare cases you can even damage it. A bigger chance is driver instability or a distorted display.

There is no overlay for that, but at your own risk you can edit the current overlay with some help of AI. But it will need the exact data of the data sheet. Just upload the data sheet, overlay and relevant dts/dtsi files (some of the includes and includes of the includes of rk3588/rk3588s) and ask to make an overlay for this display for Armbian.

Yes, when you out it in device tree mode: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file

This one I made for the Orange Pi 5, perhaps it works also on yours: https://drive.google.com/drive/folders/1r76sUsfG_F8pq0pkzzPgEyzqdRG6fGcz These for RK3399 https://drive.google.com/drive/folders/12VfNmKC30vxNzaNAk2EN5sHDfeCnnzYX For the 5.10.160 kernel there's an already rt patched source from Orange Pi: https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-5.10-rk35xx-rt And when you apply an rt patch in Armbian, you should remove the local version patch. Armbian doesn't support local versions

@Jacob Olness The SD-card has priority, otherwise it would be difficult to recover.

The boot directory is on the nvme, so likely the btrfs file system is not supported by the bootloader. Please put in your title that you've solved it

Maybe it's secure boot that's enabled in the bios why the unsigned module won't load?

@ArmBoy1988 I gave you already the answer if you want full hardware decoding support. Maybe you don't like it, but it's the only way. So a Flatpak won't work unless it's specifically built with rkmpp support. At this moment using the vendor kernel and build Kodi with FFmpeg with rkmpp support it the way to go.

@Gullik To me it sounds like a problem with Mesa. This happens with an x86 box that I have after a kernel update or something with a self compiled Mesa, then in the folder /usr/lib64 the files libGL.so.1, libGLESv2.so.2 and libEGL.so.1 will be relinked to the original files (with a higher version number). In that case relinking them solves the issue. Enter "ls -ltr" in the lib64 folder to see the newest files under

While playing a video press the letter "O" to check if you're using hardware or software decoding. For hardware decoding you need to compile Kodi with FFmpeg that supports rkmmp hardware decoding and with gless. For 10 bit decoding you should run Kodi from GBM. You'll also need to change a setting in Kodi under video, set render method to "Direct to plane". So install FFmpeg as described at: https://github.com/nyanmisaka/ffmpeg-rockchip/wiki/Compilation Build Kodi as described at: https://github.com/xbmc/xbmc/blob/master/docs/README.Linux.md#41-configure-build with as cmake command for example: cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCORE_PLATFORM_NAME="wayland gbm" -DAPP_RENDER_SYSTEM=gles