Porting Qt 5.3.2 to Ubuntu LXDE on BD i.MX6Q SABRE-Lite with HW graphics acceleration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Porting Qt 5.3.2 to Ubuntu LXDE on BD i.MX6Q SABRE-Lite with HW graphics acceleration

Jump to solution
3,820 Views
philipphörler
Contributor II

I'm porting the Qt 5.3.2 source to my i.MX6 SABRE-Lite. Everything's working well except QPA (Qt Platform Abstraction) related issues. I've no success on starting my test application (QtWidget-Based GUI with a child widget serving as OpenGL-Rendering surface). EGLFS compiles fine but runs into Seg Fault during application startup (same with plugins DirectFB and XCB). According to the Qt configure summary XCB should run fine.

The cause of the problem seem's to be in the OS driver setup or some incompatibillities between the Kernel- and the OS-libraries. I'm using the OS-libs from the VIVANTE GPU SDK (gpu-viv--x11-bin-mx6q-3.10.17-1.0.0) because Qt should be built on top of an X11 environment with Openbox window manager.

Does somebady made some similar experiences?

What should i consider to get Qt 5.3.2 running on top of X11 (LXDE) with OpenGL support?

My setup:

- Boundary Devices SABRE Lite (i.MX6Q)

OS:

- Kernel 3.10.17-8-boundary-4t3

- Ubuntu with LXDE (from

- gpu-viv--x11-bin-mx6q-3.10.17-1.0.0 installed

- hard float toolchain

Regards, Philipp

Labels (2)
1 Solution
2,052 Views
TeleLaci
Contributor III

Hi Philipp,

Ok, its done, I moved to another repo. Here you go :

http://storage.googleapis.com/boundarydevices.com/20141117-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lx...

Its quite big image because all of the Qt5 demos were installed for testing. Few of them can't run without problem because :

  - they want a specific GL extension, but its not available.  These Qt things used to run on Intel, AMD platforms, where they can have hundreds of GL extensions. Unfortunately Vivante has quite few of them. You have to live with this, if you want to develop for Vivante GL drivers.

  - they call swapBuffer() or similar function. There are no buffers to swap, only one. Unfortunately Vivante X11 driver doesn't support double/triple buffering and VSYNC at the moment. As far as I know, the Freescale guys are working hard on it. I don't know when can we expect X11 double buffering, maybe in January with the new 3.10.31_1.1.0 ? Otavio knows more about this, I'm sure.

Regards,

Laci

View solution in original post

0 Kudos
18 Replies
2,052 Views
TeleLaci
Contributor III

Hi Philipp,

Wait a bit please don't download that, Eric was mistaken, its not a Qt5 image. I'll upload one in the weekend I promise, and I'll let you know.  But Its Qt 5.2.1 , that is the official version in Trusty Tahr.

Regards,

Laci

0 Kudos
2,052 Views
philipphörler
Contributor II

Hi Laci

Thanks for the effort you put into this. As I have seen, only the libraries of Qt 5 is installed on Eric's image but not the development headers and qmake. It would be great if you can include the Qt 5.2.1 headers and qmake in the image you're going to build.

The code should work on Qt 5.2.1 with minor changes in QOpenGL related code... but this should be fine.

Thanks a lot

Philipp

0 Kudos
2,053 Views
TeleLaci
Contributor III

Hi Philipp,

Ok, its done, I moved to another repo. Here you go :

http://storage.googleapis.com/boundarydevices.com/20141117-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lx...

Its quite big image because all of the Qt5 demos were installed for testing. Few of them can't run without problem because :

  - they want a specific GL extension, but its not available.  These Qt things used to run on Intel, AMD platforms, where they can have hundreds of GL extensions. Unfortunately Vivante has quite few of them. You have to live with this, if you want to develop for Vivante GL drivers.

  - they call swapBuffer() or similar function. There are no buffers to swap, only one. Unfortunately Vivante X11 driver doesn't support double/triple buffering and VSYNC at the moment. As far as I know, the Freescale guys are working hard on it. I don't know when can we expect X11 double buffering, maybe in January with the new 3.10.31_1.1.0 ? Otavio knows more about this, I'm sure.

Regards,

Laci

0 Kudos
2,052 Views
philipphörler
Contributor II

Hi Laci

You saved my day. The image is working well and the Qt GUI prototype runs fluently with 3D HW acceleration.

I'm going to compare your image and mine to find out the reason for the broken compatibility between QPA and the installed OS graphic libraries. Can you provide me additional details on the used kernel and rootFs configuration, library versions and the workflow to create the image?

Thanks to Otavio and Laci for their help on this post.

Philipp

0 Kudos
2,052 Views
TeleLaci
Contributor III

Hi Philipp,

>> "...Can you provide me additional details on the used kernel and rootFs configuration, library versions and the workflow to create the image..."

You can find the kernel .config in the /boot directory (config-ABI-FLAVOUR) , rootfs has no one specific config file, but many in /etc and other dirs, installed library versions can be dumped by dpkg -l

For example :

$ dpkg -l | grep libqt5

will dump the qt5 libraries (or any installed package containing "libqt5" in the name)

The workflow is not so short, but basically the image was created by qemu-debootstrap and pbuilder.

Regards,

Laci

0 Kudos
2,052 Views
OtavioSalvador
Senior Contributor II

Glad you got it up and running :smileyhappy:

0 Kudos
2,052 Views
TeleLaci
Contributor III

Hi Philipp,

Yeah, there is a Qt5 but its not accelerated, that is actually useless, at least for OpenGL tasks.

You need to wait till weekend, sorry. It is done and working fine, but I have to move it to another repository, or your image could get broken anytime when I change the repo.

Regards,

Laci

0 Kudos
2,052 Views
OtavioSalvador
Senior Contributor II

Hello philipphörler,

Did you ever considered using Yocto Project for the project?

Even though Ubuntu may seem attractive for initial development I think it is not the best option for long term products. Some remarks I usually provide to our customers when choosing a generic distribution are:

Using a common Linux distro

  • Either customer, 3rd party, or a community is responsible for:
    • Choosing which components from the Freescale BSP (U-Boot, Kernel, GPU/VPU/IPU support stack) to use
    • Porting the Freescale BSP components to the desired Linux distribution
    • Maintaining the distribution (updating BSP and non-BSP components)
    • Backporting bug and security fixes released either by Freescale BSP Team or the Linux distribution vendor/maintainer
    • Assuring copyleft compliance, by collecting all the changes made on top of the original Linux distribution packages for the inclusion of the Freescale BSP components, together with the source code of the unmodified Linux distribution packages (even if using a prebuilt rootfs as base) for all software carrying copyleft licenses such as GPL, LGPL, etc.
    • Assembling the product image, using custom scripts or tools, to include the required application binaries and packages
  • Customer is tied to the distribution dependency tree, which may not be optimized for the hardware platform or for the design goal (performance/size/cost)
  • Customer uses in-target build or a toolchain for application development
  • Customer can use the provided package management tool and package repositories available, however binary compatibility issues may happen due to changes inherited from the Freescale BSP (U-Boot, Kernel, GPU/VPU/IPU support stack) components inclusion

In case you conside Yocto Project  as an option, I advise you to take a look on FSL Community BSP. It has some benefits as:

Using FSL Community BSP

  • BSP maintained by community
  • Synchronized to the Yocto Project release schedule (releases every April and October)
  • Releases maintained for about one year, following the Yocto Project maintenance cycle
  • Support for a broader variety of chip families (MX23, MX28, …, MX6, QorlQ Layerscape)
  • Support for a broader variety of boards including reference boards, development kits, SoMs and SBCs from Freescale, 3rd parties and other communities
  • Security and bug fixes constantly applied on latest stable releases
  • Community BSP updated with latest components from Freescale's official releases, usually in a couple of weeks after the release
    • The work is done in a collaborative work between the Community and the Freescale BSP Team
  • Support is provided by community members

Specifically about using Boundary Devices boards with it, it is peace of cake as Boundary Devices does an outstanding job in maintaining their boards well supported there. If you want, you cake take a look on the Release Notes. To enable the Qt5 support it is dead simple and it is basically adding the Qt5 support layer and it allow you  to easily generate images, application and SDK toolchains for development.

This is just our advice so don't feel pushed...

0 Kudos
2,052 Views
EricNelson
Senior Contributor II

Hi Otavio,

While I agree with most of your comments (i.e. custom is better), with Laci's help, we at Boundary Devices are committed to providing upgrades to our Ubuntu releases.

Unlike Freescale's periodic releases, we are backing each of these with proper packaging of kernel and other BSP bits like acceleration, so the image doesn't crater if you 'apt-get upgrade'.

You're also right that Freescale-provided bits in our images will lag behind, but there are also bits that are more actively maintained in Ubuntu than in Yocto, and it's much easier to use apt to upgrade things than re-image a system.

This is definitely one of those areas where different needs lead to different "best fit" solutions.


Regards,

Eric

0 Kudos
2,052 Views
OtavioSalvador
Senior Contributor II

I agree with all that and I do have projects we maintain on top of Debian and Ubuntu (not Freescale-based though)[1] and the biggest cumbersome is the (a) maintenance and (b) copyleft license compliance process.

1. http://www.ossystems.com.br/blog/2013/09/05/interactive-computer-the-development-of-the-operating-sy...

For (a) it is problematic as embedded systems usually involves customization and this requires patches to be maintained and reapplied every time a new update package comes out. I know Luci is doing an outstanding job maintaining the image updated and running but this involves the basic BSP system and a small set of packages (as Qt5) but the customization needs which are customer-specific imposes a maintenance workload which is high. This works very well though when the product is very close of a Desktop system and does not require patches to be applied.

In (b) case, the requirement of making the source code of copyleft components used in a product is another issue; every time we update a component it needs to be redone and if customer is not very careful it can easily get out of control.

0 Kudos
2,052 Views
EricNelson
Senior Contributor II

s/Luci/Laci/

0 Kudos
2,052 Views
philipphörler
Contributor II

Hi Otavio

You are absolutely right, availabillity, support, maintaining etc. are relevant features which a software package for a final product on the market should provide.

At the moment I'm working on a feasibility study on the performance requirements of a new HMI. It's kind of a fast prototype which implements the most demanding control elements (in terms of computatinal power and graphic acceleration) to do some profiling on the i.MX6Q. The most comfortable way to do this is on a "Desktop-Like" system including a window manager and the Qt 5 development library to build  directly on the target... I must admit, this is not the most elegant way to develop, but the easiest. If I'm going to Yocto, then I definitely setup a cross developement host.

I definitely going to give Yocto a try. Freescale uses Yocto since 3.10.17 right? If I remember right 3.0.35 was built with LTIB...

Thanks for your input.

Philipp

0 Kudos
2,052 Views
OtavioSalvador
Senior Contributor II

For performance profiling, specially it being a HMI product it seems it would benefit from a very lean system which runs few daemons as possible and avoids all Xorg stack (running in Framebuffer in EGL environment).

Even though the cross-compiling environment might seems complex it is peace of cake when using QtCreator and we do have it properly working on Yocto Project.

We at O.S. Systems can assist you to shorten all this steps if you want to; also we can assist you in profiling what might be need for your application. In case you intend to give Yocto Project you might want to check the book DaianeAngolini and I released.

2,052 Views
EricNelson
Senior Contributor II

+1 for the book.

Especially for newbies like me, this has been a big help.

Thanks OtavioSalvador and DaianeAngolini!

2,052 Views
EricNelson
Senior Contributor II

Hello Philipp,

TeleLaci has Qt5 acceleration enabled now, and you can test it out by using this image:

     http://boundarydevices.com/eula?file=20141029-nitrogen-3.10.17_1.0.1_ga-trusty-en_US-lxde_armhf.img....

0 Kudos
2,052 Views
philipphörler
Contributor II

Thanks, Eric.

But the link's broken...and I could not find the file on Boundary Devices website.

0 Kudos
2,052 Views
EricNelson
Senior Contributor II

Sorry about that Philipp,

Our web-site is undergoing some (re)construction, so you can use this link as well.

        http://storage.googleapis.com/boundarydevices.com/20141029-nitrogen-3.10.17_1.0.1_ga-trusty-en_US-lx...

You may also be able to use "apt-get update" and "apt-get dist-upgrade" to get the core stuff, but TeleLaci put some nice desktop shortcuts in the image.

0 Kudos
2,052 Views
philipphörler
Contributor II

Alright, I got the image and give it a try.

Thank you very much for pointing me to this.

0 Kudos