Jump to content

Mali support announced for mainline (Allwinner SOC's)


makama80

Recommended Posts

19 hours ago, zador.blood.stained said:

It should go to sun8i-h3.dtsi

H5 has mali450 and it should have different bindings.

 

I know, but the patch failed to find the hunks in sun8i-h3.dtsi.

After spending some time digging into dts files, I found that the patch could fit in sunxi-h3-h5.dtsi, so manually changed the patch, run the compilation script and the patch was correctly applied.

All of this is with kernel 4.13. Maybe 4.14 has been changed or will be changed: that could be the reason why the patch is currently disabled in the armbian source code. As far as mine is just an experiment, it's enough for me.

 

BTW the mali kernel driver loads fine, that's the userland part which is missing something I guess.

 

 

Link to comment
Share on other sites

1 minute ago, jock said:

Maybe 4.14 has been changed or will be changed: that could be the reason why the patch is currently disabled in the armbian source code.

Once you start adding that many DT patches that we have you'll get conflicts. I have a fixed version for sun8i-h3.dtsi but I don't know how useful it is given that X11 mali doesn't work properly and I'm not sure how useful the Wayland/gbm version is.

 

6 minutes ago, jock said:

BTW the mali kernel driver loads fine, that's the userland part which is missing something I guess.

Userspace part needs to be installed properly, i.e. Ubuntu implements it in a really good way using update-alternatives and ld.so symlinks. Also xf86-armsoc driver is required for X11.

Link to comment
Share on other sites

On 11. 10. 2017 at 8:10 PM, zador.blood.stained said:

Once you start adding that many DT patches that we have you'll get conflicts. I have a fixed version for sun8i-h3.dtsi but I don't know how useful it is given that X11 mali doesn't work properly and I'm not sure how useful the Wayland/gbm version is.

 

Userspace part needs to be installed properly, i.e. Ubuntu implements it in a really good way using update-alternatives and ld.so symlinks. Also xf86-armsoc driver is required for X11.


So if I understand this correctly ... even though I have the mali.ko, there is no easy way of using it in X currently? How does this differ from using the legacy kernel / stack? I thought the difference was only in the kernel and user-space stuff should be more or less the same. Could you please elaborate? Also, it seems that I only get mali.ko, not mali_drm.ko ... what's the relation and is that what's preventing the use of something useful?

I am very inexperienced with the graphics stack, so if those are super silly questions, I am sorry to bother.

Link to comment
Share on other sites

14 minutes ago, René Kliment said:

So if I understand this correctly ... even though I have the mali.ko, there is no easy way of using it in X currently? How does this differ from using the legacy kernel / stack? I thought the difference was only in the kernel and user-space stuff should be more or less the same. Could you please elaborate? Also, it seems that I only get mali.ko, not mali_drm.ko ... what's the relation and is that what's preventing the use of something useful?

I am very inexperienced with the graphics stack, so if those are super silly questions, I am sorry to bother.


This might help you understand: http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/

Link to comment
Share on other sites

Will this be integrated into the mainline Images for the Allwinner SOC based devices?

http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/comment-page-1/#comment-1856480

 

It would be awesome and i am sure, alot of people would love it too, as it finally made it possible to run kodi/xbmc etc.. with acceptable speed.

If it comes true, i will be the first to donate.

 

Hope it hasnt been posted anywhere else. Didnt read all the topics.

Link to comment
Share on other sites

1 hour ago, rubbeldiekatz2 said:

Didnt read all the topics.


We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.

https://www.armbian.com/search_gcse/

 

1 hour ago, rubbeldiekatz2 said:

If it comes true, i will be the first to donate.


To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry B) and sometimes pcs of hardware.

Donations are like love. Unconditional.

Link to comment
Share on other sites

On 11/4/2017 at 2:03 PM, rubbeldiekatz2 said:

Will this be integrated into the mainline Images for the Allwinner SOC based devices?

http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/comment-page-1/#comment-1856480

 

It would be awesome and i am sure, alot of people would love it too, as it finally made it possible to run kodi/xbmc etc.. with acceptable speed.

If it comes true, i will be the first to donate.

 

Hope it hasnt been posted anywhere else. Didnt read all the topics.

 

Sadly, a working MALI won't help with kodi/xbmc performance, as it's purely a OpenGL ES device and nothing else. For media playback, you need a working CedarX driver, which is a completely separate thing. Luckily it's being worked on in the form of Cedrus project.

Link to comment
Share on other sites

Maybe i tell bullshit but i saw a kernel4.4 driver for mali400 released with NanoPi Fire2A & Fire3 Boards.
 

Spoiler

 


gpu@c0070000 {
			compatible = "arm,mali-400", "arm,mali-utgard";
			reg = <PHYS_BASE_VR 0x10000>;
			interrupts = <IRQ_VR>, <IRQ_VR>, <IRQ_VR>,
				   <IRQ_VR>, <IRQ_VR>, <IRQ_VR>, <IRQ_VR>;
			interrupt-names = "IRQGP", "IRQGPMMU", "IRQPP0",
				"IRQPPMMU0", "IRQPP1", "IRQPPMMU1", "IRQPMU";
			pmu_domain_config = <0x1 0x4 0x8 0x0 0x0 0x0 0x0 0x0
						0x0 0x2 0x0 0x0>;
			pmu_switch_delay = <0xff>;
			clocks = <&vr>;
			clock-names = "clk_mali";
			resets = <&nexell_reset RESET_ID_VR>;
			reset-names = "vr-reset";
		};

		video-codec@c0080000 {
			compatible = "nexell, nx-vpu";
			reg = <0xc0080000 0x4000>;
			interrupts = <IRQ_CODA960_HOST>,
				<IRQ_CODA960_JPG>;
			resets = <&nexell_reset RESET_ID_CODA_A>,
				<&nexell_reset RESET_ID_CODA_P>,
				<&nexell_reset RESET_ID_CODA_C>;
			reset-names = "vpu-a-reset", "vpu-p-reset",
				"vpu-c-reset";
			clocks = <&pclk>, <&bclk>;
			status = "okay";
			sram = <0 0>;
		};

		mpegts_0: mpegts0@c005d000 {
			compatible = "nexell,nx-mpegts";
			reg = <0xc005d000 0x4000>;
			reset-names = "mpegts0-rst";
			resets = <&nexell_reset RESET_ID_MPEGTSI>;
			clock-names = "mpegts0-clk";
			clocks = <&mpegtsi>;
			channel_num = <0>;
			status = "disabled";
		};

		mpegts_1: mpegts1@c005d000 {
			compatible = "nexell,nx-mpegts";
			reg = <0xc005d000 0x4000>;
			reset-names = "mpegts1-rst";
			resets = <&nexell_reset RESET_ID_MPEGTSI>;
			clock-names = "mpegts1-clk";
			clocks = <&mpegtsi>;
			channel_num = <1>;
			status = "disabled";
		};

 

Edited by Tido
added Spoiler
Link to comment
Share on other sites

48 minutes ago, makama80 said:

Ehh... maybe you can reduce the amount of bull-poo if you tell where to find it?

Here http://112.124.9.243/uftp/linux-4.4.y-g3739ddc.tar.xz
 

 

After read some comments at http://free-electrons.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/, mali400 have different implementation (nexell mali 400 != allwinner mali 400)

Link to comment
Share on other sites

I compiled the Mali kernel driver for latest Armbian 5.34 (kernel 4.13.14) nightly for OrangePi PC; compilation goes fine.

When I install the mali.ko module I get:

mali: loading out-of-tree module taints kernel.
[    8.696542]  mali-utgard: assigned reserved memory node linux,cma
[    8.697136] Allwinner sunXi mali glue initialized
[    8.697333] mali-utgard mali-utgard.0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[    8.697357] mali-utgard: probe of mali-utgard.0 failed with error -14
[    8.697419] Mali: 
[    8.697422] Mali device driver loaded

and /dev/mali filesystem object is not exposed

 

This is unexpected: using the old armbian release (usinge the "next" kernel) I was able compile the mali kernel driver, patching the device tree assemblies to add HDMI support and compiling the kernel manually, and everything worked.

 

I wrote some EGL code to initialize the libMali.so binary userspace blob and it was working, but now obviously it isn't :/

 

edit: ok I got the issue sorted, practically the guy who maintains the github repository with sunxi-mali binary driver is updating the patches. I guess he is keeping them up to date with mainline kernel (4.15 at the moment), but actually breaking compatibility with armbian next (which is 4.13.16). I managed to compile, install and test successfully the driver using an old copy.

Edited by jock
SOLVED
Link to comment
Share on other sites

On 13/1/2018 at 10:48 AM, hostkit said:

Hai @jock Do you successfully install mali on mainline kernel? What Hw acceleration is working?

 

Step by step to install please. I dont know how to add device tree steps

 

Hi hoskit, yes I was able to get the job done. I suggest you to take the very latest development armbian nightly which already has the HDMI bits in the device tree, just not to tinker about the kernel compilation and other messy things.

The guy (mripard) on github fixed some regression he introduced that broke the mali kernel driver compilation on slightly older kernel, so now compilation and installation should be pretty accessible.

I tried only the framebuffer version, and yes, it was working pretty well: I tried different OpenGLES2 demos from the official Mali SDK and they all worked without issues

Link to comment
Share on other sites

Hi guys,

I was so excited Mali can work with mainline kernel, so I immediately gave it a try on my Banana Pi.

 

As I'm not quite familiar with the low-level part, I spent some time reading instructions and catching up with the background.

 

Then I took this guide,

https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/

 

I downloaded and tried to compile https://github.com/mripard/sunxi-mali.git

failed with the absence of mm/cma.h

Found this file here (https://github.com/google/kmsan/raw/master/mm/cma.h)

 

afterwards everything compiled with the kernel 4.14.18.

after insmod mali.ko it failed

in dmesg I see: failed to find mali node.

 

And I realized that the patch for device tree didn't find its way to the mainline kernel. Still.

 

Now what? 

Patch the kernel files and rebuild the kernel, right?

 

First, read instructions and follow them!

https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

I've set up all environment and made sure everything works without issues.

Then I patched the file ./arch/arm/boot/dts/sun7i-a20.dtsi according to this instruction

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt

 

Added the following lines:

--- ./arch/arm/boot/dts/sun7i-a20.dtsi.orig     2018-02-20 12:24:14.045089402 -0800
+++ ./arch/arm/boot/dts/sun7i-a20.dtsi  2018-02-20 12:23:33.000000000 -0800
@@ -1617,6 +1617,28 @@
                        #size-cells = <0>;
                };

+               mali: gpu@1c40000 {
+                       compatible = "allwinner,sun7i-a20-mali", "arm,mali-400";
+                       reg = <0x01c40000 0x10000>;
+                       interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+                                    <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+                       interrupt-names = "gp",
+                                         "gpmmu",
+                                         "pp0",
+                                         "ppmmu0",
+                                         "pp1",
+                                         "ppmmu1",
+                                         "pmu";
+                       clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
+                       clock-names = "bus", "core";
+                       resets = <&ccu RST_BUS_GPU>;
+               };
+
                gmac: ethernet@01c50000 {

And tried to compile 

2616805-Error: arch/arm/boot/dts/sun7i-a20.dtsi:1637.19-20 syntax error
2616869:FATAL ERROR: Unable to parse input tree
2616909-scripts/Makefile.lib:320: recipe for target 'arch/arm/boot/dts/sun7i-a20-bananapi.dtb' failed
2617003-make[1]: *** [arch/arm/boot/dts/sun7i-a20-bananapi.dtb] Error 1
2617067-arch/arm/Makefile:354: recipe for target 'dtbs' failed

It complains about the following line:

clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;

Tried this patch

https://patchwork.kernel.org/patch/10046141/

 

Same thing

 

I double-checked the similar patch you've already done 

https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/32-h3-DT-add-mali-node.patch

 

What am I doing wrong?

Sorry for dumb questions, I give up :)

Link to comment
Share on other sites

On 3/4/2018 at 2:51 AM, Anshul Panjabi said:

Hello, I got it compiled and installed successfully, but es2gears, es2_info and es2gears_x11 all fail to initialize EGL display and give eglGetDisplay() failed error. 

Please can you advise how you patched the kernel to add Mali node?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines