royk

@Kuu Tirronen Nice found that hack, but I'm questioning if you've followed the right steps, so which steps did you follow? Wayland will probably give better results, for hardware video decoding you'll need software that will make use of mpp. Amazingfate made a repo for jammy with panfork mesa and a repo with software build with rkmpp hw acceleration there are a few topics about this, also don't forget to install malirun from his repo, this will set the udev rules that's needed for hw acceleration. For Panfrost this option should be disabled: cat /boot/config* | grep CONFIG_DRM_IGNORE_IOTCL_PERMIT For mali blob you'll need the right driver and is not compatible with panfork mesa and not every driver supports X11.

@NiLace Check the UART output, page 96 in the manual.

@dkg It seems like your cec-client is missing the linux cec framework api, but with what do you want to use it? If it's with kodi you'll need to configure this before you compile it. If you want to use cec-client outside of kodi, you could try to compile a new one. First remove the installed version. apt-get update apt-get install cmake libudev-dev libxrandr-dev python-dev swig git clone https://github.com/Pulse-Eight/libcec.git mkdir libcec/build cd libcec/build cmake -DHAVE_LINUX_API=1 .. make -j8 sudo make install sudo ldconfig

@dkg Can't test it at the moment, but it did work. Don't you have a /dev/cec0 device? How did you test, which version, dtb?

@PajPaj You could try: https://github.com/philn/glide

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.