This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Hi,

I'm sure this is a very easy question for most of you to asnwer. I sadly seem to be having quite a bt of difficulties to get the driver to compile.

I have compiled the ump.ko kernel module. For that to work i had to uncomment these lines:

ifeq ($(ARCH), arm)

# when compiling for ARM we're cross compiling

export CROSS_COMPILE ?= $(call check_cc2, arm-linux-gnueabi-gcc, arm-linux-gnueabi-, arm-none-linux-gnueabi-)

endif

The compile command i used:

KDIR=/usr/lib/modules/3.8.13.23-3-ARCH/build BUILD=release make

Which did it for the ump module.

However, the mali module isn't that easily persuaded to compile.

I'm compiling that module with this line:

KDIR=/usr/lib/modules/3.8.13.23-3-ARCH/build USING_UMP=1 BUILD=release make

and that gives me this compile output:

Makefile:76: /root/mali/DX910-SW-99002-r4p0-00rel1/driver/src/devicedrv/ump/Module.symvers

Makefile:110: CONFIG_TRACEPOINTS required for profiling

make ARCH=arm -C /usr/lib/modules/3.8.13.23-3-ARCH/build M=/root/mali/DX910-SW-99002-r4p0-00rel1/driver/src/devicedrv/mali modules

make[1]: Entering directory '/usr/src/linux-3.8.13.23-3-ARCH'

make[1]: arm-none-linux-gnueabi-gcc: Command not found

  Building modules, stage 2.

  MODPOST 0 modules

make[1]: Leaving directory '/usr/src/linux-3.8.13.23-3-ARCH'

rm: cannot remove ‘__malidrv_build_info.c’: No such file or directory

rm: cannot remove ‘__malidrv_build_info.o’: No such file or directory

Makefile:161: recipe for target 'all' failed

make: *** [all] Error 1

Disabling those lines like i did for the ump module only causes the line: "make[1]: arm-none-linux-gnueabi-gcc: Command not found" to not be in the output. The rest is the same.

It smells like i'm missing a step somewhere. But i'm merely following the documentation.

Some guidance in commands to use would be greatly appreciated.

** in case you wonder, yes i run this as root. I know it's bad practice but if i can't get my gpu to work then i certainly won't bother setting up a user environment **

Best regards,

Mark

Parents Reply Children
  • 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