royk

@Dbosco (Assuming you set the settings in Kodi correct: settings->player->videos->render method Allow using DRM PRIME Decoder=enable Allow Hardware Acceleation with DRM PRIME=enable Prime Render Method=Direct to Plane) Perhaps something is wrong with your ffmpeg, mpp or rga. Try to follow the steps on: https://github.com/nyanmisaka/ffmpeg-rockchip/wiki/Compilation After that run the cmake command for kodi again before make and install.

@Dbosco Build and install with at least GBM Paste the following in /usr/share/wayland-sessions/kodi-wayland.desktop [Desktop Entry] Name=Kodi Wayland Comment=This session will start Kodi media center Exec=env FFMPEG_RKMPP_DEC_OPT="afbc=on" kodi --windowing=gbm --audio-backend=alsa TryExec=kodi-standalone Type=Application Keywords=audio;video;media;center;tv;movies;series;songs;remote; Icon=kodi Otherwise try to stop the window manager and start it manually to see if it gives an error, from login window press: ctrl+alt+F2 -> sudo systemctl stop gdm3 -> env FFMPEG_RKMPP_DEC_OPT="afbc=on" kodi --windowing=gbm --audio-backend=alsa

@Dbosco Yes that's it

@Dbosco The same here until I compiled Kodi with the patch myself and everything works.

@Antimtr Learn some basic commands first: https://ubuntu.com/tutorials/command-line-for-beginners#5-moving-and-manipulating-files sudo rm /usr/lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm

I've found information on how to use your own IR remote controller from this site: https://forum.odroid.com/viewtopic.php?f=215&t=44671 In short: 1. Enable logging from the IR kernel module, enter in a terminal: sudo -i echo 1 > /sys/module/rockchip_pwm_remotectl/parameters/code_print dmesg -w 2. Check if your remote is supported by pressing the keys on your remote. It should give you info like: [ 3485.342354] USERCODE=0xfb04 [ 3485.369309] RMC_GETDATA=fd 3. Download the overlay file below and edit the usercode and the code for each key. So for like with the key above it'll be 0xfd 4. Place the header file "rk-input.h" in the same directory as the overlay file. In my case the location is "/usr/src/linux-headers-6.1.43-vendor-rk35xx/include/dt-bindings/input/rk-input.h" 5. Compile and install with: cpp -nostdinc remote.dts remote-precompiled.dts sudo armbian-add-overlay remote-precompiled.dts remote.dts

@Joel @amazingfate Just tried the 6.1 image (Armbian_24.2.4_Orangepi5-plus_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop.img.xz) and installed to the NVME (with only 1 ext4 partition) with armbian-install. Initially it didn't boot, there are no files in /boot. After copying the files from the boot partition of the SD-card to the /boot folder of the NVME and changing the UUID in armbianEnv.txt to the UUID of the NVME it boots.

@greg396 WiringOP? WiringOP isn't mentioned in this topic as it isn't necessary. AFAIK is the green wire (RPM) only feedback of the actual RPM which will not be used. In case of the OPI5 I'm not sure if there'll be 5v on the PWM wire, if that's the case you might break the OPI5 by connecting it to the GPIO pins (3.3v), otherwise you can try it. In case you have the OPI5 plus you can try to connect it as in:

@rix81 Great tip! Although Wayland can't output HDR yet (it's almost there), Kodi under GBM can output HDR and these days it's pretty common to have a HDR TV, at least where I live unless you mean something different with "true HDR". Eitherway it seems like a good alternative but you might still need to edit the dtb for HDR.

@XXXBold Yes check my previous post:

@bolet75 Yeah HDMI -> DVI didn't work for me either. About the audio, HDMI audio doesn't work yet on the mainline kernel, jack input/output would need to be set correctly in the dtb, last time I checked it didn't work either: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

@XXXBold You could try updating mpp: git clone https://github.com/rockchip-linux/mpp.git -b develop cd mpp/build/linux/aarch64 nano make-Makefiles.bash add after '-DHAVE_DRM=ON \' the following lines and save (ctrl-x then y) -DCMAKE_INSTALL_PREFIX:PATH='/usr' \ -DCMAKE_INSTALL_LIBDIR:PATH='lib/aarch64-linux-gnu' \ bash make-Makefiles.bash make -j8 sudo make install

@XXXBold Perhaps because you're using a kernel from February while the FFmpeg you're using needs recent made fixes. Try a newer kernel/image. https://fi.mirror.armbian.de/archive/orangepi5/archive/Armbian_23.8.1_Orangepi5_jammy_legacy_5.10.160_xfce_desktop.img.xz

I had the same issue with an old Samsung TV/monitor and use a HDMI->VGA adapter as workaround.

@vale Yeah, I found out it was because I was sitting on the remote. But seriously In case you've got the OPi5 plus it is possible that the IR receiver receives a signal from another remote, I remember that mine did with a remote, I thought the one of LG. Perhaps it's better to disable the remote in the DTB by default, for now you could try to put a piece of tape over it or disable it if it's a module.

@Seb042 In the manual on page 215/216 you can see a better picture, the colored one you'll only see the functions and pin names and beneath that picture you'll see more details with gpio numbers. The prefix you need to use depends on the filename like I explained in my previous message. ls -l /boot/dtb/rockchip/overlay/*spi* The overlay files I've got there begins with rk3588 so that's what you need to use as prefix. If you also need another overlay that begins with orangepi-5-plus then use that as prefix and rename the spi overlay you'd like to use from rk3588-.... to orangepi-5-plus-.... Or to prevent it from getting overwritten after a update, even better to download the dts from: https://github.com/armbian/linux-rockchip/tree/rk-5.10-rkr6/arch/arm64/boot/dts/rockchip/overlay and install it as useroverlay: sudo armbian-add-overlay your-download-spi-overlay.dts Can you post your armbianEnv.txt ?

@Seb042 Yes and it's m0 by the way. So assuming you've got the overlay with filename "rk3588-spi4-m0-cs1-spidev.dtbo" you should have the following in armbianEnv.txt: overlay_prefix=rk3588 overlays=spi4-m0-cs1-spidev

@Seb042 For the DAC you would need to port the RPI overlay so the correct pin names are used and the you would need to check if that kernel module is installed. It might be that you're activating conflicting overlays, in the manual you could find the SPI pin names and just activate that one. Some pins do have something like the same function on m0 as on m1, activating both won't work. Other pins has different functions on the same pin like spi and i2c, activating both won't work either.

To shutdown without a reboot 'shutdown -h now' works, although to boot it again it's necessary to press the shutdown key for a few seconds and press it again to boot.

I've no idea if qemu works, never tried it, but if you want to run a Windows app smooth you'll have a better chance with box64 and wine. Beside that you could literally install Windows for Arm on it although not everything works: https://worproject.com/guides/how-to-install/on-rockchip The RK3588 is thermal throttled at 80 degrees, so it will run slower. An aluminium heat sink will extend the time before it reaches 80 degrees but eventually it'll still thermal throttle, at least the ones I've tested. Replacing the thermal pads for high performance ones can make big difference, just check the temp of the heat sink to see if you'll need it. Depending on your use case adding a (quiet) PWM fan might be a better solution.

@Ravi Terala Read the manual, there you can see how to use the UART, mind the baudrate capability of the adapter.

@johnwoo1999 I'm not an expert, and I don't know what you've already tried. But I've just been experimenting a lot until the results were good. On the GitHub of Rockchip there is a 5.10-rt53 branch which is the one with the RT patches included and a working rt config: https://github.com/rockchip-linux/kernel/tree/develop-5.10-rt53 But because that branch hasn't been updated since august 2022, I made a patch out of the diff of the rt branch and develop-5.10 branch till the same date. This resulted in a RT patch set. The patch is applicable to the 5.10.110 kernel, so I used the kernel source of Xunlong for it. So to build it with Armbian you'll need to edit the source and place the config and patch in the right directory. In the Armbian build system a few folder/file names have been changed in the meantime so you'll need to edit these accordingly.

It could be a lot of things, forgotten to write the bootloader to SPI and ejected the SD after the last boot, something went wrong while updating like wrong dtb, wrong dtb name in armbianEnv.txt Wrong UUID in armbianEnv.txt or in /etc/fstab - you can see it with the command 'blkid'. Symlinks in /boot mixed up (different kernel versions). But after all, the best thing to do is like what Werner said and explains in his video to check the serial console output and you'll see exactly where it fails. If you don't see it then post the boot log. If you don't have a FTDI adapter (that supports a baudrate of 1500000) even when you already found the problem, it's still recommended to buy one, saves a lot of time when you need it.

@Josh Blackburn Do you have the overlay files in? /boot/dtb/rockchip/overlays/ Is the right prefix set in armbianEnv.txt? Other overlays activated that uses the same pin?

@danielpinto8zz6 I didn't test it myself but you should built it with FFmpeg that has rkmpp accelerated encoding capabilities. This FFmpeg version has hevc encoding option: https://github.com/hbiyik/FFmpeg/tree/encoder Or use this Docker but I believe it only has h264 encoding: https://hub.docker.com/r/jjm2473/jellyfin-mpp