Ryzer

@schunckt Yes, I should have clarified that drm-copy is an argument is for MPV, which according to the guide mentioned above should allow the frame-buffer to be accessed directly. It is worth noting that mpv makes use of ffmpeg under the hood. Tried with ffplay once but did not have much luck with it. last I checked VLC is not supported other than the legacy vaapi. Please see: https://linux-sunxi.org/Sunxi-Cedrus You can use the sample media from linaro: https://samplemedia.linaro.org/ Just to check are you using the ffmpeg-v4l2-request?

Those specific patches only apply to the H61X SOCs. Very Strange that hardware decoding is apparently slower. Out of interest if you run something like glxgears to see what the reported screen refresh rate is. Not impossible to be the VPU but I suspect it is more likely to be the dma-buf transfers which could be a potential bottleneck. Could you provide a more detailed log by --log-file=test1.txt When working with the framebuffer, try drm-copy instead of drm.

Some fixes are kernel specific. If I understand correctly, the "memory-region" is only necessary when using the legacy cedar driver with a more recent kernel. It is supported up to kernel 6.1. You can confirm CMA allocation by running "sudo dmesg | grep CMA" or by running "cat /proc/meminfo | grep Cma" That's interesting, although cedrus only acts as the video decoding engine while the display engine is responsible for the actual rendering.

It is not an internal module so modprobe will not work. It appears to need to built separately: https://github.com/v4l2loopback/v4l2loopback You should be able to build this if you have the kernel headers that match, the just load it by using sudo insmod instead.

If they are warnings like X is not a valid phandle reference then they can be ignored. Correct

Testing under 6.15-sunxi and unable to load the module at all. ryan@pcduino3:~/exp-drivers/hello$ sudo insmod hello.ko insmod: ERROR: could not insert module hello.ko: Invalid module format ryan@pcduino3:~/exp-drivers/hello$ sudo dmesg | tail -n 1 [ 2002.550246] module hello: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time ryan@pcduino3:~/exp-drivers/hello$ I am now wonder Is this tied to a configuration issue? Or is it something more deeper routed? One other thing I will try is bumping up GCC as AI suggest it could be a mismatch issue as the Build system uses GCC 13 but Debian comes with GCC 12. I will also try building with an Ubuntu distro as well.

Hi wel7on, I see based on the image provided that you have an unpopulated serial console port (RX, TX and GND labels). If you are up for it I would recommend soldering a header to it and if you dont already buy a usb to serial converter. Makes it easier to identify why the board may not appear to be booting. You can use a program such as putty to recieve the serial debug output. Best of luck Ryzer

Unfortunately an added challenge of the older SOC (A10, A13 & A20) generation is a limitation of the video engine which can only access the first 256MB of DRAM. I have tested this and found that the system becomes unresponsive as soon as we attempt media playback which confirms this is true. I dont yet know how it works under the hood but probably a similiar mechanism to how the kernel parses the dts in order to know what modules to load during the boot process. Allocation and ranges are set within the memory reserved node. reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; /* Address must be kept in the lower 256 MiBs of DRAM for VE. */ default-pool { compatible = "shared-dma-pool"; size = <0x6000000>; alloc-ranges = <0x40000000 0x10000000>; reusable; linux,cma-default; }; }; I have also tried increasing via overlay but it seems anything larger than 96MB gets disassociated from the dma pool. The first address that gets allocated is 0x4a000000. Trying via the extraargs method to specify a lower start address fails. Looks like the display buffers take a chunk out of CMA as well. Monitor disconnected: ryan@pcduino2-2:~$ cat /proc/meminfo | grep Cma CmaTotal: 98304 kB CmaFree: 98008 kB Monitor connected: CmaTotal: 98304 kB CmaFree: 89780 kB If I attempt to fast forward, playback falls back to software decoding and I get these errors in the log: [ 596.444060] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -16 [ 596.444103] cma: number of available pages: [ 596.444110] cma: range 0: 3@109+56@128+64@192+23@2281+8@4344+162@5726+162@7262+162@8798+162@10334+162@11870+162@ 13406+8@15608+8@17656+8@19704+162@21086+162@22622+418@24158 [ 596.444254] cma: [ 596.454008] cma: __cma_alloc: reserved: alloc failed, req-size: 350 pages, ret: -16 [ 596.454045] cma: number of available pages: l: [ 596.454052] cma: range 0: 3@109+56@128+64@192+23@2281+8@4344+162@5726+162@7262+162@8798+162@10334+162@11870+162@ 13406+8@15608+8@17656+8@19704+162@21086+162@22622+418@24158

First test was in a CLI environment so running fullscreen. Self built with no media related changes to the configuration. Edge build around kernel 6.15.0 and running on Pcduino2 For the second test I used the build scripts to create a desktop image which came to be less of a headache because less dependencies had to resolved than working purely with CLI only. This was built around kernel 6.15.4 and running on Pcduino3. This time got a blue screen within the window and lots of errors relating to dmabuf. test2.txt I currently have CMA set to 64mb, although this is overridden by the shared-dma-pool within the sun7i-a20.dtsi

I believe I have installed all the components as mpv seems to detect ffmpeg-v4l2-request. Unless adding --no-audio I get complaints about hdmi audio failing. From what I can tell mpv is at least trying to run on the video engine but something is not right:mpv-log.txt From when I tested this once before I got errors relating not being able to reserve enough memory (-12). I guess I need to hunt for cedrus patches as well as lowering CMA buffer size which conversely in the past allowed me to run a desktop image without crashing at boot. In truth the A10 is so old now that it is likely the video engine on will ever be fully supported.

Interested in giving this a go again, a slight challenge is that the connection appears to timeout when using my home network: I did find that if instead use my phone for internet I can connect to the repo fine. If I where to manually download and install the debs, what is the correct order to do so? Are there any other dependencies which need to be installed?

Difficult to say how to fix without further logs. What I am looking into and what it could possibly be related to is the simpledrm module loading alongside sun4i-drm. I wonder if you remove simpledrm then does the cursor become less erratic? Without diverging to far off topic, I suspect this related to sun4i-gpadc and how the temperature sensor is polled is carried out. The 6.12 Hdmi patches are a backport of the changes found in 6.15.

@eselarm ok thats interesting. Is it not even listed if looking for alternative kernels via armbian-config? Scrolling through the collection of community creation builds does not appear to list anything for the M1 only for the Pro Model.

@eselarm what kernel version are you currently using? As a quick check could you please provide the output of sudo dmesg | grep drm, on the off chance I may have missed something or broke again during kernel bump?

Hi @Alex83, Ok that aligns more with prior welcome screen in your prior post and the Banana Pi M1 is an A20. I dont know how long it takes for changes to flow through to automated builds after submitting a PR but I should hope they would now be present in the latest release kernel 6.12.35. Out of interest where did you source the image from as armbian pages only list images with 6.6 kernel unless you are using the image from the Banana Pi pro? While HDMI output can be convient it is not always ideal for debug purposes. For instance it is not possible to scroll back through logs using just hdmi alone.