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
  • 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

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

Children
No data