search

mripard / sunxi-mali

GNU General Public License v2.0
100 stars 54 forks source link

Kernel 4.16 + Allwinner A20 + RGB888 LCD Screen + Mali GPU acceleration on X11 #38

Closed toluse closed 6 years ago

toluse commented 6 years ago

Apologies for opening an Issue, it's likely that i have a configuration problem, but i am banging my head on the desk since a week with very little sleep and it's time to get some help.

I went into full adventure mode and am trying to compile a Yocto / Openembedded Rocko release with u-boot 2018.03 , linux kernel 4.16 for the Cubieboard2 with an Cubiescreen LCD display. I know stone-age hardware but my chances to get it working with something not Allwinner sunxi kernel 3.4 related are much better these days than a few years ago.

What works: Cubiescreen LCD works with with u-boot 2018.03 and a little dirty patch, to send a few 9-bit-wire init commands over SPI. Kernel loads fine and i have the text on the screen. CMA is configured and that fb overalloc define set to 300 as well. Switching to sun4i-drm display engine also seems to work after more guesswork and adding the timings to simple-panel.c, but i am not sure i got the DT entries correct. It was guesswork as you find mostly information for elder kernels on the internet (naturally with 4.16):

[ 3.597851] sun4i-drm display-engine: bound 1e60000.display-backend (ops sun4i_backend_ops [sun4i_backend]) [ 3.608329] sun4i-drm display-engine: bound 1e40000.display-backend (ops sun4i_backend_ops [sun4i_backend]) [ 3.618913] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops sun4i_rgb_init [sun4i_tcon]) [ 3.628808] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 3.636767] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops sun4i_rgb_init [sun4i_tcon]) [ 3.647706] sun4i-drm display-engine: bound 1c16000.hdmi (ops sun4i_tmds_create [sun4i_drm_hdmi]) [ 3.656712] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.663368] [drm] No driver support for vblank timestamp query. [ 3.669300] fb: switching to sun4i-drm-fb from simple

Mali driver also probes:

[ 4.181989] mali: loading out-of-tree module taints kernel. [ 4.194033] Allwinner sunXi mali glue initialized [ 4.199485] Mali: [ 4.199497] Found Mali GPU Mali-400 MP r1p1 [ 4.211004] Console: switching to colour frame buffer device 100x30 [ 4.217845] sun4i-drm display-engine: fb0: frame buffer device [ 4.225247] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [ 4.234786] Mali: [ 4.234799] 2+0 PP cores initialized [ 4.241795] Mali: [ 4.241805] Mali device driver loaded

Not sure why it says out-of-tree. I tried to write a bitbake recipe that still misses some RDEPENDS / DEPENDS... Only runs through when everything else was build beforehand. Alas the mali.ko is there and loads.

Mind you when X11 starts with armsoc driver, i get this:

[ 81.407] (II) ARMSOC(0): Setting the video modes ... [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1654: Entering [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1671 Got KMS resources [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1674 2 connectors, 2 encoders [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1677 2 crtcs, 0 fbs [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1680 0x0 minimum resolution [ 81.407] (II) ARMSOC(0): drmmode_pre_init:1683 8192x8192 maximum resolution [ 81.407] (II) ARMSOC(0): Adding all CRTCs

0 fbs ??? Is this a problem with the DT ? Shouldn't it be 1 or 2?

And later:

[ 82.930] (II) ARMSOC(0): ARMSOCPreInit:941: Exiting [ 82.930] (--) Depth 24 pixmap format is 32 bpp [ 82.930] (II) ARMSOC(0): ARMSOCScreenInit:992: Entering [ 82.930] (II) ARMSOC(0): ARMSOCScreenInit:1005 allocating new scanout buffer: 800x480 32 32 [ 82.930] (EE) _CREATE_GEM({height: 480, width: 800, bpp: 32 buf_type: 0x0}) failed. errno: 22 - Invalid argument [ 82.931] (EE) ARMSOC(0): ERROR: Cannot allocate scanout buffer

[ 82.931] (II) ARMSOC(0): ARMSOCScreenInit:1225: Exiting

I have not built umplock. And i saw that there is a error in the Mali driver code debug printout that reports that it is on when its off and off when its on. So the trace shows enabled, but i guess it is off. At least in build.sh it says USING_UMP=0.

Do i still need the mali egl x11 drm module? The build.sh script does not compile it. The xf86-video-armsoc has the reference to sun4i-drm, but i have not seen anything mali drm related in it. Found some nice slidedeck i think Maxime used on some linux "how to drm" talk, but it doesn't mention module or driver names.

So to sum it up:

Thank you, Tobias

P.S.: Here is the 20-armsoc.conf and the complete logs: 20-armsoc_conf.txt bootlog.txt x11log.txt Will add the guesstimated DT patch (it's not an overlay yet - sorry) later.

giuliobenetti commented 6 years ago

Hi @toluse,

have you tried with applying patch for GEM? Try to cherrypick this commit(NextThingCo/linux@e390023) and recompile kernel. At the moment it's not part of mainline kernel.

toluse commented 6 years ago

Thanks @giuliobenetti !

I didn't have that patch cherrypicked.

drm_gem_cma_create_with_handle that the custom ioctl uses is static in 4.16. Hmm make it public or use drm_gem_cma_dumb_create instead?

giuliobenetti commented 6 years ago

@toluse you're welcome. But does it work now?

About patch I let answer the author, because honestly I don't know.

toluse commented 6 years ago

@giuliobenetti I hack the function access for the moment and let you know asap what happens. (Have to do my regular -paid- work first, before going back to this ;) )

toluse commented 6 years ago

Hi @giuliobenetti !

Looks like i am one step further. With the gem patch added to Kernel 4.16, my X11 server starts up with armsoc_drv.so. See attached log.

Unfortunately i hit the next problem immediately... As soon as i try to use any app that would make use of the GPU, i get a Segmentation Fault. E.g. callling es2_info.

Since this is a a Yocto core-image-x11 minimal build, i have to add some devtools first for further debugging. E.g. gdb and strace. I hope it's not a binary incompatibility between the shared libraries in yocto and the mali-blob. The SW is built with Enable hardfloat, thumb2 and neon capabilities. ( DEFAULTTUNE = "cortexa7hf-neon-vfpv4" )

If anybody else has a clue about my other 2 questions, please chime in:

Regarding the last: Looks like i cannot build it on 4.16. Lot's of things changed in DRM area.

-Tobias

x11log-gem-patch.txt

giuliobenetti commented 6 years ago

About Compiler compatibility there should not be problems.

From your x11 log i can't understand what's going on, also i don't even see segmentation fault.

It would be great if you pastebin strace log. Also you could recompile Mali kernel driver in debug mode and set mali_debug_level=5 to make it verbose and post also dmesg. That can give more info. Also posting x11 log would be interesting.

toluse commented 6 years ago

I think X11 and armsoc_drv is happy for the moment. That x11log was just for comparision to see that i can now get past the gem allocations stage now. Having the requested IOCTL in the kernel really helps.. :D

I tried an gdb run when calling es2_info and got that:

Thread 1 "es2_info" received signal SIGSEGV, Segmentation fault. 0xb6908c0e in _mali_base_common_mem_alloc () from /usr/lib/libMali.so (gdb) bt

0 0xb6908c0e in _mali_base_common_mem_alloc () from /usr/lib/libMali.so

1 0xb68f13da in _mali_frame_builder_alloc () from /usr/lib/libMali.so

2 0xb68feae8 in __egl_mali_create_frame_builder () from /usr/lib/libMali.so

3 0xb690435a in __egl_platform_create_surface_x11 () from /usr/lib/libMali.so

4 0xb6f25642 in __egl_create_surface () from /usr/lib/libGLESv2.so

5 0xb6f25878 in _egl_create_window_surface () from /usr/lib/libGLESv2.so

6 0xb6f225aa in eglCreateWindowSurface () from /usr/lib/libGLESv2.so

7 0x00010ec4 in make_x_window (name=0x115a0 "ES info", x=0, y=0, width=400, height=300, surfRet=, ctxRet=, winRet=,

es_ver=<optimized out>, egl_dpy=0x1, x_dpy=0x23150) at /usr/src/debug/mesa-demos/8.3.0-r0/mesa-demos-8.3.0/src/egl/opengles2/es2_info.c:205

8 main (argc=, argv=) at /usr/src/debug/mesa-demos/8.3.0-r0/mesa-demos-8.3.0/src/egl/opengles2/es2_info.c:273

Not sure if this is already trying to do a malloc via Mali IOCTL on GPU side...

I'll try the debug mode idea... If i am lucky, it's something dumb, like wrong DT entry not powering up the GPU.

Thanks for your time @giuliobenetti !

The shameful thing is, i have worked on Mali400 Android integration a few years ago for my employer. So really should have no problem getting it working. Mind you that was r3p2 at that time and having access to the full Mali conformance test suite helps for getting the basic things right.

-Tobias

giuliobenetti commented 6 years ago

You're welcome.

For correct DT bindings take a look at sun7i-a20.dtsi on mainline kernel. I've submitted it couple of months ago. That should work correctly.

Please let us know when it works what you've changed, thanks!

toluse commented 6 years ago

@giuliobenetti Turns out i was already using your DT binding from linux mainline. I attach the mali_debug_level=5 modprobe traces of the mali driver

bootlog.txt

Is this:

[ 3.956786] Continuing without Mali regulator control and [ 4.350451] Mali GPU Utilization: No platform utilization handler installed [ 4.590996] Mali<2>: [ 4.591005] Mali DVFS init: platform function callback incomplete, need check mali_gpu_device_data in platform .

expected?

Mind you the interrupt tests pass, so it seems to be powered and alive at least.

When i later start my segfaulting es2_info, i see this: errorlog.txt

0 pages on pool? [ 132.984417] OS Mem: Stopping pool trim timer, only 0 pages on pool Not good i guess.

So maybe still some kernel config or patch regarding memory, CMA, DMA, DMABUF missing or wrong?

[ 0.000000] cma: Reserved 256 MiB at 0x60000000 [ 0.000000] Memory: 763960K/1047076K available (7168K kernel code, 695K rwdata, 1568K rodata, 1024K init, 276K bss, 20972K reserved, 262144K cma-reserved, 260644K highmem)

Kernel config: config.txt

Alas it looks like libMali.so talks to the kernel driver... The Mali GPU bootup is also promising... I should be close.

How does that FBDEV_OVERALLOC relate the CMA memory btw.? Is the first in MB or % ? Does it relate to CMA memory of 256MB somehow.

(And now back to the important weekend-tasks - bathroom cleaning. Calvin & Hobbes - There is never enough time to do all the nothing you want!!)

-Tobias

giuliobenetti commented 6 years ago

Hi,

Can you also attach your board dts? From a certain point on of Mali kernel driver, you don't need anymore to setup a cma area since driver will do it for you.

About FBDEV_OVERALLOC that is needed only for fbdev version as I know, not for X11(maybe I'm wrong).

And how much ram do you have in your board?

It seems like it can't get enough ram to create the surface.

toluse commented 6 years ago

Yes will do... But i haven't done any big changes.

I managed to compile the UMP driver after a bit of hacking. Yes i know is outdated, but i wanted to see, if i have the same problem there as well. Here is the log: umplog.txt

_ump_ukk_size_get() calls ump_random_mapping_get and i guess it fails in mem = search(&map->root, id);

Very odd...

This is a bog standard Cubieboard2 which has 1GB RAM afaik...

cat /proc/meminfo

MemTotal:        1027128 kB
MemFree:          905976 kB
MemAvailable:     966220 kB
Buffers:            9568 kB
Cached:            64552 kB
SwapCached:            0 kB
Active:            57564 kB
Inactive:          30428 kB
Active(anon):      14096 kB
Inactive(anon):       84 kB
Active(file):      43468 kB
Inactive(file):    30344 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        260644 kB
HighFree:         177516 kB
LowTotal:         766484 kB
LowFree:          728460 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         13856 kB
Mapped:            27276 kB
Shmem:               316 kB
Slab:              18012 kB
SReclaimable:       8188 kB
SUnreclaim:         9824 kB
KernelStack:         656 kB
PageTables:          676 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      513564 kB
Committed_AS:      95064 kB
VmallocTotal:     245760 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
CmaTotal:         262144 kB
CmaFree:          255216 kB
toluse commented 6 years ago

@giuliobenetti

Ok here is my sun7i-a20.dtsi and sun7i-a20-cubieboard2.dts.

sun7i-a20.dtsi.txt sun7i-a20-cubieboard2.dts.txt

The changes should be:

The last one could still be woefully wrong, but the armsoc_drv.so starts up fine after the GEM patch. Not sure if those lcd pin definition is still necessary... At some point in the past is was.

I'll do a complete rebuild from scratch of my yocto image to rule out any side-effects from interim incremental testing of individual recipes.

(My X11 configuration is also still a bit odd... Looks like "glamor" is enabled by default somehow and that requires libgbm, which is provided by mesa. The mali driver blob do not provide it. So i disabled it for the moment. Mind you that should not affect the kernel driver allocating memory and es2_info to run.)

-Tobias

giuliobenetti commented 6 years ago

dts files seem to be ok for working. GPU doesn't need any other DT binding. For the rest I don't know how to help you. Here we need someone else more expert than me to get it working. Sorry!

toluse commented 6 years ago

Again thanks for your time @giuliobenetti !

It will sort itself out sooner or later. Maybe my DVFS config is still lacking some DT entries. This was not enabled by default, but the Mali kernel driver is configured to use it. I could still try with DVFS and DEVFREQ disabled.

-Tobias

giuliobenetti commented 6 years ago

Ah wait, dvfs is not a problem at all, same goes for devfreq. I've always used without it enabled. So ignore the build time warnings. Instead if you have dvfs enabled in kernel is different. Try without it enabled.

toluse commented 6 years ago

Ok i will try it. I think i got a compile error with the driver without, that's why i enabled it in the kernel, but i do not see a frequency table in the device-tree for the CPU for example. So that might not do any good.... e.g. things timing out if we run slower than expected.

giuliobenetti commented 6 years ago

Are you sure it is a compiler error? Can you retry disabling DVFS and recompile Mali and post build log? So you mix less things together. After you get it working without DVFS, then you can try have it working with it enabled.

mripard commented 6 years ago

You don't need UMP at all. Revert the changes you made to go back to your segfault state, and try moving the libMali (and all the symlinks) to /usr/lib/arm-linux-gnueabihf/

toluse commented 6 years ago

Hi everybody...

After fiddling until 1am and seriously impacting my days work today i made some progress. With DVFS disabled in kernel configuration i could get es2_info to start and it segfaults a bit later with a new error. (This is back to using dmabuf of course. The ump experiment was just a test.)

The delta configuration is: Old non working state: CONFIG_PM_DEVFREQ=y CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=m CONFIG_DEVFREQ_GOV_PERFORMANCE=m CONFIG_DEVFREQ_GOV_POWERSAVE=m CONFIG_DEVFREQ_GOV_USERSPACE=m CONFIG_DEVFREQ_GOV_PASSIVE=m

New a bit better state: None of the aboves defined, but CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y instead... Which seemed like a good idea..

So @giuliobenetti you were right the driver just throws a warning. My compilation errors were probably caused by my bitbake recipes. (Still try to find the right syntax to compile the mali-sunxi driver in bitbake with minimum / none changes to the original code. A do_unpack_prepend which calls the build.sh -a seems to do most of the trick, but i have to get the dependency that e.g. quilt and the in-tree kernel modules are built beforehand right.)

Current error thrown by es2_info:

---

root@cubieboard2:/data/mesa-demos/usr/bin# ./es2_info
EGL_VERSION: 1.4 Linux-r6p2-01rel0
EGL_VENDOR: ARM
EGL_EXTENSIONS:
    EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap,
    EGL_EXT_image_dma_buf_import, EGL_KHR_gl_texture_2D_image,
    EGL_KHR_gl_texture_cubemap_image, EGL_KHR_gl_renderbuffer_image,
    EGL_KHR_reusable_sync, EGL_KHR_fence_sync,
    EGL_KHR_swap_buffers_with_damage, EGL_EXT_swap_buffers_with_damage,
    EGL_KHR_lock_surface, EGL_KHR_lock_surface2,
    EGL_EXT_create_context_robustness, EGL_ANDROID_blob_cache,
    EGL_KHR_create_context, EGL_KHR_partial_update,
    EGL_KHR_create_context_no_error
EGL_CLIENT_APIS: OpenGL_ES
GL_VERSION: OpenGL ES 2.0
GL_RENDERER: Mali-400 MP
GL_EXTENSIONS:
    GL_OES_texture_npot, GL_OES_vertex_array_object,
    GL_OES_compressed_ETC1_RGB8_texture,
    GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_OES_standard_derivatives,
    GL_OES_EGL_image, GL_OES_depth24, GL_ARM_rgba8,
    GL_ARM_mali_shader_binary, GL_OES_depth_texture,
    GL_OES_packed_depth_stencil, GL_EXT_texture_format_BGRA8888,
    GL_OES_vertex_half_float, GL_EXT_blend_minmax, GL_OES_EGL_image_external,
    GL_OES_EGL_sync, GL_OES_rgb8_rgba8, GL_EXT_multisampled_render_to_texture,
    GL_EXT_discard_framebuffer, GL_OES_get_program_binary,
    GL_ARM_mali_program_binary, GL_EXT_shader_texture_lod, GL_EXT_robustness,
    GL_OES_depth_texture_cube_map, GL_KHR_debug,
    GL_ARM_shader_framebuffer_fetch,
    GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_OES_mapbuffer,
    GL_KHR_no_error
[xcb] Unknown request in queue while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
Segmentation fault
root@cubieboard2:/data/mesa-demos/usr/bin

gdb backtrace:

Thread 1 "es2_info" received signal SIGSEGV, Segmentation fault.
_int_malloc (av=av@entry=0xb6d8e7ec <main_arena>, bytes=1, bytes@entry=300)
    at /usr/src/debug/glibc/2.26-r0/git/malloc/malloc.c:3786
3786              bck->fd = unsorted_chunks (av);
(gdb) bt
#0  _int_malloc (av=av@entry=0xb6d8e7ec <main_arena>, bytes=1, bytes@entry=300)
    at /usr/src/debug/glibc/2.26-r0/git/malloc/malloc.c:3786
#1  0xb6cc5e48 in __GI___libc_malloc (bytes=300) at /usr/src/debug/glibc/2.26-r0/git/malloc/malloc.c:3066
#2  0xb6cc0084 in __GI__IO_str_overflow (fp=0xbefff828, c=114)
    at /usr/src/debug/glibc/2.26-r0/git/libio/strops.c:107
#3  0xb6cbeb84 in __GI__IO_default_xsputn (f=0xbefff828, data=<optimized out>, n=29)
    at /usr/src/debug/glibc/2.26-r0/git/libio/genops.c:455
#4  0xb6c97298 in _IO_vfprintf_internal (s=s@entry=0xbefff828,
    format=format@entry=0xb6d70650 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", ap=..., ap@entry=...)
    at /usr/src/debug/glibc/2.26-r0/git/stdio-common/vfprintf.c:1643
#5  0xb6cb9278 in _IO_vasprintf (result_ptr=0xbefff920, result_ptr@entry=0xbefff918,
    format=format@entry=0xb6d70650 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", args=..., args@entry=...)
    at /usr/src/debug/glibc/2.26-r0/git/libio/vasprintf.c:59
#6  0xb6c9ca64 in ___asprintf (string_ptr=string_ptr@entry=0xbefff918,
    format=0xb6d70650 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n")
    at /usr/src/debug/glibc/2.26-r0/git/stdio-common/asprintf.c:35
#7  0xb6c7a844 in __assert_fail_base (fmt=0xb6d70650 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=0xb6e3093c "!xcb_xlib_unknown_req_pending", assertion@entry=0xb6d8e000 "\030o\023",
    file=0xb6e30750 "../../libX11-1.6.5/src/xcb_io.c", file@entry=0xb6e306f8 "append_pending_request",
    line=151, line@entry=3067545168, function=function@entry=0xb6e306f8 "append_pending_request")
    at /usr/src/debug/glibc/2.26-r0/git/assert/assert.c:57
#8  0xb6c7a9b8 in __GI___assert_fail (assertion=0xb6d8e000 "\030o\023",
    file=0xb6e306f8 "append_pending_request", line=3067545168,
    function=0xb6e306f8 "append_pending_request") at /usr/src/debug/glibc/2.26-r0/git/assert/assert.c:101
#9  0xb6dc6fc4 in ?? () from /usr/lib/libX11.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

---

Stack corruption?

I just found this old forum posting for Odroid related to that xcb warning/error. https://forum.odroid.com/viewtopic.php?f=52&t=2680 https://forum.odroid.com/viewtopic.php?f=9&t=245&p=1793#p1739 Nasty... Assembler binary blob patching.. Yiiiiks!

On the pro side i can start es2gears_x11 and it gives a phantastic (mediocre) 25fps:

---
root@cubieboard2:/data/mesa-demos/usr/bin# ./es2gears_x11
EGL_VERSION = 1.4 Linux-r6p2-01rel0
vertex shader info:
fragment shader info:
info:
130 frames in 5.0 seconds = 25.886 FPS
129 frames in 5.0 seconds = 25.682 FPS
130 frames in 5.0 seconds = 25.881 FPS
128 frames in 5.0 seconds = 25.488 FPS
110 frames in 5.0 seconds = 21.960 FPS
128 frames in 5.0 seconds = 25.600 FPS
130 frames in 5.0 seconds = 25.809 FPS
128 frames in 5.0 seconds = 25.554 FPS
129 frames in 5.0 seconds = 25.749 FPS
129 frames in 5.0 seconds = 25.616 FPS
130 frames in 5.0 seconds = 25.824 FPS
---

This is running with maximised window on the 800x480 display. So probably something around 790x470 pixel ?! A bit better. Maybe i still have some mistakes in my simpel-panel.c setup that impacts framerate, but anyhow es2_info should probably neither use the panel, nor Segfault, right?

-Tobias

mripard commented 6 years ago

I'm not sure what makes you say that es2_info is using the panel.

But es2gears is probably synchronized on vblank, so yeah it looks like a misconfigured panel. Either way, this is really not a Mali driver issue. I'm closing the issue now.

toluse commented 6 years ago

@mripard I was saying that es2_info should probably not use the panel for querying the capabilities of a GPU. But i have to check in the source...

I find this and the related Odroid forum post a bit a bit worrying though:

[xcb] Unknown request in queue while appending request [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that.

Alas you are the expert, so me doing something else wrong is more likely than a bug in the Mali userspace library.

-Tobias

Halolo commented 6 years ago

Hi,

If you still need inspiration for your bitbake recipe, here is the one I wrote for a H3 board, but with DVFS and DEVFREQ disabled. https://github.com/Halolo/orange-pi-distro/blob/master/meta-opi/recipes-kernel/mali/mali_r6p2.bb

Note that I experienced some problems also, segfault in libmali.so when I try to run egl_info or any egl test app.

marsohod4you commented 5 years ago

I have issue already described here: my Xorg says: (EE) _CREATE_GEM({height: 1080, width: 1920, bpp: 24 buf_type: 0x0}) failed. errno: 22 - Invalid argument [ 7564.890] (EE) ARMSOC(0): ERROR: Cannot allocate scanout buffer

I read I need to cherrypick "NextThingCo/linux@e390023" But what is this? Can You please point exactly to this commit? I cannot find it. Where is it? I do not see project "linux" at github.com/NextThingCo

lazant0 commented 5 years ago

@marsohod4you https://github.com/mripard/sunxi-mali/issues/63#issuecomment-470973499