zador.blood.stained Posted October 10, 2017 Posted October 10, 2017 49 minutes ago, jock said: I had to remove the .disable suffix and patch the patch (no pun) Zador pointed above because the DTS section to be edited is in file sunxi-h3-h5.dtsi and not in sun8i-h3.dtsi. It should go to sun8i-h3.dtsi H5 has mali450 and it should have different bindings.
jock Posted October 11, 2017 Posted October 11, 2017 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.
zador.blood.stained Posted October 11, 2017 Posted October 11, 2017 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.
René Kliment Posted October 22, 2017 Posted October 22, 2017 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.
Igor Posted October 22, 2017 Posted October 22, 2017 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/
rubbeldiekatz2 Posted November 4, 2017 Posted November 4, 2017 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.
Igor Posted November 4, 2017 Posted November 4, 2017 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 and sometimes pcs of hardware. Donations are like love. Unconditional. 4
hojnikb Posted November 5, 2017 Posted November 5, 2017 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. 1
rubbeldiekatz2 Posted November 6, 2017 Posted November 6, 2017 This sounds wondeerful. I think you mean this project, right? http://linux-sunxi.org/Cedrus They say, that the driver already decodes MPEG2, H264 and H265, which would be neough to decode most of the multimedia content. What is the status or plans of implementing the driver in the A20 SOC mainline images?
Tido Posted November 6, 2017 Posted November 6, 2017 This page was last modified on 23 November 2016, at 02:00. lesen bildet
Menion Posted November 9, 2017 Posted November 9, 2017 http://linux-sunxi.org/Linux_mainlining_effort got updated. There is a link to a lima kernel driver plus MESA OpenGL Lima for Mali400 So apparently the things are moving underground
boobypi Posted November 16, 2017 Posted November 16, 2017 (edited) 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 November 16, 2017 by Tido added Spoiler
makama80 Posted November 16, 2017 Author Posted November 16, 2017 Ehh... maybe you can reduce the amount of bull-poo if you tell where to find it?
boobypi Posted November 16, 2017 Posted November 16, 2017 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)
jernej Posted November 16, 2017 Posted November 16, 2017 @boobypi those video-codec and mpegts nodes don't have anything in common with mali.
jock Posted November 29, 2017 Posted November 29, 2017 (edited) 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 November 30, 2017 by jock SOLVED
hostkit Posted January 13, 2018 Posted January 13, 2018 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
jock Posted January 25, 2018 Posted January 25, 2018 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 2
djx-treme Posted February 20, 2018 Posted February 20, 2018 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
René Kliment Posted February 20, 2018 Posted February 20, 2018 This is my very dirty script that seems to work for me: https://gist.github.com/renekliment/707ea4a2dc3f11fc15ed8085f506c57e 4
Anshul Panjabi Posted March 4, 2018 Posted March 4, 2018 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.
djx-treme Posted March 8, 2018 Posted March 8, 2018 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?
Recommended Posts