Mali OpenGL support on Allwinner platforms with mainline Linux

As most people know, getting GPU-based 3D acceleration to work on ARM platforms has always been difficult, due to the closed nature of the support for such GPUs. Most vendors provide closed-source binary-only OpenGL implementations in the form of binary blobs, whose quality depend on the vendor.

This situation is getting better and better through vendor-funded initiatives like for the Broadcom VC4 and VC5, or through reverse engineering projects like Nouveau on Tegra SoCs, Etnaviv on Vivante GPUs, Freedreno on Qualcomm’s. However there are still GPUs where you do not have the option to use a free software stack: PowerVR from Imagination Technologies and Mali from ARM (even though there is some progress on the reverse engineering effort).

Allwinner SoCs are using either a Mali GPU from ARM or a PowerVR from Imagination Technologies, and therefore, support for OpenGL on those platforms using a mainline Linux kernel has always been a problem. This is also further complicated by the fact that Allwinner is mostly interested in Android, which uses a different C library that avoids its use in traditional glibc-based systems (or through the use of libhybris).

However, we are happy to announce that Allwinner gave us clearance to publish the userspace binary blobs that allows to get OpenGL supported on Allwinner platforms that use a Mali GPU from ARM, using a recent mainline Linux kernel. Of course, those are closed source binary blobs and not a nice fully open-source solution, but it nonetheless allows everyone to have OpenGL support working, while taking advantage of all the benefits of a recent mainline Linux kernel. We have successfully used those binary blobs on customer projects involving the Allwinner A33 SoCs, and they should work on all Allwinner SoCs using the Mali GPU.

In order to get GPU support to work on your Allwinner platform, you will need:

The kernel-side driver, available on Maxime Ripard’s Github repository. This is essentially the Mali kernel-side driver from ARM, plus a number of build and bug fixes to make it work with recent mainline Linux kernels.

The Device Tree description of the GPU. We introduced Device Tree bindings for Mali GPUs in the mainline kernel a while ago, so that Device Trees can describe such GPUs. Such description has been added for the Allwinner A23 and A33 SoCs as part of this commit.

The userspace blob, which is available on Free Electrons GitHub repository. It currently provides the r6p2 version of the driver, with support for both fbdev and X11 systems. Hopefully, we’ll gain access to newer versions in the future, with additional features (such as GBM support).

If you want to use it in your system, the first step is to have the GPU definition in your device tree if it’s not already there. Then, you need to compile the kernel module:

You should be all set. Of course, you will have to link your OpenGL applications or libraries against those user-space blobs. You can check that everything works using OpenGL test programs such as es2_gears for example.

Author: Maxime Ripard

Maxime Ripard is an embedded Linux engineer at Bootlin, which he joined in March 2011. In the past, Maxime has worked at France Telecom on embedded Linux systems, and at Archos on Android-based tablets. At Bootlin, Maxime is in charge of Android projects and training, and also handles various embedded Linux and kernel projects. More details...
View all posts by Maxime Ripard

It’s limited to Allwinner Chips because Mali implementation varies througout every different Soc producer.
Mali can be the same, but bus, interrupts, features etc. can be different.
Someone correct me if I’m wrong.

first of all, please be patient, Maxime did this work for open source.
You can’t expect it to be answered in 5 days…
Anyway, if you join linux-sunxi google group,
you will find my patch that supports A20/Dts and a patch for mali clock.
Anyway, everything ends with error 0x3003 on malitest,
so it takes some more time to fix this.
Let’s cooperate all together.

Ok, I’ll try to be )) Sorry.
I am just a bit disappointed by spending my time on a solution which is not tested and is not working. We all have been waiting such news about Mali support and I was expecting a bit more (at least a tested and working solution).

with kernel 4.13.4, trying to insmod mali.ko,
it gives me “Couldn’t reserve our memory region”.
So I’ve seen you’ve released a patch time ago to define a memory-region in dts.
But now it’s not there anymore.
Am I on right path?
I’ve also tried to extend cma with bootargs “cma=128M”

But on fd = 4(/dev/mali) don’t seem to be syscalls with errors.
The only thing strange to me is mmap2 on mali with offset 0x10000000.
But it returns a valid virtual memory address and I don’t how normally works Mali.

Try to recompile r6p2 kernel driver mali.ko with BUILD=debug instead of release.
At least it is more verbose and can give more informations.
I have to give it a try before debugging into mali.so assembly tomorrow.

I’ve noticed that if surface is not created, it doesn’t free cma memory.
This is why I get error from Kernel Mali Driver.
So it’s not clear where is the problem.
Anyway inserting driver with
“insmod mali.ko mali_debug_level=6”
makes it very verbose and can help

Hi Giulio,
you did good findings but it seems to take a very loooong time to make it work.
I am just wondering again what was the reason for Maxime to advertise this unfinished work.?
Just let us know if you are lucky to fix this.
Thanks

at this time I’ve found that basically Mali can’t find a display,
this is why it gives me 0x3003 BAD_ALLOC.
I’ve tried both fbdev and wayland versions.
I’m interfacing more with open-source.
You can join IRC channel #linux-sunxi.
There you can find help if you’re patient to have an answer.
Maxime made it work, its work is finished.
The point is that we’re missing something at kernel level.

Linux-sunxi team is doing a huge effort,
you can see it on git commits on linux-sunxi github sunxi-next branch.
And Maxime is the Maintainer.

Hi Sergey,
I’m trying to recompile all buildroot with an older toolchain(4.9),
because you can notice that libMali is compiled with 4.8.2.
Maybe that could cause such problem.
And also it’s not clear vfp/neon.
I give it a try.

Finally works! Thanks to Net147 on #linux-sunxi IRC channel,
you have to compile linux with at least:
CONFIG_DRM_FBDEV_OVERALLOC=200
to achieve double buffer,
since libMali.so r6p2 can’t support single buffer.
Now malitest works.
I try with Qt5 now.

It works also with Qt5,
keep cma area size as big as 128M.
Kernel can take that memory if unused,
so don’t worry to waste it.
In that memory you have to put all your framebuffers but also all egl stuff, that is not few.

Here is my dmesg http://sprunge.us/ZTJW
Can you look and see if you find something.
It would be nice if you also share your device tree nodes regarding Mali.
Here is my device tree sources that I use for my kernel.

This is great; wondering about Allwinner aarch64 SoCs – does this agreement extend to (or are there available) libraries for sun50i models (A64 with Mali 400, H5 with Mali 450) under 64-bit Linux? This would be really great for boards like the PINE64/Orange Pi Prime.

This is indeed great news. As a linux noob, question is: Will be/is there a distro, which already contains everything needed for the Allwinner/A2x SOC based GPU being accelerated? EG all multimedia dsitros like openelec, kodi based, etc..? I am searching for this for quite a while, since i own a Cubietruck (A20)… And i can say: it has been a pain the a….

Thank you, Maxime! But I’m very new for allwinner A33, I just have one office building package, kernel version is 3.4, Only I can do is follow the steps of office release, would you please provide me some basic article which can help me understand how to build in my way? as you know, it is hard to get documents from Allwinner. Thanks!