royk

@Tony3 Yes that's correct. At the moment I've got a Noctua pwm fan connected the same way (only the red and black wire). And with this overlay, because it's often about 51 degrees idle I've set the first trip at 53 but edit it as what works best for you. That Noctua fan you don't hear at all and it never runs hotter than 62-64 degrees (with an old router heatsink). /dts-v1/; /plugin/; / { fragment@0 { target = <&fan>; __overlay__ { cooling-levels = <0 72 74 78 85 100>; rockchip,temp-trips = < 53000 1 58000 2 62000 3 67000 4 75000 5 >; }; }; };

It depends on what you are using it for. The best experience for me is Armbian Jammy with the software installed from amazingfate's repository. I'm using it daily, it's not perfect, but I'm amazed how much I use it instead of my pc. Especially with box64/Wine64. The acceleration was with the kernel of Googulator? That one is not updated for months and very hacky. For the 6.5 kernel you can look here what had made it to the mainline kernel: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

I don't think that Mesa has support for it but you could build it yourself: https://gitlab.com/panfork/mesa For video acceleration you'll need to compile/install mpp https://github.com/rockchip-linux/mpp FFmpeg with rkmpp support decoding/encoding https://github.com/hbiyik/FFmpeg/ For Chromium you could find some info here, but I've never done this: https://github.com/JeffyCN/libv4l-rkmpp With a bit of luck it won't take very long to get working mainline drivers. https://www.collabora.com/news-and-blog/news-and-events/pancsf-a-new-drm-driver-for-mali-csf-based-gpus.html

@OP5_PLUS Are you using the upper m.2 slot for WiFi/BT or something else? If so you could try without. What does "lsblk -t" return? What improved the speed a bit with my nvme is (but first check the current settings with lsblk -t): echo 4096 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb echo 1024 | sudo tee /sys/block/nvme0n1/queue/nr_requests This should be better for NVME drives, but I don't see a difference echo none | sudo tee /sys/block/sda/queue/scheduler If it returns something like "Invalid argument" then try lower values like 2048, 1024, 512.... Another thing you could try is (especially when you wrote the image with dd): sudo fstrim -v / Setting the sector size to 4k seems to improve the performance by some people. Last time I tried that I wasn't able to boot from it and didn't try again (likely I did something wrong). After doing this don't use dd to write the image, just create one ext4 partition and install with armbian-install. What worked for me to restore a backup was 'sudo cp -ra /location/backup/* /location/nvme' https://www.bjonnh.net/article/20210721_nvme4k/

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

Looks like you need to set a few drivers at least to y instead of module. Something about linking static library against dynamic library. I've made this script as executable in /usr/local/bin/findtext #!/bin/bash location="$1" text="$2" grep -rnw $location -e $text Then you could search with findtext /location/of/kernel/drivers/media v4l2_subdev_call_wrappers Perhaps you could find the options in the kernel config after enabling/saving? cat saved-kernel-config | grep CONFIG_VIDEOBUF2_ Or with findtext without the "w"

I've just compiled a new kernel with almost the default config, the things I've changed have nothing to do with access to the GPIO pins and I've never seen these errors. What have you tried? Did you install the right branch of Wiringpi? git clone https://github.com/orangepi-xunlong/wiringOP.git --branch next cd wiringOP ./build clean ./build Then just run "GPIO read all" Works here without root, perhaps the default user groups have been changed? But first see if this works.

@vandyman That's probably because you write the sd-card image (with bootloader) to the NVME. Android uses a lot of different partitions. I've seen a few times that Ubuntu's disk utility didn't recognize the drive correctly while gparted did. Yeah it is an easy way to just write the image, for Android images I get it. For backups cp -ra did work well, the Armbian image with armbian-install. One time the bootloader installed to MTD didn't work, that was because the drive was SATA and had to copy it from the Orange Pi GitHub, not sure if that's still necessary.

My advice is to respond to replies you received in duplicate posts from you. That could help others too instead of just receiving.

@Paulo da Silva With the Raspberry Pi you're not really installing it but just write an image to a sd, that does also works right away with the OPI. When you bought an Orange pi you should've known that it's fairly new and it's not the same as a raspberry. Then while Armbian makes these devices much more usable and give great support you're complaining here. If you want to complain go to the manufacturers forum, on this forum you could ask for help You're probably doing something wrong and that's what you could expect when you begin with something new. "without information on the company's website"??? https://orangepinet-5898.kxcdn.com/wp-content/uploads/2023/07/OrangePi_5_Plus_RK3588_user-manual_v1.5.1.pdf Especially look at: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#How_to_use_the_debugging_serial_port http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus What's the brand/type of the NVME? and which steps did you take? @vandyman Although I did this at the beginning I've learned that dd (Raspberry Imager) to a nvme/ssd is not recommended and you don't need the official Orange Pi image. With the Orange Pi 5 plus I didn't even had to update the bootloader to make it boot from nvme.

No problem, btw you could enable other PWM pins except the PWM 3 pins. In the DTB you could see that PWM3 controls pin pwm3m1. When you enable the other PWM3 overlays PWM3 might have been pwm3m0, pwm3m2 or pwm3m3 (I believe the last one you've added). So always check which one you need and only activate that.

@nihilowy It does work here with a 2 pins fan with LED and with a 3 pins fan of Noctua, both connected with the black wire to 5v on the fan header and red wire to PWM on the fan header. Did you use the first overlay I had posted? orangepi-5-plus-pwmfan.dts Compiled/installed with sudo armbian-add-overlay orangepi-5-plus-pwmfan.dts ? Checked if the temperature was high enough to trigger the fan? Perhaps you've still enabled all PWM pins? This could conflict with the fan PWM pin, the fan PWM pin is enabled by default. Try to disable all other overlay files in /boot/armbianEnv.txt and see if that helps. (Except sata if you need that one of course) You could rise the temp quickly with: stress --cpu 8 or less if you want to see how it behaves at lower temps. With armbianmonitor -m you could see the temp. (C.St. is always 0/7 and doesn't matter) If you do also want to edit the temp settings you could use this overlay orangepi-5-plus-pwmfan.dts

@alex.i See https://forum.armbian.com/topic/29253-temperature-and-fan-control-on-opi5/?do=findComment&comment=170418

It turns out that the fan connector doesn't give a real PWM signal (tested with pwm signal tester for laser module) and needs PWM values between 0-100. If you really want to use the PWM wire (be sure it's 3.3v and not 5v) and use the above overlay, with the other PWM pins it needs values between 0-255.

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

@OP5_PLUS It has a 5v driver, the black wire to 5v and red wire to pwm. The result I had with the fan I've got is that the fan didn't spin at 50 and at 55 degrees it was spinning at 100%. I've just looked at it and to me it seems like the cooling-levels should be between 0-100 instead of 0-255. I've made an overlay which you could edit and compile/activate with: sudo armbian-add-overlay orangepi-5-plus-pwmfan.dts With this overlay it works correctly with my fan, so post your results here and perhaps it could be edited in the source. orangepi-5-plus-pwmfan.dts

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

@mo123 Perhaps using a newer version of MPP, as far as I can see Batocera uses a version from March. That Kodi commit is reverted eventually. Lately I had compiled Kodi with that FFmpeg version and somehow HDR didn't work. I didn't look further into it. With FFmpeg from JeffyCN, latest version of Kodi and MPP, recent Armbian kernel, HDR does work here. AFAIK the rk3588 doesn't support HDR10+ and Dolby Vision. The ones I've tested are regular HDR and HLG.

@Tony3 It depends on the config of your current kernel if the ethernet adapter will work: cat /boot/config* | grep CONFIG_R8125 If that module is not enabled then the easiest thing to do is recompile with your current config and enable the R8125. You could first check if the modules you were missing aren't already in the default config. And you'll need to select the right DTB of course in armbianEnv "rk3588-orangepi-5-plus.dtb". If you don't have that file, download a minimal image and copy to /boot/dtb/rockchip/

@ZZY For ffmpeg check: https://github.com/hbiyik/FFmpeg rkmppenc is what I use with tvheadend to transcode to hevc. https://github.com/rigaya/rkmppenc For gstreamer you'll need to add the repo of amazingfate. Search packages in apt with "apt search ..."

Read OttawaHacker's post of 2 days ago: https://forum.armbian.com/topic/29352-udev-for-i2c-and-gpio/

I don't have a GoPro 11 but just tried 2 4k 120fps samples and they play fine in Kodi (GBM) 1: Stream #0:0[0x1](eng): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(pc, bt709), 3840x2160, 163257 kb/s, 119.88 fps, 119.88 tbr, 120k tbn (default) Not exactly the same format though. You could try to update mpp: https://github.com/HermanChen/mpp Default installs in /usr/local/ so add the following lines to "make-Makefiles.bash" (otherwise it still uses the previous installed version) -DCMAKE_INSTALL_LIBDIR:PATH='lib/aarch64-linux-gnu' \ -DCMAKE_INSTALL_PREFIX:PATH='/usr' \ In Wayland I'm only able to play the file decoded with rkmppenc to ffplay, but with high cpu load. ./rkmppenc --avhw -i file.mp4 -o - | ffplay -

@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

Already tried a virtual display? https://help.realvnc.com/hc/en-us/articles/360004324217-Beginner-s-guide-to-Virtual-Mode#what-is-virtual-mode--0-0

@hammsandwich21 Did you apply the ffmpeg commits and reverted the Kodi commit?