royk

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

@royk Hi
Yeah, my bad, i guess when you open an ssh connection it goes up a little bit as you can see on my second screenshot (when you log in), thats why I posted the htop screenshot too, because it didnt match.
 
Running mpstat showed me the truth:
 
# mpstat Linux 5.10.160-rockchip-rk3588 (orangepi5-plus) 06/14/2023 _aarch64_ (8 CPU) 09:00:44 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 09:00:44 AM all 0.25 0.00 0.66 0.07 0.00 0.01 0.00 0.00 0.00 99.01  
About 99.01% of idle, or 0.99% of usage . Pretty nice.

Ver 20230609-edge (use u-boot) kernel 6.4-rc5 (no HDMI)
20230609-EDK2-EFI-edge kernel 6.4-rc5 - HDMI work only EDK2 (grub), HDMI in system not work
 
 
root@192.168.1.16's password: ___ ____ _ ____ / _ \| _ \(_) | ___| | | | | |_) | | |___ \ | |_| | __/| | ___) | \___/|_| |_| |____/ Welcome to Armbian 23.04 Lunar with bleeding edge Linux 6.4.0-rc5-media No end-user support: built from trunk System load: 13% Up time: 5 min Memory usage: 2% of 7.76G IP: 192.168.1.16 CPU temp: 37°C Usage of /: 51% of 3.4G RX today: 5.4 KiB [ 29 security updates available, 34 updates total: apt upgrade ] Last check: 2023-06-09 09:18 [ General system configuration (beta): armbian-config ] Last login: Fri Jun 9 12:18:35 2023 root@orangepi5:~# neofetch root@orangepi5 -------------- █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (23.04) aarch64 ███████████████████████ Host: Orange Pi 5 ▄▄██ ██▄▄ Kernel: 6.4.0-rc5-media ▄▄██ ███████████ ██▄▄ Uptime: 5 mins ▄▄██ ██ ██ ██▄▄ Packages: 549 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.2.15 ▄▄██ ██ ██ ██▄▄ Terminal: /dev/pts/0 ▄▄██ █████████████ ██▄▄ CPU: (8) ▄▄██ ██ ██ ██▄▄ Memory: 193MiB / 7943MiB ▄▄██ ██ ██ ██▄▄ ▄▄██ ██ ██ ██▄▄ ▄▄██ ██▄▄ ███████████████████████ █ █ █ █ █ █ █ █ █ █ █ root@orangepi5:~# lspci 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Non-Volatile memory controller: Sandisk Corp PC SN520 NVMe SSD (rev 01) root@orangepi5:~# fdisk -l Disk /dev/ram0: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram1: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram2: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram3: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram4: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram5: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram6: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram7: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram8: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram9: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram10: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram11: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram12: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram13: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram14: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram15: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram0: 3.88 GiB, 4164530176 bytes, 1016731 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/mtdblock0: 16 MiB, 16777216 bytes, 32768 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 209E9F6E-F3DE-4E2D-9674-F497A9BE8D63 Device Start End Sectors Size Type /dev/mtdblock0p1 64 7167 7104 3.5M Linux filesystem /dev/mtdblock0p2 7168 7679 512 256K Linux filesystem /dev/mtdblock0p3 7680 8063 384 192K Linux filesystem /dev/mtdblock0p4 8064 8127 64 32K Linux filesystem /dev/mtdblock0p5 8128 8191 64 32K Linux filesystem /dev/mtdblock0p6 8192 16383 8192 4M Linux filesystem /dev/mtdblock0p7 16384 32734 16351 8M Linux filesystem Disk /dev/nvme0n1: 119.24 GiB, 128035676160 bytes, 250069680 sectors Disk model: WDC PC SN520 SDAPMUW-128G-1101 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x027e8210 Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 * 2048 208058367 208056320 99.2G 83 Linux /dev/nvme0n1p2 208058368 250068991 42010624 20G 82 Linux swap / Solaris Disk /dev/sda: 3.7 GiB, 3967811584 bytes, 7749632 sectors Disk model: Silicon-Power4G Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BFDA5BCE-6452-AB45-9B78-7749AD770D18 Device Start End Sectors Size Type /dev/sda1 32768 7340032 7307265 3.5G Linux filesystem Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes  

@Minh I've seen a GitHub of someone who added hw encoding to ffmpeg but can't find it atm. Perhaps this will help you:
https://github.com/rigaya/rkmppenc
 
Not sure if this one works for rk3588:
https://github.com/jjm2473/ffmpeg-rk

curl https://raw.githubusercontent.com/orangepi-xunlong/linux-orangepi/orange-pi-5.10-rk3588/arch/arm64/boot/dts/rockchip/overlay/rk3588-i2c5-m3.dts -O rk3588-i2c5-m3.dts armbian-add-overlay rk3588-i2c5-m3.dts reboot  
So this is how you can make the fix permanently.
If you use different Kernel or arch then it might be a bit different location in the github repo.
 
# uname -a Linux opi 5.10.160-rockchip-rk3588 #1 SMP Fri May 26 08:01:48 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux  

@royk I already realized that this is not your snapshot of the test. I am reading this post listed in the link.
 
Rod wrote about my repository.
This is currently in development and not finished.
In the final version, this branch will collect an image with a real-time kernel and linuxcnc + a certain number of libraries and settings necessary for work. All in one build system.
When I am ready, I will join your company on the linuxcnc forum.
 
It looks like the truth.

ver 20230427-EDK2-EFI-current kernel 6.2 ( work HDMI USB LAN etc )