royk

@ZBGB That probably won't do much, pin 7 is the reset pin which have to be brought to low to reset, so touch pin 7 with the grounding clip should work I think. I took, pin 6-7. Pin 5 is data in, touching that pin with the grounding clip shall probably also work.

@ZBGB As you could see in the schematics, the pins of the spi flash are not connected to the pin header. So what I did was with a small knife underneath/side of the spi flash. Check the manual and schematics for the location. It's 1.8v so don't connect with a pin from the pin header or something else. I had to try a few times before I had 2 pins shorted to make the memory unreadable and let it pick the next source (sd-card). After that you should indeed erase the flash and write with armbian-install the right image.

@ZBGB You could find a lot of info in the manual and schematics: https://drive.google.com/drive/folders/1Bre2q0bGgXQuQlYaYDMvwstpvtHLmcgX

@ZBGB Sounds like you wrote the wrong image to the SPI flash (mtdblock0). You could check the serial port with baudrate @1500000 (not every ftdi adapter is capable at this baudrate). I did that once and couldn't recover it so I shorted the data pins of the SPI flash while having a sd with armbian on it inserted, after that it booted from the sd card and I was able to write the right image to the spi

@amazingfate Yes I've seen it's in the kernel. Still haven't found the solution yet. Something that struck me is that the block sizes of NV15 are different than NV12_10 when I look at { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2, + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 }, + .hsub = 2, .vsub = 2, .is_yuv = true}, { .format = DRM_FORMAT_NV15, .depth = 0, .num_planes = 2, .char_per_block = { 5, 5, 0 }, .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, Trying some things with the libraries, next step will be adding NV12_10 back in the kernel.

@luizkun You could find the build options in the source that amazingfate has uploaded on his repository, just build ffmpeg with rkmpp and libdrm enabled, then build kodi with gles and at least gbm. But just use a newer version doesn't work, already tried. @amazingfate Tnx I will have a look if I could find something in there. But I'm 100% sure that HDR did work at the beginning, so there has been a change somewhere, still not sure if it's mpp, libdrm or something else. I was thinking something in ffmpeg, since you'd found a working solution and after that JeffyCN made some commits which makes no sense to me like: #ifndef DRM_FORMAT_NV15 // fourcc_code('N', 'V', '1', '5') #define DRM_FORMAT_NV15 fourcc_code('N', 'A', '1', '2') #endif Removed these lines but this had the same result. Something else I was thinking is that at the beginning gbm used the original driver? and now panfork. But I'm unable to make the original driver to work in gbm.

@Tony3 You've to edit the UUID in armbianEnv.txt to the one of your SD card. You could find it with the Gnome Disk-utility or with blkid in terminal. And edit the UUIDs of the mounting points in /etc/fstab For "cloning" you could use sudo cp -ra /source/* /destination

@vandyman For hw acceleration you'll need to compile it with ffmpeg configured to use rkmpp. @amazingfate At the repo of JeffyCN I saw some commits related to NV12_10, NV15 and NV16, could this be the missing link for hdr video? https://github.com/JeffyCN/xorg-xserver/commit/aa8e4176d3a4c6ee258f333e9dac8ce6ef827d4c https://github.com/JeffyCN/xorg-xserver/commit/2a9c55ef3300e696d16ff6c868332fdcfa1b5740

@amazingfate I'm really wondering if hdr video's play on yours because I have no clue what else I could try. It's telling that the format is not supported 2023-03-07 23:36:33.121 T:141589 error <general>: CEGLImage::SupportsFormat - format not supported: 2023-03-07 23:36:33.121 T:141589 info <general>: GLES: Selecting single pass rendering 2023-03-07 23:36:33.121 T:141589 info <general>: GLES: Selecting YUV 2 RGB shader 2023-03-07 23:36:33.121 T:141589 error <general>: CBaseRenderer::GetShaderFormat - unsupported format 179 2023-03-07 23:36:33.121 T:141589 error <general>: GLES: BaseYUV2RGBGLSLShader - unsupported format none I've compiled newer versions of ffmpeg and kodi, tried to revert some of the changes in ffmpeg related to your comment, but still the same result, perhaps I'm doing something wrong. Do you have the older version of ffmpeg still on your pc? Software decoding does show the video with hdr, but unfortunately a bit to slow.

@amazingfate Mine /etc/chromium-browser/default looks the same. I didn't had to at start, but after an update I'd to set that to wayland otherwise it was running in xwayland and the cpu usage was at 300/400% with 4k youtube video. I suspect there is something not right with the libs/symlinks or do these looks the same on yours? ls -l /usr/lib/aarch64-linux-gnu/libEGL* lrwxrwxrwx 1 root root 20 feb 28 14:59 /usr/lib/aarch64-linux-gnu/libEGL_mesa.so.0 -> libEGL_mesa.so.0.0.0 -rw-r--r-- 1 root root 292072 feb 28 14:59 /usr/lib/aarch64-linux-gnu/libEGL_mesa.so.0.0.0 lrwxrwxrwx 1 root root 15 jan 4 2022 /usr/lib/aarch64-linux-gnu/libEGL.so.1 -> libEGL.so.1.1.0 -rw-r--r-- 1 root root 68040 jan 4 2022 /usr/lib/aarch64-linux-gnu/libEGL.so.1.1.0 ls -l /usr/lib/aarch64-linux-gnu/libGLESv* lrwxrwxrwx 1 root root 21 jan 4 2022 /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0 -rw-r--r-- 1 root root 141408 jan 4 2022 /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 lrwxrwxrwx 1 root root 18 mrt 6 14:01 /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.1.0 -rw-r--r-- 1 root root 149600 jan 4 2022 /usr/lib/aarch64-linux-gnu/libGLESv2.so.2.1.0 ls -l /usr/lib/aarch64-linux-gnu/libmali-x11/ lrwxrwxrwx 1 root root 36 feb 18 18:02 libEGL.so -> libmali-valhall-g610-g6p0-x11-gbm.so lrwxrwxrwx 1 root root 36 feb 18 18:02 libEGL.so.1 -> libmali-valhall-g610-g6p0-x11-gbm.so lrwxrwxrwx 1 root root 36 feb 18 18:02 libgbm.so.1 -> libmali-valhall-g610-g6p0-x11-gbm.so lrwxrwxrwx 1 root root 36 feb 18 18:02 libGLESv2.so -> libmali-valhall-g610-g6p0-x11-gbm.so lrwxrwxrwx 1 root root 36 feb 18 18:02 libGLESv2.so.2 -> libmali-valhall-g610-g6p0-x11-gbm.so -rw-r--r-- 1 root root 43763352 feb 18 18:02 libmali-valhall-g610-g6p0-x11-gbm.so lrwxrwxrwx 1 root root 36 feb 18 18:02 libOpenCL.so.1 -> libmali-valhall-g610-g6p0-x11-gbm.so

@amazingfate With Kodi I think you're right about that this was the cause of why it was using egl. It does play normal hevc (at least the one I tried) but none of the hdr, I've tried a lot of different files of which I'm sure aren't drm protected. Chromium is working here, but runs in xwayland, the moment I set "Preferred Ozone platform" to wayland in chrome://flags the hw decoder stops working, while I'd to set that before I reinstalled everything to make it work, it's not a real problem but it uses a bit more of the cpu. Moonlight-qt does work, at default it also start in xwayland, but after installing qtwayland5 and running it with "QT_QPA_PLATFORM=wayland moonlight" it does run native in wayland. kodi-error-hdr.txt

@amazingfateYes I saw that, but the setting is at "direct to plane". I think it falls back to egl although it isn't in the log. Besides that, hw acceleration in Chromium also doesn't work under Wayland, but it does under xwayland, moonlight-embedded also doesn't work with Wayland. It all worked before. It seems that somehow gles doesn't work with Wayland/gbm

@PajPaj I just did a clean install, unfortunately I can't get it to work either. @amazingfate Do you've an idea what could be wrong? Installed everything the same as before except the udev rules and the lines in rc.local because these are installed automatically by your package (tried to set these manually to be sure). I assume that installing the original driver will cause gbm/X11 stop to work? Chromium does work with hw accelaration, but only when I set the Preferred Ozone platform to X11, while before the clean install it only worked with this setting at Wayland. With your image "Armbian_23.05.0" I've got the same result. (audio over HDMI is working) cat /proc/version Linux version 5.10.110-rockchip-rk3588 (armbian@next) (aarch64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Thu Mar 2 08:08:28 UTC 2023 kodi.log lib-list.txt

I guess this needs to be done in the driver, so no easy switch unless you could make that. I've seen there is some information (GitHub commits) how they did with the RPI4. Tony's advice will be easier😁

No problem, I know after a few posts this restriction is gone. Armbian 23.02.2 with the legacy Rockchip kernel.

Time stamping parameters for eth0: Capabilities: hardware-transmit software-transmit hardware-receive software-receive software-system-clock hardware-raw-clock PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off on Hardware Receive Filter Modes: none all ptpv1-l4-event ptpv1-l4-sync ptpv1-l4-delay-req ptpv2-l4-event ptpv2-l4-sync ptpv2-l4-delay-req ptpv2-event ptpv2-sync ptpv2-delay-req

echo none | sudo tee /sys/class/leds/status_led/trigger To set it "permanent" add this line to rc.local echo none > /sys/class/leds/status_led/trigger The red LED you can't turn off by software, the ethernet LED I expect it is possible, but I don't know how.

@luizkunThen you're not running it directly from the login screen. It should show gbm. If the video is really not hdr I don't know why it doesn't show the video under Wayland, but I guess it will work under gbm.

@luizkunThe Kodi amazingfate has build is using GLES. What do you see in Kodi at: Settings -> System info -> Video -> Windowing system

I did also have these problems at the beginning, but I don't have seen them for about a month I think. No sure what made the difference, I thought it was because there were some changes made in the drivers/kernel code. I changed some settings in the kernel config, like disabled most of the debugging options, default scheduler at performance, timer at 1000hz, set the compiler at performance and some other settings with the scheduler. Maybe this fixed the lockups? Although this probably won't make a difference for the behavior of the cursor, or could the timer clock at 1000hz have reduced the flickering? There are some minor problems like night light doesn't always work immediately but does start after I turn on the receiver or reboot the tv.

hdmi dummy adapter, I don't know anything else

Perhaps you've installed something for nvidia? Check: apt list --installed *nvidia* if you find something from nvidia and remove with sudo apt remove ....

Did you set: Enable legacy vnc protocol with "require password" filled in a username and password Updated the package Try to connect with ip address instead of hostname Maybe there is a firewall in between or another service on the OPI running on the same port?

From the gui. Settings -> Sharing -> Remote Desktop You could update it with sudo apt install gnome-remote-desktop

I don't know with what you try to connect it to, if you try to connect with vnc then "Enable legacy vnc protocol". It could be that the notification to accept the client was not visible, you could set "Require password" (3 dots after legacy vnc protocol) as workaround.