martivo

@Werner thanks, Ill try to update the Kernel at some point, but seems this is a KDE or plasma bug. After understanding that it's somehow related to KDE I found many bug reports with similar signal loss issues with KDE using Wayland on other devices. I don't think this is a Kernel or Armbian issue - especially since it works fine with cinnamon(wayland) and xfce. I will give a try on KDE again in 6 months and see if the bug is fixed.

I now uninstalled KDE and installed XFCE. I also tried with Cinnamon Wayland - also no problems there The issue is only present in KDE desktop. So something is wrong there. When i turn off and on the screen in XFCE, i see similar messages in syslog as when doing the same in console. 2025-02-06T14:58:10.864100+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 2025-02-06T14:58:10.897375+02:00 loovsys kernel: [drm:vop2_plane_atomic_check] *ERROR* Esmart0-win0 is invisible(src: pos[0, 0] rect[64 x 64] dst: pos[3530, 1348] rect[64 x 64] 2025-02-06T14:58:14.507317+02:00 loovsys kernel: [drm:vop2_plane_atomic_check] *ERROR* Esmart0-win0 is invisible(src: pos[0, 0] rect[64 x 64] dst: pos[3373, 2143] rect[64 x 64] 2025-02-06T14:58:14.507355+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 3840x2160p60, type: 11(if:HDMI0, flag:0x0) for vp0 dclk: 594000000 2025-02-06T14:58:14.507357+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:5aa320 rate:5940000 2025-02-06T14:58:14.507359+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! 2025-02-06T14:58:14.507361+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] dclk_out0 div: 0 dclk_core0 div: 2 2025-02-06T14:58:14.507362+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] set dclk_vop0 to 594000000, get 594000000 2025-02-06T14:58:14.523961+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 594000000 2025-02-06T14:58:14.637291+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: don't use dsc mode 2025-02-06T14:58:14.637303+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode 2025-02-06T14:58:14.637304+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x5aa320,bit_rate:5940000 2025-02-06T14:58:14.637305+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane locked!

Hi, after upgrading to Armbian 24.11.3 noble with 6.1 Kernel I have this problem that every time I turn off my TV that is connected to OPI with HDMI, then turning it back on again it will never have a HDMI signal. Same thing happens when I unplug the HDMI cable and plug it back in. I can reproduce it every single time - not just occasionally. It is not a hardware or cable problem, the exact same setup has worked flawlessly for long time with older Armbian and 5.1 kernel. I tried disabling all of the KDE power saving settings, also totally disabled kpowerdevil - with no change. SSH still works fine, the OS has not crashed. No new messages come to "dmesg" after tuning the TV off and on. Only thing that appear is in /var/log/syslog is when I turn the tv back ON again. Turning it off does not add any messages. 2025-02-06T13:21:23.984567+02:00 loovsys DiscoverNotifier[1979]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.984940+02:00 loovsys kded6[1877]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.985204+02:00 loovsys polkit-kde-authentication-agent-1[1929]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.985425+02:00 loovsys plasmashell[1897]: kde.plasmashell: requesting unexisting screen available rect -1 2025-02-06T13:21:23.985562+02:00 loovsys plasmashell[1897]: message repeated 3 times: [ kde.plasmashell: requesting unexisting screen available rect -1] 2025-02-06T13:21:23.986668+02:00 loovsys kalendarac[1985]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.986910+02:00 loovsys kactivitymanagerd[1904]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.987124+02:00 loovsys xdg-desktop-portal-kde[1930]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.991124+02:00 loovsys plasmashell[1897]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:21:23.991328+02:00 loovsys plasmashell[1897]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken. Or another time pretty similar 2025-02-06T13:26:53.652232+02:00 loovsys kactivitymanagerd[1880]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.653516+02:00 loovsys kalendarac[1964]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.654495+02:00 loovsys kded6[1852]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.655328+02:00 loovsys DiscoverNotifier[1957]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.656229+02:00 loovsys xdg-desktop-portal-kde[1905]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.657111+02:00 loovsys plasmashell[1868]: kde.plasmashell: requesting unexisting screen available rect -1 2025-02-06T13:26:53.657645+02:00 loovsys plasmashell[1868]: message repeated 3 times: [ kde.plasmashell: requesting unexisting screen available rect -1] 2025-02-06T13:26:53.658397+02:00 loovsys polkit-kde-authentication-agent-1[1904]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.665372+02:00 loovsys plasmashell[1868]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:26:53.665685+02:00 loovsys plasmashell[1868]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken. 2025-02-06T13:26:53.807759+02:00 loovsys plasmashell[1868]: message repeated 3 times: [ kf.plasma.quick: Exposed with no visual parent. Window positioning broken.] When plugging the HDMI cable back in: 2025-02-06T13:30:00.668173+02:00 loovsys kalendarac[1948]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.669049+02:00 loovsys DiscoverNotifier[1946]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.669745+02:00 loovsys kactivitymanagerd[1869]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.670412+02:00 loovsys kded6[1839]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.671016+02:00 loovsys xdg-desktop-portal-kde[1889]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.671596+02:00 loovsys polkit-kde-authentication-agent-1[1888]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.672173+02:00 loovsys plasmashell[1858]: kde.plasmashell: requesting unexisting screen available rect -1 2025-02-06T13:30:00.672548+02:00 loovsys plasmashell[1858]: message repeated 3 times: [ kde.plasmashell: requesting unexisting screen available rect -1] 2025-02-06T13:30:00.672946+02:00 loovsys plasmashell[1858]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash 2025-02-06T13:30:00.688381+02:00 loovsys plasmashell[1858]: kf.plasma.quick: Exposed with no visual parent. Window positioning broken. 2025-02-06T13:30:00.705197+02:00 loovsys plasmashell[1858]: message repeated 2 times: [ kf.plasma.quick: Exposed with no visual parent. Window positioning broken.] 2025-02-06T13:30:01.892282+02:00 loovsys CRON[6339]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs) 2025-02-06T13:30:01.895234+02:00 loovsys CRON[6338]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi) 2025-02-06T13:30:02.361046+02:00 loovsys chronyd[1553]: Selected source 212.7.1.131 (0.ubuntu.pool.ntp.org) 2025-02-06T13:30:05.222767+02:00 loovsys plasmashell[1858]: The cached device pixel ratio value was stale on window update. Please file a QTBUG which explains how to reproduce. I also tried to switch between graphical and multi-user targets. (This works fine when the TV is never turned off - i can get the console and switch back to grapgical UI) systemctl isolate multi-user.target systemctl isolate graphical.target Issuing a reboot command will bring the display back. I do not have to power cycle the entire device to get the display back. I can also get back the display after I have lost signal by switching to the multi-user.target, unplugging and plugging back in the cable. After that i can also switch back to graphical.target and everything works. Only switching between graphical and multi-user afer losing the signal will not bring back the display. If I first switch to multi-user.target and then turn off the tv, then turning it back on the display works. I can also enable the graphical target again without problems. Then the following messages appear in syslog 2025-02-06T13:37:21.290588+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 2025-02-06T13:37:24.167556+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 3840x2160p60, type: 11(if:HDMI0, flag:0x0) for vp0 dclk: 594000000 2025-02-06T13:37:24.167664+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:5aa320 rate:5940000 2025-02-06T13:37:24.167680+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! 2025-02-06T13:37:24.167693+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] dclk_out0 div: 0 dclk_core0 div: 2 2025-02-06T13:37:24.167706+02:00 loovsys kernel: rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] set dclk_vop0 to 594000000, get 594000000 2025-02-06T13:37:24.167719+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 594000000 2025-02-06T13:37:24.280906+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: don't use dsc mode 2025-02-06T13:37:24.280986+02:00 loovsys kernel: dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode 2025-02-06T13:37:24.281000+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x5aa320,bit_rate:5940000 2025-02-06T13:37:24.281011+02:00 loovsys kernel: rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane locked! Also in the dmesg the following appears [ 293.342367] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 [ 296.325415] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 3840x2160p60, type: 11(if:HDMI0, flag:0x0) for vp0 dclk: 594000000 [ 296.326327] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:5aa320 rate:5940000 [ 296.326706] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! [ 296.327137] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] dclk_out0 div: 0 dclk_core0 div: 2 [ 296.327226] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] set dclk_vop0 to 594000000, get 594000000 [ 296.327422] dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 594000000 [ 296.438292] dwhdmi-rockchip fde80000.hdmi: don't use dsc mode [ 296.438342] dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode [ 296.438380] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x5aa320,bit_rate:5940000 [ 296.438665] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane locked! As soon as I use the graphical target, then dmesg shows nothing and syslog only the messages I showed before. root@loovsys:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Armbian 24.11.3 noble Release: 24.04 Codename: noble root@loovsys:~# uname -a Linux loovsys.eu 6.1.84-vendor-rk35xx #1 SMP Thu Jan 9 02:09:01 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux Anyone experiencing similar issues or has any idea what could be the reason for it? Otherwise t

Seems this issue has been fixed, I am able to use the new kernel now with video playback. I did not do anything different...just update/upgrade.

Should this also work with the 5.10.160-legacy-rk35xx kernel?

It does boot up and graphical user interface works, but I now get segmentation fault with any video playback with ffplay or mpv (using ppa:liujianfeng1994 repo). So anyone switching kernels should be aware that there might be video playback issues.

Here is my ansible for running a small LCD over I2C https://github.com/martivo/armbian-orange-pi-5-ansible/tree/main/roles/oledinfo

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

@Efe ÇetinThank You for pointing me to the right direction! What was simple was to restore the boot/dtb/rockchip/overlay/rockchip-rk3588-opi5-i2c5-m3.dtbo file from backup and reboot....now it works again. Having to rumble through a 3.8Gb git repo to get some dts files from it just to get I2C working is really ugly solution in my personal oppinion. I am a bit puzzled about this - it is a basic functionality of Orange Pi 5 SBC and I understand Armbian tries to support these SBCs. Also Armbian provides SBC specific images. Is there a reason these dts files can't be at least packaged into Armbian OPI5 image that are related to OPI5? So it would be easy to call the "armbian-add-overlay" command at least? Is it some licencing issue? I did manage to find it in this folder in the git repo after some digging https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-5.10-rk3588/arch/arm64/boot/dts/rockchip/overlay rk3588-i2c5-m3.dts - no idea if it's even the file I need. I assume during next update the overlay will break again since I just restored the file...I guess I will give it a shot once it breaks again in the hopes to fix it permanently.

After updating my Orange Pi 5 I no longer can use the "opi5-i2c5-m3" overlay in /boot/armbianEnv.txt to activate and use i2c. Seems the file (or any ohter "opi5-i2c*") is gone from /boot/dtb folder. #uname -a Linux 5.10.110-rockchip-rk3588 #1 SMP Sun Apr 2 14:30:48 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux Is there a new or different procedure to activate i2c? Do I need to install a separate package for it? Or build the entire OS? Anyone else having the same issue? It does detect some i2c devices(0,10,2,6,7,9), but they don't seem to be related to the GPIO headers, prevoiusly I could also use (1,3,5). # ls -l /dev/i2c- i2c-0 i2c-10 i2c-2 i2c-6 i2c-7 i2c-9 I would like to use physical pins 3 and 5 - these were until now working fine.

@VidorThis post might be helpful.

I am having the same occasional freeze issue(mouse won't move, all windows frozen in place, movie audio plays but picture won't move), but I found out that unplugging the HDMI and plugging it back in seems to recover desktop withour rebooting. I have only tried this a few times so far since I only realized it recently. Can someone confirm that it solves the freeze issue for them too?

@WarHawk_AVG The onboard nvme drive KingSpec M.2 2242 NVMe 512GB (theoretical max speed 600 MB/s in specs) Here the PCI 2.0 lane of the OPi 5 is defenetly not helping and its a cheap e-bay drive... root@:~# dd if=/dev/nvme0n1 bs=1M count=10000 of=/dev/null 10485760000 bytes (10 GB, 9.8 GiB) copied, 50.3259 s, 208 MB/s The Samsung 850 EVO SSD over USB in the enclosure (theoretical max speed 540 MB/s in specs): root@:~# dd if=/dev/sda bs=1M count=10000 of=/dev/null 10485760000 bytes (10 GB, 9.8 GiB) copied, 27.1413 s, 386 MB/s The Software Raid in on the 6TB WD Red HDD (max theoretical should be 2x speed of WD Red) root@:~# dd if=/dev/md0 bs=1M count=10000 seek=100000 of=/dev/null 10485760000 bytes (10 GB, 9.8 GiB) copied, 53.1439 s, 197 MB/s Single WD Red HDD (theoretical max by spec 180 MB/s) root@:~# dd if=/dev/sdd bs=1M count=10000 of=/dev/null 10485760000 bytes (10 GB, 9.8 GiB) copied, 57.9577 s, 181 MB/s So in case of the Spinning hard drives the harddrive itself will be the bottleneck. In case of SSD the enclosure is the limiting factor. I am happy with it, more than Ill need for my purposes.

My HDMI 1.4 LG TV works just fine at 4k 60Hz on HDMI port.

Here is a video of my Orange Pi 5 setup. Hopefully someone finds it helpful!