royk

@ichigonitro The easiest way will be to install the kernel deb package on a working system. Here is the latest build which work still perfectly for months with LinuxCNC. With this build I made a patch from the difference of the RT branch and rk3588 branch till the date of the latest change on the rt branch. Applied that patch to the kernel source of Xunlong (didn't work with the more updated kernels). https://mega.nz/folder/znBVHJ4Z#69huCvInrf3tqc8I4QR-lQ I don't know for what you'll use it for, but LinuxCNC seems to run best with the kernel arg: isolcpus=5,7 And had to move the ethernet irqs with the use of an ethernet controller. cat /proc/interrupts to see the irqs, then add to /etc/rc.local before 'exit 0' : sleep 10 && echo 20 | tee /proc/irq/82/smp_affinity && echo 20 | tee /proc/irq/81/smp_affinity 20= cpu5. cpu number binary: 00100000 (first number=cpu7 and last number= cpu0) to hex. 81 and 82 are the irq numbers of the device moved to the isolated core. You can build it yourself too if you want to with the config/patch in the zip, but you'll need to change some of the (folder) names. rk35xx armbian-build-rt (2).zip

@amazingfate Yeah I know what you mean, every time the OSD popups the video goes black. Removing the line 'disable-win-move;' from the dtb did solve that problem on the OPi5 and OPi5 plus.

@Dbosco Great and tnx for letting me know. @PajPaj Nothing special, you should've installed FFmpeg with MPP support, and Kodi build with that. The one from amazingfate's repository should work. Then be sure you run it with the GBM window manager like you can see in the screenshots of Dbosco. Just follow the instructions of this topic for the right settings. Perhaps you've updated FFmpeg en Kodi to a build without MPP? @amazingfate Perhaps the DTB/dts can be edited in the source for the right behavior of the planes/overlays?

@Dbosco I've seen something like that before. As you can see is your edited file rk3588s-orangepi-5b.dtb while in your armbianEnv.txt you've got the file rk3588s-orangepi-5.dtb, so that's the reason it doesn't work. So this seems to be a bug of the editor (or a config setting at some place), I'm not sure if that dtb only has the wrong filename or if it's an edited 5b dtb. As workaround you could just try to edit the name in armbianEnv.txt to rk3588s-orangepi-5b.dtb and hope that it will boot Or replace the 5b dtb with the OPi5 dtb and edit again, then move 5b dtb to OPi5 dtb: sudo mv /boot/dtb/rockchip/rk3588s-orangepi-5.dtb /boot/dtb/rockchip/rk3588s-orangepi-5b.dtb sudo armbian-config -> System -> DTC Then search (crtl+w) for 'disable-win-move;' and remove that line. After that ctrl+x and save and DISAGREE to reboot sudo mv /boot/dtb/rockchip/rk3588s-orangepi-5b.dtb /boot/dtb/rockchip/rk3588s-orangepi-5.dtb sudo reboot

@Dbosco I did have that behavior when I didn't remove the "disable-win-move;" line. You could check if the edited dtb is the one mentioned in armbianEnv.txt. 'ls -ltr /boot/dtb/rockchip/' The last file should be the same as the one in armbianEnv.txt

@thanh_tan Are you using X11 or Wayland? Orange Pi has the option "NoEDID" "true" for X11 which you could try https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/bsp/rk3588/etc/X11/xorg.conf.d/20-modesetting.conf

If there are people that still have problems with the overlays in Kodi, unable to see the OSD while playing a movie. You could try the following: Install the overlay: sudo armbian-add-overlay vop.dts Then: armbian-config -> System -> DTC Then search (crtl+w) for 'disable-win-move;' and remove that line. After that ctrl+x and save and agree to reboot The correct way would be to edit/patch the dtb of course, but I thought it would be better to first check if this will solve it for everyone and perhaps this could be changed in the source. vop.dts

I'm not sure but don't think there could be something in then fan that interferes. The only thing I can imagine is that the range is very small. Have you tried different values between 80-85? Swapping the wires probably doesn't work but doesn't hurt either to try. You do see that a line is added in armbianEnv? Something like: user_overlays=orangepi-5-plus-pwmfan

It doesn't have to be a PWM fan, before I used a 2 pins fan with LED which was delivered with the heat sink. With the PWM fan I've got now it didn't even work with the PWM fan connected to that fan header, so it's weird it doesn't work on yours. Do you have other overlays enabled? And you use both of these pins? But yeah if you don't hear the fan is doesn't matter much. And PWM normally goes up to 255, but at least on mine its max is at 100

@Tony3 Did you install the overlay with: sudo armbian-add-overlay name-of-overlay.dts ?? If so then try lower settings at cooling-levels like: cooling-levels = <0 50 55 60 65 70>; monitor the temperature with: armbianmonitor -m and try to raise the temperature a bit with: stress --cpu 1 or more cpus if 1 doesn't raise it enough Not sure what you mean with that one file has a line that's dealing with pwm. The cooling levels are the pwm values, the temp-trips are the values at which temperature it has to trigger each cooling level. An overlay overrules the setting in the dtb, so if you don't mention it in the overlay it uses the setting in the dtb.

Stop and disable Docker and you'll know. Did you check the temperature while this happens? "armbianmonitor -m" Tried another network cable, another place (interference), power supply, cpu governor "echo performance | sudo tee /sys/bus/cpu/devices/cpu[0-7]/cpufreq/scaling_governor". Did you install another network manager? Does dmesg show you something? Other devices connected to the OPi 5?

It could be about anything, but what did help for LinuxCNC was setting the smp affinity of the Ethernet adapter to another CPU cat /proc/interrupts | grep eth Then you'll see 2 IRQs then set these to other CPU(s). In HEX format. Convert from binary to HEX, the binary is reversed. So 00001111 is the first 4 and to HEX is F. To set them to the 5th CPU (CPU4) for example: 0001 0000 -> 10 (change the IRQ numbers) echo 10 | sudo tee /proc/irq/82/smp_affinity && echo 10 | sudo tee /proc/irq/81/smp_affinity If that does help you could set it at boot in rc.local or crontab with 10 seconds delay.

You probably already disabled the automatic deletion in the Chromium settings... It could be a website setting in Chromium Because of automatic login? Although I think this only affects access to the the keyring No user rights to the cookies folder: sudo chown -R username:username ~/.config/chromium Some flag set in Chromium: chrome://flags or at /etc/chromium-browser/default Otherwise just remove it with apt purge ... and check if everything is deleted and reinstall.

OPi 5 vs OPi 5 plus. Different Ethernet controller

@koi It's disabled in the driver https://github.com/armbian/linux-rockchip/blob/rk-5.10-rkr5.1/drivers/net/ethernet/realtek/r8125/Makefile ENABLE_PTP_SUPPORT = n ENABLE_PTP_MASTER_MODE = n

@Peter Gamma 02 I don't see any reason why a bt keyboard or mouse wouldn't work as long as it isn't a proprietary device that has a specific connection method and hidden pin that you're not able to hack. If it's a bt device that works on ble you should have an adapter that supports ble and use the right utility to connect with it. As long as it works on a PC it works on a SBC. That the person from crosstalk solutions says not all devices work and sell items selected for the orange pi (bull sh...) himself or at least make profit of it, says enough. btw this question is asked before and there is a search bar for it in the upper right.

@OP5_PLUS If you've got the same original bootloader as the one I've got (displays an orange at power on when there is no bootable storage connected), it should boot. On my nvme there is one ext4 partition with the kernel/dtb in the folder /boot (no mount). If it doesn't boot then you could check if the UUID is set right in /boot/armbianEnv.txt and in /etc/fstab (you should not have a boot mount). The UUID you'll see with the command "blkid" and might change after resizing the partition. If it still doesn't boot than you probably need to install the bootloader to MTD with armbian-install, this takes a few minutes. When you run "sudo nvme id-ns -H /dev/nvme0n1" you'll most likely see this message at the end (which indicates that the sector size is 512): LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use) LBA Format 1 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better It's not likely that it will improve that much after changing it to 4k but if you do you might want to reboot after running "sudo nvme format --lbaf=1 /dev/nvme0n1" to make sure the OS recognizes the 4k sectors correctly. Another thing I could think of is that the PCIe linking isn't working correctly. What do you see with: "dmesg | grep PCIe" fe150000 should be the M.2 PCIe 3.0 port. I guess the first digit (2) indicates the link speed... [ 5.440728] rk-pcie fe150000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.489614] rk-pcie fe190000.pcie: PCIe Link up, LTSSM is 0x130011 [ 5.489640] rk-pcie fe180000.pcie: PCIe Link up, LTSSM is 0x130011 [ 5.497438] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.522945] rk-pcie fe150000.pcie: PCIe Link up, LTSSM is 0x230011 [ 5.522972] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.549640] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.576306] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.602972] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.629640] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.656305] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.682975] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 5.709637] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3 [ 8.186316] rk-pcie fe170000.pcie: PCIe Link Fail Running this command gives probably more usefull information (output to pcie.txt as the terminal buffer might be too small): sudo lspci -vv | tee pcie.txt 0000:01:00.0 Non-Volatile memory controller: KIOXIA Corporation NVMe SSD (rev 01) (prog-if 02 [NVM Express]) Subsystem: KIOXIA Corporation Toshiba RC500 NVMe SSD 500GB LnkSta: Speed 8GT/s (ok), Width x4 (ok) As last, although I understand you want the max performance out of it, it might be possible that it's just a weak spot of your nvme but still works fast (enough) on regular daily tasks. I didn't notice much of a difference with my OPi5 with PCIe 2.0 (about the same results as you've got)

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