Hello,
I've successfuly compiled the kernel for my Tablet with Amlogic 8726-MX SoC, I've also compiled the mali.ko and the ump.ko drivers, but while I'm booting the kernel the init process says that mali session ended.
Is it true that the libMali.so and the libUMP.so are the closed source binary blobs? I'm new to Mali and don't know if mali.ko and ump.ko drivers deliver the complete drivers? I'm know now that mali.ko and ump.ko are the modules for both libraries.
I want to run Android on my tablet, with my custom kernel, /*but from where do I get working Mali drivers?*/ Not necessary, because I'm going to use the libMali.so and libUMP.so provided with the Tablets Android system (only the modules get recompiled, hope it works).
Regards,
Johannes
Hi Johannes, The user-space parts of the Mali driver stack are proprietary and only available as closed source binaries. We generally do not supply binaries directly, except for a small number of reference drivers which Ben linked above.
The approved route for user-space driver binaries, as well as platform-specific kernel sources and configuration files, is getting them directly from the device or chipset manufacturer as they will be able to provide the fully integrated, configured, and tested drivers for that chipset. Fully integrated drivers may include vendor-specific customization such as GPU power management integration, which is outside of the Mali GPU itself.
While it may be possible to compile and configure kernel drivers from the open source components we provide, it will be missing any vendor-specific customization and configuration. Also if you attempt this, make sure that that the release version of the kernel driver matches the release version of the user-space binaries you have - the interface between the two is versioned and many reject any mismatched pairs due to API changes.
Cheers, Pete
Hello Peter Harris and others,
thanks for your answers so far, now I have one important question:
Is it possible to use the precompiled libmali.so and libump.so with self compiled mali.ko and ump.ko kernel modules?
My Android system contains the already working libmali.so and the libump.so + the working mali.ko and ump.ko, but if I have self compiled ump.ko and mali.ko the libmali.so and libump.so doesn;t work for some reason together.
Is my idea possible?
Regards.
Peter Harris said:While it may be possible to compile and configure kernel drivers from the open source components we provide, it will be missing any vendor-specific customization and configuration. Also if you attempt this, make sure that that the release version of the kernel driver matches the release version of the user-space binaries you have - the interface between the two is versioned and many reject any mismatched pairs due to API changes.
I don't want to recompile the libMali.so and libUMP.so as they are property.
If I recompile the mali.ko and ump.ko (which aren't kernel drivers?), I'm able to give my kernel a kernel version made by myself? Like 3.0.8-ge9ca3e2 from the original to my own: 3.0.8?
I've already changed the kernel version of the kernel image and the mali.ko and ump.ko with my Octeta hex-editor and the libMali.ko and libUMP.ko I haven't changed, and it worked, so my conclusion is:
The kernel version depend on mali.ko and ump.ko, but not on libMali.so and libUMP.so!
Thanks for help.
Johannes said:The kernel version depend on mali.ko and ump.ko, but not on libMali.so and libUMP.so!
Correct, but there is a dependency between libMali.so (user-space driver component) and mali.ko (kernel-space driver component); they generally must match (i.e. come from the same rXpY release from Arm). Mismatched user-space and kernel-space driver components are not tested and may not work at all, or may work unreliably.
HTH, Pete
Oh no!
This really means I can't update/upgrade my kernel from 3.0.8 to something like 4.x.x?
Have a nice day.
You can upgrade the kernel you are using just fine - this is why we provide the kernel drivers as source. All I mean is that the version of the kernel driver source which you are building (which comes from a particular rXpY release from Arm) must match the version of the binary libraries in user-space.
How do I find out what version my libMali.so and libUMP.so libraries have?
Im still having problems with the connection between the mali drivers and the mali Moduls, so I've uploaded here the ramdisk from Intenso which was stock shipped: https://www.dropbox.com/s/s5r85393k60jekx/rootfs.cpio?dl=0
Can anyone tell me what rXpY release my Moduls have? Is the release only readable from the library mali drivers?
Regards Form Germany!
I need to solve this issue, please thanks!
Hello
I've installed now CPU-Z and found under SoC the Revision r3p0
But how do I put the r3p0 number niw ino my mali.ko and my ump.ko self compiled modules???
Is there a location where the revision number must be put in?
This is my last question to get this topic solved.
Please help.
Regards Johannes from Germany
@Peter Harris I need your help. I'm heavily dissatisfied with the ARM Software. I can't patch my Kernel!
My self Compiler UMP.KO Kernel module dies work, but the self Compiler mali.KO doesn't work!
Sadly I habe the feeling Peter Harris is not Herr anmore... maybe in holiday or ... :'(
I don't think that there is someone else who know about Mali GPU's?
Plesse help me, this forum/community begins to look fake or just Stränge to me.