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.

Hi @Alex83, There was a kernel bump prior to submission so HDMI fixes only apply to 6.12.35. If you device is indeed the Banana Pi M3 then that is A83T SOC and not the A10 or A20 for which these patches apply.

Oh right, that is fairly old. My USB sticks are not in exFat format which may explain why I have not encoutered such issues. I will have to try re-formatting one as exFat to see if encounter the same kind of issue. That said after a bit of digging, it could be related to this? https://www.cvedetails.com/cve/CVE-2025-22036/

Right, judging by only one instance in the topwise a721 dts: [ 3.446799] sun4i-drm display-engine: No panel or bridge found... RGB output disabled I am inclined to think that is configuring the panel. This can be validated by checking ls /sys/devices/platform/display-engine/drm/card0 or looking for simple-panel in lsmod. I suspect it may be a pin-muxing issue where the pins are not being set. now what these are set depends on the lcd panel type which could be LVDS or a parallel panel. I believe it should be LVDS but just wanted to confirm. Now the A10's pin controller section within the dtsi does not map out as many function compared A20 dtsi, so within the topwise a721 dts under the pio node the display pins need to be declared and their function stated. Secondly attach the pin control handle to tcon0. For example: &pio { lvds0_pins: lvds0-pins@0 { pins = "PD0", "PD1", "PD2", "PD3", "PD4", "PD5", "PD6", "PD7", "PD8", "PD9"; function = "lvds0" }; }; &tcon0 { pinctrl-names = "default"; pinctrl-0 = <&lvds0_pins>; };

Note you can provide more diagnostics with armbianmonitor -u and then pasting the link to the report here. Maybe something could have gone wrong in the unpacking process or linger system components causing issue? Just trying to rule out all other possibilities before putting it down to regression. I haven't encountered this on my system or aware of anyone else having the same problem. That's not of course to say their could be a problem.

Ok the backlight turning on confirms that it uses PWM0. It is worth noting at this point that PWM works but is not perfect on the A10 as the pwm-sun4i driver assumes all devices are 16-bit resolution however only the lower 8-bits are only valid on the A10. Looking into this again it would probably make it easier for yourself to include the panel parameters within the DTS as well. As mention earlier the "starry,kr070pe2t" is included within panel-simple.c. What is the current output of sudo dmesg | grep drm? I am curious to see if there is even an attempt to bind the panel. All the best Ryzer

Just to confirm this is a regression issue could you also test with a clean image rather than an upgrade? It is possible something could have gone wrong during the upgrade. If I understand correctly you are only using an SD card for booting, and the kernel and main OS reside on the SSD. have you preformed an integrity check of the USB, just to ensure there is no possible file corruption? Could you also please provide the output of mocp --debug? Best of luck Ryzer

Thats the Plan I just wanted to update my fork first in case any problems occured before submitting. Just wanted to check, seeming as I am covering 2 areas (dts patches and drm patches) would you still prefer this to be in a single commit? The original purposing being to add hdmi support for the Pcduino2 and Pcduino3, but evolved due to the drm breakages.

Indeed. Comparing sources between kernel 6.12 and 6.15, I could only spot one difference in the drm_atomic_helper_connector_hdmi_check() function so I have tested applying this via a patch and the build compiled successfully. Testing the build I found that reboot now works and shutdown finishes with just a blank display. If it is indeed the same issue then this patch will likely fix the problem. Based on what I found it may impact certain Rockchip Socs also: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/display/drm_hdmi_state_helper.c?h=linux-6.15.y&id=0d337b40ca1e532af42516d9e9024baad466319a drv-drm-atomic-helper-null-pointer-fix.patch Thanks Ryzer

The good news is that we get a working display. The bad news is that it creates a new problem. when Either shutting down or rebooting a kernel panic is triggered. After a bit more digging I found the reason that the drm_hdmi_connector_mode_valid patch failed is because the function does not exist under kernel 6.12. I dont know yet if it may be necessary to include it yet or if drm_atomic_helper_connector_hdmi_check needs some further tweaks. Thanks Ryzer

Recreated hdmi patches under kernels 6.12 and kernels 6.15 in pcduino-boards-fixes branch. When attempting to build with current kernel 6.12.30, with drm patches for sun4i_hdmi_enc.c to use drm_hdmi_connector_mode_valid and drm_atomic_helper_connector_hdmi_check fails to compile. when just applying drm_atomic_helper_connector_hdmi_check patch build compilation is successful. Just need to verify this build works. For kernel 6.15, with just the hdmi patches, we get a working HDMI display output: