Want to try hard float vivante drivers for MX6?

[avoltz]

Hello MX6 users,

I work for Timesys and have been integrating the Vivante drivers into our LinuxLink tools for mx6. In this thread I'd like to invite you to try out some of our built SDKs.

I've done a lot of wrangling with our tools and these drivers on X & framebuffer, and am currently working on QT4 & QT5 support. I still wouldn't call myself an expert, but I'd like to learn from your expertise and share these builds to hopefully improve our support out of the box.

We have a free web build service, but at this time only soft-float can be built the web service, so I'll be uploading built SDKs to dropbox and sharing the links here.

About the SDKs:

We provide built SDKs as an installer script which can be distributed to developers for building applications with a cross-toolchain. To install the SDK, run the .sh file contained within these published tarballs to install the toolchain and RFS, kernel, to ~/timesys/.

DO NOT run as root (except to extract the RFS tarball).

These have been built on my host which is x86-64 Ubuntu 12.04, and therefore will not be compatible with 32-bit hosts. If anyone wants a 32-bit SDK let me know, I'll run a build.

Each sdk installer will create a few items under ~/timesys/<board-name>/: kernel sources, bootloader images, the toolchain, and also a built kernel image.

Since the SDKs include a toolchain, you can use this to build additional applications to run on the target! For this reason, I'm providing minimal RFS images.

The first built SDK is available here: https://www.dropbox.com/s/4cbpot1436l4tse/vivante-hardfloat-sdp.tar.xz

This SDK provides a toolchain, rfs, and kernel with an X desktop. However, I didn't include any real X applications apart from the vivante samples.

Testing the SDK:

I use tftp/nfs to boot the SDP (bootargs=console=ttymxc0,115200 video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 ldb=sin1 root=/dev/nfs ip=dhcp)

Here's a quick boot log snippet of running a test on the SDP:

Distribution built using LinuxLink by Timesys
Kernel 3.0.35-ts-armv7l for armv7l
SABRE_SDP login: root
No mail.
root@SABRE_SDP:~$ X &
[1] 1307
root@SABRE_SDP:~$ _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/SABRE_SDP:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

X.Org X Server 1.11.4
Release Date: 2012-01-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-40-generic x86_64
Current Operating System: Linux SABRE_SDP 3.0.35-ts-armv7l #1 SMP PREEMPT Tue May 7 08:39:50 EDT 2013 armv7l
Kernel command line: console=ttymxc0,115200 video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 ldb=sin1 root=/dev/nfs ip=dhcp
Build Date: 07 May 2013  09:22:06AM

Current version of pixman: 0.28.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan  8 13:12:54 1970
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
(EE) GLX: could not load software renderer

root@SABRE_SDP:~$ export DISPLAY=:0
root@SABRE_SDP:~$ cd /opt/viv_samples/vdk/
root@SABRE_SDP:/opt/viv_samples/vdk$ ./tutorial7
fps: 727.27
fps: 729.34
fps: 730.73
^Croot@SABRE_SDP:/opt/viv_samples/vdk$
----snip----

A few notes about this log:
X has no session/nothing to start, so I start the server manually. Then set the display and run the tutorials under /opt/viv_samples/

When using the X drivers, I've been unable to run tiger & vv_launcher without using fullscreen on the SDP. Use these commands to run those samples:
./tiger -w 1024 -h 768
./vv_launcher -w 1024 -h 768

Also, some of the samples must be run in the directory where they reside--they are coded to use images using relative path.

Later this afternoon I'll be posting the framebuffer only version of the SDK. If you can't wait for a framebuffer-only SDK, the tarball containing both soft & hard float builds is here http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q-1.1.0-ts/gpu-viv-bin-...

FYI, I split these vivante drivers into 2 packages for now, one for X and one for framebuffer only. Hoping to add a directFB build and eventually wayland. For now only the Framebuffer and X versions are available on our repository.

Roadmap

We're awaiting a new drop of the vivante driver sources which will hopefully improve performance. Also we are aiming for DirectFB & wayland support in the coming weeks, but again that may require new vivante sources. I have a DirectFB build, but it doesn't seem to work.

I have done some testing with Qt5 and qt4, and will provide SDKs for testing as well as feedback over the next couple of days. I've not had success with the X drivers & QT, but the framebuffer seems to work.

I've also had some trouble with the DirectFB builds I've used, but perhaps we can get into that as well.

Thank you all for the feedback,

Regards,

Andy Voltz

[kende]

Has anyone got vivante, wayland and Qt5 to work with hard float binaries? I'm trying this Kontron i.MX6q board which uses different kernel than freescale and none of the soft float vivante binaries work, only this hard float version but only with eglfs.

[claymontgomery]

Qt5 works with Matchbox/Sato and hard-float on the Dora release of Yocto.  I'm not sure if that uses Wayland or not.  I have built and run the Vivante samples for hard-float and framebuffer mode on Dora for the WandBoard.

Google Groups

Regards, Clay

[paulgeurts]

Do these libraries also work for i.MX6 Solo and Dual Lite CPU? These are equipped with a different 3D core.

[mtx512]

I have tried later versions of the libraries on a i.mx6 solo board and they work fine.

[TeleLaci]

Timesys has released some more binaries since then:

http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q-3.0.35-4.0.0/gpu-viv-...

http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q-3.0.35-4.0.0-ts/gpu-v...

http://repository.timesys.com/buildsources/g/gpu-viv-x11-bin-mx6q/gpu-viv-x11-bin-mx6q-3.0.35-4.0.0/...

All of them have an armel and an armhf directory.

That's very nice, thank you.

But.

In those armhf directories, among those armhf libraries there is one doesn't belong to the group an armel library named libCLC.so

This must be a bug if I'm right, because armel binaries pass floating point values in integer registers while armhf binaries pass them in vfp registers. So you can't mix armel binaries/libaries with armhf binaries/libraries.

Would you please check it and fix it, that must be a simple mistake, but it can cause serious and mysterious bugs.

[xobs]

Do these libraries require a specific version of galcore?

I'm using a version copyright 2013, taken from the gpu-viv/ directory in L3.0.35_4.0.0_130424_source/pkgs/linux-3.0.35/drivers/mxc/, compiled as a module for linnux-3.10.0-rc7.  The libraries linked here look like they use 32-bit pointers for the ioctl DRIVER_ARGS data, and the gcsHAL_INTERFACE pointed to is 128 bytes, whereas the version of galcore that ships in L3.0.35_4.0.0_130424 uses 64-bit pointers for ioctl DRIVER_ARGS data and gcsHAL_INTERFACE is 168 bytes.

[mtx512]

Hi Andy,

We tested the binaries on a Linaro 12.11 build, we can run es2gears/glmark2 as root, initial figures are marginally better than armel. However these fails to run as a non-root user (ie linaro), I've checked the obvious permissions, groups and  xorg.conf and it seems to be ok.

gdb reports the following:

Starting program: /usr/bin/es2gears

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.

0x2ad9e8a8 in gcoHAL_QueryChipCount () from /usr/lib/libGAL.so

Also the viv_samples don't run as there seems to be a binary compatibility issue.

We have tested the same setup on a Linaro armel build using the softfp binaries and everything runs fine.

[arslan]

Hi Andy,

I have the same situation here. I am using Boundry Nitrogen6x board. I got Qt5 with your Vivante-libs FB-only running. I could run the "collidingmice" example from qt with eglfs. Then I switched fron kernel 3.0.35_1.1.0 to 3.0.35_4.0.0, now the programm segfaults at the call eglBindAPI(...) in the constructor of the class QEglFSIntegration. To cross-check, I switched back to 3.0.35_1.1.0 and everything was fine again.

Can you verify this?

[ortogonal]

I got the same problem. Was you able to solve it?

[avoltz]

Just to confirm, it sounds like you have tried our binaries with the Linaro RFS? Have you tried building the es2gears glmark2 samples with one of the SDKs I posted? If you link me to the sources of those examples I can try to build them here and let you know.

[mtx512]

Yes we tested with a Linaro RFS. Our sources will have been pre-built from Ubuntu – Details of source package mesa-demos in precise ,as mentioned they run as root and seg fault as non-root. So I'm guessing there seems to be a permission problem somewhere?

[avoltz]

I haven't used the Linaro RFS, but can you check the permissions on /dev/galcore and /dev/fb0?

With the RFS from the framebuffer-only SDK I posted above, I needed to run "chmod 666" on those device nodes.

[mtx512]

Thanks :smileyhappy: the problem was permission on /dev/galcore.

Next issue is that the vivante samples don't run:

root@linaro-alip:~/viv_samples/vdk# ./tutorial7

-bash: ./tutorial7: No such file or directory

Seems to be some kind of libc compatibility issues. Can we compile the samples from scratch?

[avoltz]

Unfortunately, I don't think so... Try the RFS from one of the SDKs I posted above, or perhaps yocto.

[avoltz]

And now for the framebuffer only version: https://www.dropbox.com/s/0dpghzo9u1coqt2/vivante-hf-fbonly.tar.xz

In this case, the tiger & vv_launcher demos do not require any arguments. Next: QT

[Dennis_Han]

good job !

very interesting !

I haven't tested yet though, it seems there is no qt related in you sdk.

would you give me sdk that has qt(4.x or 5) and gstreamer ?

[mtx512]

Do you know if the binaries will work against xorg 1.13 if we patch the dri driver?

[avoltz]

Unfortunately, no. The other driver sources require additional patching. I'm hopeful the next sources I receive will support a newer X, but for now 1.11 is required. Our system builds 1.11 for the mx6 for this reason.