royk

The bootloader does work, but I can't boot into X. After the kernel is loaded it's repeating messages on the screen with "Failed to start network manager", "failed to start D-bus system message bus", "Failed to start User login management", "Failed to start system logging service" I did a manual install, removed all partitions on the nvme, created one ext4 partition, then mounted your "image for mtd install with gnome". cp -ra /location/image/* /location/nvme/ Changed the UUID in extlinux and fstab, then wrote the bootloader /usr/lib/linux-u-boot-current-orangepi5_23.02.3_arm64/rkspi_loader.img to mtdblock0. Oops I think I'd to check the disk first: " re-mounted 715e6119-a664-4ffb-8e5f-1ef95ca8a651. Quota mode: none." Ok wrote the image to usb and this booted correctly, then I installed it to the nvme with "armbian-install" and now it boots from nvme, so everything is working correctly.

Thanks, nice to see having more options. AFAIK the MTD bootloader of opi-5 doesn't support ext4, so the boot manager has to be on an ext2 or fat partition.

@amazingfate HDR problem is solved by https://github.com/JeffyCN/FFmpeg/commit/2e578b9ce6f46c4e2ab7f5bc3e066a7be1d586bc

@ZBGB That sucks, are you sure that you've the right settings and the adapter support these? I assume you know the adapter has to be at 3.3v and rx from the adapter has to be connected to tx on the board?

@vandyman Ok tnx, to be able to watch hdr at the moment it's only possible from gbm with gles rendering, I'm almost certain it doesn't work. I think that ffmpeg needs some adjustments due to changes in mpp. @amazingfate Found something, in ./mpp/codec/dec/h265/h265d_refs.c there is a line "s->h265dctx->pix_fmt |= MPP_FRAME_HDR;" when I change that to "s->h265dctx->pix_fmt |= MPP_FMT_YUV420SP_10BIT:" it plays HDR again. I assume a proper way to fix this is to add "MPP_FRAME_HDR" to ffmpeg?

@vandyman And does that one play HDR videos? @amazingfate and @luizkun I haven't found the exact problem yet, but luckily found a backup. With this backup it does play HDR videos again, but with the HDR Vision the colors don't match. After compiling a new version of mpp the same problem occured as before. So the problem should be in mpp or the combi of the new version with ..... The file I've uploaded is the working one for HDR10, is from date 2022-11-16 librockchip_mpp.so.0

@ZBGB That's what I thought when mine didn't boot whatever I tried. The voltage you read could be a bit lower because it's connected but since the pin should be pulled low to reset it doesn't matter anyway.

@ZBGB Did you look at the serial output? Perhaps that will make it a bit easier to find out what's going wrong. And how do you write the image to the SD card and which image?

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