royk

Thank you for your feedback, I think you are right in that my problem related to an issue with 24.8.4.
 
I could not boot from NVME when I used kernel 6.1.75 with 24.8.4 (ie the version of images published here https://www.armbian.com/radxa-rock-5c/)
 
I built a new image using 6.1.75 and 24.11.0 (subsequently upgraded to 24.11.1), this now boots fine from the NVME drive.
 
 

@roykAfter many hours, what fixed my issue is reverting to an older kernel .
Indeed it seems 6.1.75-vendor-rk35xx might have issue with nvme / pcie and so the penthat

the solution that worked was downgrading to the 24.8.2 version of the kernel :
 
sudo apt install linux-dtb-vendor-rk35xx=24.8.2 linux-image-vendor-rk35xx=24.8.2 reboot
for reference the solution found was in this post

https://forum.armbian.com/topic/46624-atp-update-changed-kernel-from-6106-current-rockchip-rk3588-to-6175-vendor-rk35xx-and-failed/
 
Thank you Royk for your kind help and suggestions ! it made me read / learn alot but alos helped continue to look further.

@royk 
I made some changes by disabling certain drivers in the DTSI (audio, Ethernet, etc.). After testing, the kernel is no longer crashing.
Now, I am re-enabling the drivers one by one to see if I can identify which one is causing the issue. Your reply has helped me narrow down the problem.
Thank you.

@Pine Li You can find the config in the deb file in the boot folder.

@royk thank your information. I download 5.10.160 branch with PREEMPT_RT feature. when compiling kernel, it throw a error for certs fold Make error. No future information even i set KBUILD_VERBOSE=1. and only few file under kernel/certs/* been compiled into *.o. Have you experience this issue.
 
thanks for your time.
 
I think i figure it out. wrong settings in .config relate to certs

@going https://github.com/orangepi-xunlong/u-boot-orangepi/tree/v2017.09-rk3588

@Benjamin Sonntag I think you want to ask aplay to list recording devices rather than playback devices - I have a different rk3588 device and it shows:
 
acas@t6:~$ aplay -C -l **** List of CAPTURE Hardware Devices **** card 0: rockchiphdmiin [rockchip-hdmiin], device 0: rockchip-hdmiin i2s-hifi-0 [rockchip-hdmiin i2s-hifi-0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: realtekrt5616co [realtek,rt5616-codec], device 0: fe470000.i2s-rt5616-aif1 rt5616-aif1-0 [fe470000.i2s-rt5616-aif1 rt5616-aif1-0] Subdevices: 1/1 Subdevice #0: subdevice #0  that is with the overlay enabled as described 

@Dbosco Yes that's it

This PR should fix USBC on OPi5 -> https://github.com/armbian/build/pull/6485

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

@roykHi, I find just adding quotation marks to rockchip,plane-mask/rockchip,primary-plane/cursor-win-id will fix kodi. No need to toggle primary plane and cursor plane.
So this patch should work for rock5b: https://paste.armbian.com/exuhabuzim.diff

@royk
Finally working for the spi bus.
As I didn't know what I may did wrong, I reinstalled the system, read better the doc as you suggested (the first example they show it's not the standard configuration, confusing for me at first),  and finally I chose the right overlay. 
My armbianEnv.txt is like this to make it works:
 
verbosity=1
bootlogo=true
overlay_prefix=rockchip-rk3588
fdtfile=rockchip/rk3588-orangepi-5-plus.dtb
rootdev=UUID=2cc7a9a6-afc7-4cd4-b377-6f83f2e1bf50
rootfstype=ext4
overlays=rk3588-spi0-m2-cs0-cs1-spidev
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
 
I'm using the cs0-cs1 because I will need both later as I will use rotary encoders. 
I assume it will be the same for i2c bus, I will have to choose the right overlay.
I still don't know which one would be for the i2s, but I should find that somewhere in the documentation I hope.
 
Thanks for the answers and the tip for how to load user overlays.
 

The connector is made for a 2 wire fan, so GND of the fan to PWM and the + wire to 5v.
 
Sorry I see I've made a mistake, actually I've connected: 
FAN                   Connector
Black wire    >     5V
Red wire       >    PWM
 
I've also just tested a pwm fan the same way without the yellow wire connected and does work correctly. But this fan needed different values than my other fan, so you'll need to test a few values.
 
Don't try to connect the red wire to another PWM pin than the one at the fan connector!
 
If it goes at full speed immediately at 50 degrees, lower the values of the following line:
cooling-levels = <0 65 75 85 95 100>;
 
If the fan only starts from 55 degrees, then raise the first value until it just starts to spin and add 1 or 2 to be more secure it will spin all the time at that level.
 
The following  overlay should work with a pwm fan that's compatible with the Raspberry Pi (3.3v).
In this case 5v to 5v, gnd to gnd and pwm to pwm14m2
 
sudo armbian-add-overlay orangepi-5-plus-pwm14m2-fan.dts  
Don't forget to remove the previous overlay from /boot/armbianEnv.txt
 
After editing the values just run the above armbian-add-overlay command again and reboot.
 
orangepi-5-plus-pwm14m2-fan.dts

@royk
I had apparently enabled UART3_M0 at some point, which does indeed conflict with SPI4_M0, disabling UART3 worked. Thank you for bringing that to my attention.
@Werner
Apologies, I will be sure to include that log in future posts. 

@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

@roykYour overlay works. Maybe I have done something wrong by directly modify the devicetree. I will investigate it later.

I did more tests 1 by 1 increment.
The fan starts at 84 at low speed (and very noisy!) and then at 85 get full speed.
 
I think it is a range issue indeed. I will put 255 for all values and start the fan at 40 degC, as the noise looks like there is a bird in the box!

@royk...thank you, I will try again.

Ver 20230911-EDK2-EFI kernel legacy\current\edge 
 
On the edge version, HDMI does not work in the kernel itself, but HDMI is supported at the level of the selection menu in GRUB, this allows you to have several different versions of the kernel\system (for example, add a self-assembled EDGE kernel with its own configuration) and choose on the monitor screen which kernel\system to run not using the UART console.

Did you dd write the images? Check the temperature  Try adding this line to armbianEnv.txt extraargs="pcie_aspm.policy=performance"

@bottlelid Yes I do also have that problem from the moment I upgraded to the latest kernel. The video is in front of everything (until you press "X" or stop on the remote control). Another strange thing I found is that when the display is at 59.9hz instead of 60hz I've got no audio over HDMi, this was never a problem before.
But again I didn't have time yet to look at what could be the cause of these things.

@buzzfab i implemented 6.5-rc1 support for opi5 in the past. I'll also add support for opi5+ this week or next week 
 
Note: It's experimental, most thing is not mainlined yet.
 

@pazzoide Are you sure your fan needs 3.3v?
if you want it to be controllable you'll need a pwm fan like this one:
https://www.amazon.com/GeeekPi-Raspberry-Controllable-Adjustment-40x40x10mm/dp/B092YXQMX5/
Or a transistor and resistors.
 
The way I did was using a pwm fan (3 pin)  and editing the dtb by making a patch with some lines copied from Radxa. Although it does only trigger the fan at a certain temperature, it doesn't regulate the speed as it should, it's missing some lines that were later added. I'll make a new one soon.
The pwm fan in this dtb is set at pwm13 and triggers the fan at 60C , pwm13 has to be enabled with the overlay.
 
The thermal policy has to be on step wise, you could check this with:
cat /sys/class/thermal/thermal_zone*/policy
 
If it's something else you could set the following line in /etc/rc.local before the last line (exit 0):
echo step_wise > /sys/class/thermal/thermal_zone*/policy
rk3588s-orangepi-5.dtb orangepi-5-pwm13.dtbo

I wanted to provide you with a brief update on our progress with the Orange Pi 5 and Moonlight. In the past few months, we have distributed 10 devices to our employees and colleagues, who have been using them as their main streaming devices. The overall experience has been excellent, as no significant problems have been reported. One thing we have noticed is that when operating at really high bit-rates of 120Mbps, the device appears to experience frame loss after some time. I'm uncertain whether there is some form of throttling occurring in this case. We were unable to reproduce this issue on a standard desktop.

Soon, I will be sharing several demonstrations showcasing the Orange Pi 5 in action. These demos will include streaming examples ranging from a basic 1080p stream to an impressive 4K stream at 80Mbps.