royk

@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

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