Compiling Mali 400 r4p0-00rel1 driver on linux (archlinux arm). How?

Small update.

When i execute:

make -C /lib/modules/`uname -r`/build M=`pwd`

I do get a "mali.o" but not the final stel in actually creating the kernel module (.ko)...

Small update.

When i execute:

make -C /lib/modules/`uname -r`/build M=`pwd`

I do get a "mali.o" but not the final stel in actually creating the kernel module (.ko)...

Hi markg85.

A few questions:

1. What board are you working on? From kernel version we're guessing Odroid-U2/3?
2. Do you have an r4p0 userspace binary to pair with the kernel driver once it is built?

Also it's worth mentioning that the sources we release on the site are taken straight from the source that we release to partners, but it is intended to be ported/integrated for a specific SoC as part of its bringup. I wouldn't expect it to build and work perfectly as-is for any given platform/kernel.

Thanks,

Chris

Hi Chris,

I'm working on the Odroid-X board. But the other odroid versions (X2, U2/3 ..) all seem to have the same mali 400 gpu so i don't expect that to be an issue.

As for the userspace binary. This site (arm.com) provides the sources to build the binary userspace driver: Open Source Mali GPUs Linux EXA/DRI2 and X11 Display Drivers « Mali Developer Center so i guess i have that

One thing i wasn't counting on is the lack of gles binary blobs. But that also shouldn't be much of an issue to compile this driver. It just means that i have to wait a while till hardkernel releases the binary gles blobs for r4p0. I think they might have even done so already for the Odroid-U3.

Regards,

Mark

Hi Mark,

The GLES blobs is what I meant, but if they've released it then that's not a problem. Commits · hardkernel/linux · GitHub seems to have r4p0 support merged in last Tuesday, so assuming that kernel works for Odroid-X (I believe it should) then is there any reason you're not starting from there? If so you could probably use it as a reference. Also from the commit log it looks like they're using DRM not UMP, for what it's worth.

Hth,

Chris

Heh

I wasn't aware of that.

I also spoke with one of the odroid folks who also happens to know a lot about archlinuxarm. Turns out that there are packages (under names i wasn't expecting) to get everything working just fine.

Regards,

Mark

I was not aware of that could you let us know the packages as this will help people googling for this later

Thanks,

Chris

I actually wanted to do that in my last reply, but the arm board was kinda busy compiling. Which i didn't want to interrupt.

So here we go. If you run archlinuxarm on the odroid-x with the kernel: 3.8.13.23-3-ARCH then you can follow these instructions to get hardware accelerated opengl es.

Install the packages:

- xf86-video-armsoc-odroid

- xf86-video-modesetting

- odroid-libgl

That "should" be all you need.

In my case i had the issue that starting X still didn't work because it couldn't find screens.. So i asked how to get around that issue and was given this conf file for xorg (you should save it as "/etc/X11/xorg.conf.d/50-armsoc.conf"):

Section "Device"

        Identifier "Mali-Fbdev"                                                                                                                                                                      

        Driver  "armsoc"                                                                                                                                                                             

        Option  "fbdev" "/dev/fb0"                                                                                                                                                         

        Option  "Debug" "false"                                                                                                                                                                      

        Option  "DPMS"  "false"                                                                                                                                                                      

EndSection

Section "Screen"

        Identifier   "Default Screen"

        Device       "Mali-Fbdev"

        DefaultDepth 24

EndSection

Section "DRI"

        Mode 0666

EndSection

That should help some people googling for this issue

There is one issue i didn't find a suitable workaround for. Much applications want "libGL.so.1" to even open. They simply crash if you don't have this file (which you don't have if you follow the above).

So starting KDE: crash

Starting some login managers: crash

What is working is startx with twm (very ugly window manager). Starting KDM (KDE's login manager) and starting openbox from KDM all seem to work just fine.

Perhaps someone here can give me some hint on how to work around that issue? I know that the mali 400 doesn't have opengl support (only opengles) but there must be some trick to let the apps "think" that there is opengl just so they don't crash.

That has to be the easiest X config I've ever seen.

As for GL, if you did symlink libGL.so.1 to GLES, then you might be lucky, but I think more often than not it would barf. Generally the apps need to be GLES versions, for example XBMC has an option to build for GLES. Not sure how variables such as that would work with package managers, would you have xbmc and xbmc-gles?

Another issue is that even when apps use GLES, they tend to depend on the mesa GLES software implementation specifically, which is one of our most common pitfalls on the Chromebook as the mesa libs will completely override any other implementation on the board, removing the hardware acceleration. This doesn't seem to be the case for GL where the OS regards GL as an interface, which many different packages (e.g. MESA, nVidia, AMD, blah) can satisfy, but GLES doesn't seem to be treated the same way. EDIT: Apparently this is only on Ubuntu, Arch treats it as an interface.

Hth,

Chris

Hi Mark,

I've had a look at these packages and it appears that you've got everything you need to get Mali working in X11. Mali-400 driver doesn't support OpenGL API so if you want to run applications that depend on OpenGL, you will need to fall back to Mesa libraries. Please note that you will be limited to software rendering instead.

To get a fully functional 3D desktop, I'd recommend using a compositing/window manager that supports GLES such as certain branches of compiz, enlightenment, kwin or gnome-shell. For example: you can install package "kdebase-workspace" which contains kwin_gles that you can use instead of the default kwin WM. Alternatively you can use xfwm4, openbox for a functional 2D desktop.

I hope this helps.

Thanks,

Tu