How do we natively compile GPU and VPU support on i.MX6 CuBox platform

[aerodame]

We have fully working base Linux distros of either Ubuntu 3.14.14 or Debian Wheezy that are compiled and downloaded from the fine folks at www.armbian.com/downloads.  We wish to add OpenGL 2.0 (or 3.0) support for this platform, but can't seem to find clean NATIVE build instructions on the Freescale i.MX6 site.  To test for success, we should be able to run the make files in the GPU SDK, but they currently fail due to lack of header files and presumably libraries.

Is it possible to completely compile in SDK support on top of the distributions we already have?  We do not wish to cross compile as that sets us back to an earlier distribution and also takes a significant amount of cross compile time under Yocto.

Even better is there an apt-get install method to accomplish the same?

Thank you.

[mtx512]

If you are wanting OpenGL (and not OpenGL ES) support then it isn't officially supported on the imx6. There is a libGL.so library included in the gpu libraries however it's not fully compliant and won't match the mesa headers for OpenGL. You can deploy mesa OpenGL but it will resort to software rendering.

If you're needing OpenGL ES support and then it possible to overlay the gpu libraries and headers over a Linux distro. You need to remove the mesa library/headers and replace them with the fsl gpu libraries/headers (for X11 there is a few more steps).I have compiled & run a few of the gpu-sdk samples this way by tweaking the makefiles. We have also created a few gpu applications this way so it is possible and removes the lengthy overhead of Yocto build.

[aerodame]

This sounds very promising.  Do you have a blog or a recipe that specifies exactly how to do this?  Yes, I'm only interested in what is supported in Open GL ES.  Sorry I wasn't specific about that.

[mtx512]

You can download imx-gpu-viv hfp (5.0.11.p4.5) from here for bsp 3.14.28-1.0.1.  On extraction of the binary:

1. copy the libraries gpu-core/usr/lib/ & g2d/usr/lib

2. copy headers gpu-core/usr/include/ & g2d/usr/include/*

Patch up the symlinks for fb support, there is a old blog entry which should help you. Ensure mesa libraries/headers aren't present for GLES before you deploy.

If you planning to use EGL/GLES against fbdev then beware that it is a very low base to start from because there is no GUI framework. Therefore libraries like Cario, Pango, HarfBuzz etc which a number of linux application rely upon may not run or resort to s/w rendering (see here). You can deploy QT (cross compile) to provide a GUI framework but again not everything is accelerated because of the lack of fbdev support in certain areas. We have had a number of customers approach about GPU acceleration for their projects and it can be challenge to meet their expectations as there is little appreciation of the software stacks involved.

[PrabhuSundarara]

First setup Yocto build and build core-image-x11 for i.MX6 board for example sabresd

In the Yocto downloads you will find imx-gpu-viv-5.0.11.p7.1-hfp.bin or imx-gpu-viv-5.0.11.p7.1-sfp.bin depends on the environment you are building. by default will build hardfp. Also you will find xserver-xorg-video-imx-viv-5.0.11.p7.1.tar.gz source code file.

Self extract imx-gpu-viv-5.0.11.p7.1-hfp.bin and deploy to the target.

If need to run Framebuffer, then use -fb based libraries in the usr/lib/..

If need to run X11, then deploy x11 or dri based libraries. Also you need to build xserver-xorg-video-imx-viv-5.0.11.p7.1.tar.gz for the XServer version running on the target.

Ubuntu is not officially tested platform. Please informed if any problem.

[aerodame]

We've tried Yocto builds (even the minimal core bitbakes) and they take an enormous amount of time and rarely succeed even on a fully fleshed out i7 core VM x64bit, iwth over 100GB of disk space.  But downloading the L3.14.28_1.0.0_iMX6QDLS_BUNDLE now... and will try to see if it will succeed.   Are you suggesting to just do the build but then copy over the graphics libraries?  Could you provide a bit more specifics on a list of each specific file and where they need to be copied?  Are there some specific tools that need to bind any of these to the kernel when you perform a side copy over an existing based image (in our case we are using this Debian Wheezy base images from Armbian as our starting point -- it is stable and runs fine to display a desktop).  (Cubox-i | armbian​  

In this case, we are building for the CuBox-i Pro 4x4 which is the latest platform from Solid Run.  We have a number of these boxes proposed to be used for image generation and we would like to be able to operate from a very stable core Linux distro and add features like you would normally add as packages. 

Also, I'm confused as to where the central repository is for all of these reference builds. There are repos scattered all over the web from various points.  How does the link you provided compare with this one I came across?   linux-2.6-imx.git - Freescale i.MX Linux Tree

I would prefer to pull from an authoritative git REPO if possible.

[david_wolfe]

Stephen,

As you've gathered, Freescale supports cross-compilation leveraging Yocto Project and not native builds with Debian Package Manager or binary distribution of same via APT. Previously Freescale provided an Ubuntu-based release via Linaro. While Ubuntu is great — among other things, for quickly assembling demos (something we apps engineers rather like) — it was determined that a large majority of our i.MX customers required a system more like Yocto Project. As Freescale does not have the resources to support (and test) both, the majority are supported.

Seemingly it should be possible to convert the build recipe from YP to a simple list of shell commands which can be converted to an APT source package. Please understand that using the Freescale GPU support outside of Yocto Project cannot be tested by Freescale.

You can find the pertinent bitbake recipes at the following URL.

     http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-fsl-arm/recipes-gra...

You can strip the path down to the following within your checked-out YP repos.

     source/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/imx-gpu-viv

Therein the SRC_URI can be expanded to an obfuscated path to download imx-gpu-viv-5.0.11.p4.5-hfp.bin or …sfp.bin as mentioned by mtx512​.

The Vivante binary files are proprietary. There is no git repo for them. Freescale requires customers acknowledge an End User License Agreement in order to use those binaries as required by our own license with Vivante. As such, I am not at liberty to provide a direct download URL.

If the SRC_URI remains opaque, You can also short-circuit the Yocto build with "bitbake imx-gpu-viv" which has far less to build.

Don't let the *.bin file name fool you. It's just a shell archive (.shar). Extracting it is fairly straight-forward — "/bin/sh imx-gpu-viv-*.bin". It contains compiled libraries and header files. If you're running an X11 server, you will also need to rebuild it with these OpenGL ES libs.

--

David

[aerodame]

Hi David,  I really appreciate your getting back with us on these difficulties.

Frankly, we ran out of time to try and find a solution a few days ago-- and we had to switch to another chip vendor.   I'm struggling with the idea of how to use i.MX6 in our project under the following scenarios as I understand it.   Just to set the atmosphere, we don't have a lot of development time and we are trying to focus on application solutions rather than really low level OS development and BSP porting to HW platforms we don't build.  This is why we look to the broadest community support for software on a given platform.  Things like RPi, Beaglebone, Arduino, and CuBox have large followings because they tend to make things simple and are well supported in the community.

Scenarios:

1) Building Yocto -- It is not clear, error prone and takes a huge amount of time to build Yocto builds.  If you don't know the exact low level configuration parameters then you are spending a lot of iterations trying to build an image.  End the end if it doesn't have a package manager, you are hard pressed to extent this images to get work done.  There also seem to be issues with Freescale Bit bakes on various Virtual Machine engines (VMWare, VirtualBox), but frankly every time I've tried to go down this path, some error occurs after hours or the bit bake just gets stuck at somelike like 642 of 3123 steps and never completes ever after more than a day (running on a powerful i7 core laptop with plenty of RAM and disk space --- but in a VM).  We don't have machines sitting around a dedicated bit bake bare metal Linux OSs...  I can't understand why VMs are so problematic.

2) Starting with a solid OS distro and building up -- I spent over a week trying to go from a very stable Debian or Ubuntu image (we have both) on the CuBox and wading through how to "add binaries" to support the VPU/GPU.   I see there might be some light at the end of the tunnel from your instructions above, but now I'd have to spend a couple more days and I'm out of time on this project at the moment.  I want you to know I do want to try all of this, but it will have to be deferred.

3) Starting from a multimedia distro and breaking it down for development - We started to try and use Android for development, but ran into numerous problems with that and it was too much of a time drain.  Also the GPU performance benchmark apps that run on Android were very disappointing and didn't inspire any confidence it would be useful to pursue this path... so abandoned for option #2).  DIdn't have enough time to chase down the XBMC distro and break it down for similar reasons.

For your links above, I tried a cursory build process, but it was a dead end.  The link you provided only takes me to three config files.  Not sure what to make of those. I did full the tabs to the summary page and tried downloading the tar.gz zip files, but they don't seem to have the full Yocto build packages so again not sure what to do with those.  I also cloned the link  git... (this forum doesn't allow pasting links it seems)... and it was a quick download, but no joy....

So it is late, and I'm going to have to look at this at a future date to see if there is any joy.   My advice to Freescale is to spend time ensuring that the leading SOM vendors are better supported with actual full packages available for download on their sites and/or Freescale's site.   Folks like the gentleman at "ARMBIAN" provide a super clean build process (but unfortunately do not yet provide graphics support) for their Linux distros.  You should try downloading their links and running their build process to see what I mean as a great example of a clean build.

As other anecdotal information, I've heard from "core" SOM developers that they don't use Yocto (probably for similar frustrations).  I think the idea of Yocto is great it just doesn't seem to live up to the promise.