Mali binary driver

This page describes how to install and set up the binary userspace drivers that a fully working system for sunxi still requires.

= 3D driver and setting up 2D/3D acceleration in X =

The sun4i and sun5i use a Mali400MP1 and sun7i uses Mali400MP2 (dual-core GPU). We have support available for several versions of the mali binary driver stack, even though our kernel tends to come with the R3P0 version. We support framebuffer and X11 as windowing systems.

Mali kernel driver
First get a working display driver.

The default config for the kernel should have the Mali kernel drivers as modules. You should be able to load it by simply running

 modprobe mali

A cleaner solution is to have the module autoloaded at boot, by adding the following to /etc/modules:  ump mali

The default permissions of /dev/ump and /dev/mali make these unusable for normal users. Add a file to /etc/udev/rules.d/, perhaps called 50-mali.rules, with the following content:  KERNEL=="mali", MODE="0660", GROUP="video" KERNEL=="ump", MODE="0660", GROUP="video" This should give a user belonging to the group video the right permissions to use the mali succesfully.

Installing the Mali binary drivers
We have an all in one repository to do this for you, called sunxi-mali.

You need libdri2-dev,xorg-dev,xutils-dev for success build.

 apt-get install git build-essential libdri2-dev xorg-dev xutils-dev


 * Some distributions have libdri2 compiled in X11 binary, so there is libdri2 separated in a github repo https://github.com/robclark/libdri2, to compile it you need install libdrm-dev

First we need to clone the repository, which is slightly less straightforward due to our use of git submodules for the actual binaries. Make sure to do this on the target system, and as root, as we will install directly into your system.

 git clone https://github.com/linux-sunxi/sunxi-mali.git cd sunxi-mali git submodule init git submodule update

Now you can descend into sunxi-mali, if all goes well, you should only need to do this:

 make install

This should autodetect the version of the kernel driver, which ABI you are on, and whether you want X11 or framebuffer support (by looking for libX11). It will then build libUMP.so (ARM Mali's Universal Memory Provider), install libUMP and the GLES/EGL binaries into /usr/lib/, and install the UMP and EGL/GLES headers to /usr/include/.

If mali needs to be used in X11 desktop, then setting up X is also necessary (the default fbdev x11 driver will not work!). Move on to the next section.

Setting up X
If you are using the framebuffer console only, and have verified that the framebuffer version of the Mali binaries was installed, then you can of course skip this section.

The Mali GPU provides acceleration of 3D OpenGL ES2 apps. However, there are also 2D acceleration features inside the A10/A20 such as hardware cursor and the G2D engine to speed up drawing in X. You can enable 2D acceleration in X using the xf86-video-fbturbo driver regardless of whether the X11 version of the binary Mali drivers is installed or not. If the X11 version of the Mali binary drivers are installed, the fbturbo driver will automatically detect this and provide OpenGL ES2 integration for 3D apps.

To compile and install the xorg driver, first install the following development packages for building X drivers:

 apt-get install git build-essential xorg-dev xutils-dev x11proto-dri2-dev libltdl-dev libtool automake

Now get the fbturbo xf86 driver (from the 0.4.0 release tag):

 git clone -b 0.4.0 https://github.com/ssvb/xf86-video-fbturbo.git

The older stable driver, which does not provide 2D acceleration, is available at git://github.com/linux-sunxi/xf86-video-mali.git

Compile and install the fbturbo xf86 driver (this is necessary even if you already had it installed for 2D only):

 autoreconf -vi ./configure --prefix=/usr make make install

Then copy over the default xorg.conf for the fbturbo driver (the preferred location for xorg.conf would be /etc/X11/ instead of /usr/share/X11/xorg.conf.d/):  rm /usr/share/X11/xorg.conf.d/99-sunxifb.conf cp xorg.conf /etc/X11/xorg.conf

You should now be able to (re)start your xserver, have a quick look through /var/log/Xorg.0.log to verify that the correct driver has been loaded:

... (II) Module fbturbo: vendor="X.Org Foundation" compiled for 1.12.4, module version = 0.4.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 12.1 (II) FBTURBO: driver for framebuffer: fbturbo (--) using VT number 7 ...

Also make sure that you don't have the following lines in it (if you do, then a clean rebuild and reinstallation of the fbturbo driver is needed):

(II) FBTURBO(0): no 3D acceleration because the driver has been compiled without libUMP (II) FBTURBO(0): if this is wrong and needs to be fixed, please check ./configure log

Verifying the EGL/GLES driver stack
From the mali-sunxi repository, you can run:

 make test test/test

And you should be able to see a smoothed triangle, either written out to the top left corner of the framebuffer, or in an X window. The console will tell you which renderer is being used:

... GL Vendor: "ARM" GL Renderer: "Mali-400 MP" GL Version: "OpenGL ES 2.0" ...

Success!

Mesa libraries are still in the way
If your are seeing this:

libEGL warning: failed to create a pipe screen for Mali DRI2 libEGL warning: DRI2: failed to open Mali DRI2 (search paths /usr/lib/arm-linux-gnueabihf/dri)

Then the current best advice is to move the mesa-egl aside:

 mv /usr/lib/arm-linux-gnueabihf/mesa-egl/ /usr/lib/arm-linux-gnueabihf/.mesa-egl/

Awkward, but at least gets you something workable.

Missing X symbols
symbol lookup error: /usr/lib/libGLESv2.so.2: undefined symbol: XextCreateExtension

This is due to bad library dependencies of the libMali.so binary we have been given. We have worked around it in our manually built libUMP.so. Check that the loaded libUMP.so is the manually built one. You can find currently active libUMP.so with "ldd gles2_application" - command

The screen go off and don't restart until reset
This seems to be linked (to be verified) to fbturbo (former name sunxifb). DPMS has 3 options : standby, suspend and off. The sandby and suspend option works. But DPMS off put off the screen with the following error on console and in dmesg :

disp clks: lcd 146000000 pre_scale 1 hdmi 146000000 pll 219000000 2x 1

A workaround is to add in /usr/share/X11/xorg.conf.d/99-sunxifb.conf, in : Option "OffTime" "0"

However, it you still have problems, you can disable DPMS completely in the X server by properly editing xorg.conf (located either in /etc/X11 or /usr/share/X11/xorg.conf.d) add adding a Screen and Monitor section that disables DPMS. The following xorg.conf works with xf86-video-fbturbo (the new name of xf86-video-sunxifb):

Section "Screen" Identifier     "My Screen" Device         "fbturbo device" Monitor        "My Monitor" EndSection Section "Device" Identifier     "fbturbo device" Driver         "fbturbo" Option         "fbdev" "/dev/fb0" Option         "SwapbuffersWait" "true" EndSection Section "Monitor" Identifier     "My Monitor" Option         "DPMS" "false" EndSection

Another suggested option is to alter the other DPMS timers (OffTime is sometimes called BlankTime):

Section "ServerLayout" Identifier "ServerLayout0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" Option "BlankTime" "0" EndSection

You can also forcibly disable DPMS at runtime (in X): xset -dpms

...and/or make sure no screen-saver will kick in that would trigger blanking or some other undesired effect: xset s off

= Media Acceleration driver = Note: For H.264 and MPEG12 it is better to use open source vdpau driver than binary blob. See Cedrus.

In case VP8/6 XDIV/DIVX/MPEG4/MS-MPEG/VC1 binary blob should be used with patched vlc or xbmc

CedarX is supported for decoding some codecs (h.264), using linaro system (13.09) and linux-sunxi kernel (stage version for A20/sun7i).

Works at least with mplayer and VLC