Mali tests fails on Debian with compositors in recovery

[Seriousattempts]

My testing methods have been unorthodox.

Fcking nuts tbh.

I was trying to run this in chroot through recovery not through termux. What I've learned is that a lot depends on the kernel module and the kernel itself. For example if the GBM doesn't have Mali/Panfrost support (I can only run a 4.14.193 kernel given by the supplier), it won't run. From what I can tell, the following didn't work in recovery:

• Mesa Panfrost (open-source driver)
• Panfrost Vulkan backend
• Zink translation layer
• VirGL virtualization

kmscube doesn't work at all. Segmentation fault for kmscube + Zink, kmscube + panfrost, kmscube + VirGL always aborts. Only modetest 1 and 2 worked for presenting an image.

This is what I learned about the GPU for my device specifically to try and run these tests:

GPU Driver - ARM Mali-G52 2 cores
r1p0 0x7402
Version: r27p0-01eac0 (UK version 11.29)
Kernel Module:

Name: mali_gondul.ko (532,480 bytes)
Location: /mnt/vendor/socko/mali_gondul.ko
Mali sysfs parameters:
  corestack_driver_control      : N
  mali_debug_level              : 2

Mali Hardware:
Device: 60000000.gpu (memory-mapped at address 0x60000000)
IRQ: 27 (job scheduler and MMU interrupts)
Architecture: "Gondul"

GPU Power Management:
DVFS (Dynamic Voltage/Frequency Scaling) active
Operating points:
Index 2: 384 MHz @ 0.7V
Current: 614.4 MHz @ 0.75V
Power states tracked: gpu_power_on, gpu_clock_on

OpenGL ES Support:
Display Drivers - Spreadtrum DRM/KMS

Platform Drivers:

sprd-drm-drv: Main DRM driver framework
sprd-dpu-drv: Display Processing Unit driver (0x20300000)
sprd-dsi-drv: MIPI DSI controller driver (0x20400000)
dpu-dvfs: Display frequency/voltage scaling

DRM Device:
Device node: /dev/dri/card0 (major 226, minor 0)
Compatible: sprd,display-subsystem

Display Output:
Connector: card0-DSI-1 MIPI DSI (Display Serial Interface)
Panel: LCD FC11339
Single Mode Display: Only one supported display mode {id=1, 752×1336, 60.0024fps}
Rotated to 1336×752 (landscape mode active)
VSYNC Period: 16,666,000 nanoseconds (16.666ms per frame)
App VSYNC Offset: 1,000,000 nanoseconds (1ms buffer time)
Presentation Deadline: 16,666,000 nanoseconds (frame must be ready within 16.666ms)
No Variable Refresh Rate: Fixed 60Hz operation only
Pixel Format: RGBA_8888 (32-bit color, 8 bits per channel)
Pixel Clock: 64 MHz (from cmdline)

Graphics Memory Management
ION Allocator:
Device: /dev/ion (character device 10:63)
Permissions: 0666 (world read/write)

No access to:
/dev/dri/renderD128 (render nodes not enabled)
/dev/fb
Rotation must be done at compositor level, not DRM plane level
GBM doesn't use Mali/Panfrost for buffer allocation even if MESA is compiled to the rootfs

GPU Cooling/Thermal
Thermal Management:
Device tree node: gpu-cooling-devices
Integrated with SoC thermal zones
DVFS adjusts frequency based on temperature
Works with display DVFS for power optimization

Driver Architecture
Built-in Components:
DRM core: Built into kernel
Spreadtrum DPU: Built into kernel
Spreadtrum DSI: Built into kernel

Loadable Modules:
Mali GPU: mali_gondul.ko (only GPU component as module)
Dependencies: mmdvfs.ko (multimedia DVFS)


Others:
modetest output:
#0 752x1336 60.00 752 770 774 782 1336 1352 1356 1364 64000 flags: ; type: preferred, driver
modetest proves DRM works showing TEST 1 (Basic Mode Setting) and TEST 2 (Plane Rendering with Pattern) on Debian
modetest -M sprd -s 84:752x1336
modetest -M sprd -s 84:752x1336 -P 27@79:752x1336@XR24
kmscube showed frozen cube before the image disappeared on Alpine

========== modetest output ==========
`Spreadtrum SoCs' DRM Driver` on driver `sprd` (version 1.0.0 at 20180501)
Encoders:
id	crtc	type	possible crtcs	possible clones	
83	0	DSI	0x00000001	0x00000000

Connectors:
id	encoder	status		name		size (mm)	modes	encoders
84	0	connected	DSI-1          	62x107		1	83
  modes:
	index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 752x1336 60.00 752 770 774 782 1336 1352 1356 1364 64000 flags: ; type: preferred, driver
  props:
	1 EDID:
		flags: immutable blob
		blobs:

		value:
	2 DPMS:
		flags: enum
		enums: On=0 Standby=1 Suspend=2 Off=3
		value: 0
	5 link-status:
		flags: enum
		enums: Good=0 Bad=1
		value: 0

CRTCs:
id	fb	pos	size
79	0	(0,0)	(0x0)
  #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 
  props:
	81 dpu version:
		flags: immutable blob
		blobs:

		value:
			6470752d7234703000
	82 corner size:
		flags: immutable range
		values:
		value: 0

Planes:
id	crtc	fb	CRTC x,y	x,y	gamma size	possible crtcs
27	0	0	0,0		0,0	0       	0x00000001
  formats: XR24 XB24 AR24 AB24 RA24 BA24 RX24 BX24 RG16 BG16 NV12 NV21 NV16 NV61 YU12
  props:
	6 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 1
	26 IN_FORMATS:
		flags: immutable blob
		blobs:

		value:
			01000000000000000f00000018000000
			00000000580000005852323458423234
			41523234414232345241323442413234
			52583234425832345247313642473136
			4e5631324e5632314e5631364e563631
			5955313200000000
		in_formats blob decoded:

	29 rotation:
		flags: bitmask
		values: rotate-0=0x1 rotate-90=0x2 rotate-180=0x4 rotate-270=0x8 reflect-x=0x10 reflect-y=0x20
		value: 0
	30 zpos:
		flags: immutable range
		values: 0 0
		value: 0
	31 alpha:
		flags: range
		values: 0 255
		value: 255
	32 pixel blend mode:
		flags: enum
		enums: None=0 Pre-multiplied=2 Coverage=1
		value: 0
	33 FBC header size RGB:
		flags: range
		values: 0 4294967295
		value: 0
	34 FBC header size Y:
		flags: range
		values: 0 4294967295
		value: 0
	35 FBC header size UV:
		flags: range
		values: 0 4294967295
		value: 0
	36 YUV2RGB coef:
		flags: range
		values: 0 4294967295
		value: 0
	37 pallete enable:
		flags: range
		values: 0 4294967295

====== Testing information =======
DRM mode setting works (drmModeSetCrtc)

The mali_gondul.ko is generic, like the libGLES_mali.so file build for it. But my Mali device uses recovery android as it's boot.img as I believe it's use a repurposed TS10 (car multimedia with ums_512_1h10_natv)

Note that I had the mali module loaded when I tested this. Here's a test script of running what I ran in recovery.

Can see more files on how I did that here (required TWRP and splitting the userdata then magisk, busybox chroot-distro and termux with custom scripts) https://github.com/Seriousattempts/rp3plus-native-attempts/tree/main/chroot/Debian

Why not just while Android is running if you read and checked those files? Well "4GB" of ram with 1.8 GB of RAM always being used. Why not change kernels? Well again, I tried, didn't work. The closest I got to a "working" kernel was Samsung Galaxy Tab 8 A Ubport.

[Seriousattempts]

With that being said, may still work in normal termux proot for an mali device if someone wants to give that a run. If not, here's 2 alternative's I've noticed that has worked for some:

• https://www.reddit.com/r/termux/comments/15ip7a1/comment/jv09ny9/
• https://www.reddit.com/r/termux/comments/1in8uo2/comment/mcck0fu/
• Can't achieve OpenGL 4.3 with VirGL LinuxDroidMaster/Termux-Desktops#68

If I wasn't trying to run this on recovery using init_second_stage as PID1 I would try but eh, I'm stupid and trying to port those specific build packages to their debian equivalent (those were made for ubuntu if I remember correct) would require more work that I'm not willing to give at the moment.

[lfdevs]

Thank you for your feedback. I previously tested this driver on a Pixel 6 Pro (Mali-G78 MP20), and it also failed to work properly—possibly because I wasn’t using a custom kernel or a Magisk module. As far as I know, the Panfrost driver has very poor compatibility on Android; so far, I’ve only seen a very small number of successful cases. I’ll attempt more tests, and if it still doesn’t work, I’ll remove the panfrost option in the next build.

If you're also using a Termux native container, you can try the vulkan-wrapper-android package, which enables hardware acceleration via Android's Vulkan driver. In my tests, it works well on the Mali-G78 MP20 and should also function properly on the Mali-G52. lfdevs/termux-packages#1 (comment)

[Seriousattempts]

As far as I know, the Panfrost driver has very poor compatibility on Android

As we noticed, it depends on the kernel driver. This is another mesa-android project I noticed but decided not to test https://github.com/kadrim/mesa-android