EGL on 3.0.35

[tselmeci]

Hello!

I've got linux-3.0.35 with galcore-4.6.9.1210 and gpu-viv-bin-mx6q-3.0.35-4.0.0 user space libraries/headers. The CPU is imx6dual (Engicam iCoreM6D). The gpu-viv bin package is maybe for imx6Solo, I haven't found the correct version for dual with galcore 4.6.9.1210.

My problem is that even the simplest OpenGL / EGL application fails to display anything complaining that it can't compile shader code.

I've been struggling with this for several days and can't see the solution. I've also given a try to etna_viv's mesa fork to use alternate OpenGL libraries, but that also provides no output (alongside with many errors).

Do you know how to solve this issue? Is it possible at all to have EGL running on 4.6.9.1210? It'd be very beneficial to stay at current kernel; I'd like to avoid porting the kernel to our custom PCB if possible (but not at all costs).

Thanks, regards,

[maxmustermann]

From my experience, you can forget any proprietary/binary drivers, especially for GPUs, per default.

They're usually broken by design.

A few month ago, I had to drop all GPU stuff on our MX53 target, as it produces hard-lockups.

There's only proprietary libGL.so binary with an *horribly* broken kernel counterpart - it completely bypasses the

usual DRM API and even introduces lots of easily-exploitable bugs (not even proper array index checks!). We're now using plain framebuffer. On mainline kernel (currently 4.2.3), of course (just a few on DTS patches).

Freescale still refuses to publish any specs, so we can't write our own drivers (w/o *huge* amount of reverse-engineering).

Right now, I'm evaluating the MX6 (on a tx6 board), struggling to get etnaviv driver running.

It's still alpha status (incomplete and unstable).

But I'm also fighting w/ QT5, which doesn't initialize EGL properly - looks like these are just dirty hacks to get certain broken-by-design proprietary drivers working somehow - far away from any sight of decent software engineering.

So, for the time being, we can summarize: *NO* GPU on MX5 and MX6.

(on MX6 that might change in future, but everything is still early WIP !).

I'm forced to give my clients an strong advice against Freescale SoCs, if they need a GPU.

[tselmeci]

etna_viv has its own 3D API, which appears to run, at least I remember that some 3D stuff was running with etna_viv, but it wasn't coded with OpenGL etc. API. That's why the purpose of etna_viv_mesa would be to wrap etna_viv drivers and to provide the OpenGL/etc. interface. And this is not working for EGL (required by Qt).

For 2D, etna_viv is perfect, I've using it for a while and I'm very satisfied with the performance. I've dropped Qt support and I'm coding the _simple_ 2D GUI by hand using direct framebuffer access and etna_viv 2D acceleration. To be honest I enjoy this much more than struggling with Qt.

I've no better advice, compile the latest Yocto and grab the kernel sources/userspace libraries, I believe they're functional. The only reason why I'm not doing the same is that currently I'm in a rush with my project and can't afford spending a lot of time to do the following porting chain: Yocto kernel --> Engicam kernel --> our custom kernel.

[Bio_TICFSL]

Hi Tamas,

this issue is due to an incompatible version pof galcore and kernel, please check tht for i.MX6D you need BSP kernel version -L3.0.35_4.1.0 for use the GPU 4.6.9 p12 version, this kernel version and gpu version shoudl works for Solo as well. Once you have the proper version load the galcore module $ sudo modprobe galcore  and you will be ready for OGL /EGL apps on GPU.

Regards

[tselmeci]

Kernel 3.0.35_4.1.0 has galcore 4.6.9.6622. Meanwhile I've switched to this kernel with the appropriate userspace libs and it's still non-functional. (/dev/galcore appears, but strange SEGFAULTs occur in graphics libs)

I've given it up. Maybe the kernel in Yocto would be suitable. I just wanted to use 3.0.35 since I've ported it to our custom PCB (and is operational in all other means) and wanted to save on beginning the porting process from zero in case of a newer kernel...