IMX8 Torizon QT5 torizon-core-docker

Technical Support
, ,
1

Dear Community.

Recently, I proudly owned the IMX8 module, which I run on the Ixora V1.1A board.
By following the torizon image building how-to
(https://developer.toradex.com/knowledge-base/build-torizoncore#native-torizoncore-build),
which is straight forward, the clean building was successful on both, the zeus branch and the master branch (https://github.com/toradex/toradex-torizon-manifest). Even the SDK toolchain was built successfully.

When I added the q5 layer (https://github.com/meta-qt5/meta-qt5) and having the right branch selected, neither the zeus manifest nor the master manifest of torizon was built succesfully by the native bitbake command. Attached, you can see the errors printed at the terminal:

bitbake torizon-core-docker
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:01:57
Parsing of 2689 .bb files complete (0 cached, 2689 parsed). 3887 targets, 564 skipped, 5 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/libgles2' (but /home/margrum/yocto-workdir-master/build/conf/../../layers/meta-qt5/recipes-qt/qt5/qtbase_git.bb DEPENDS on or otherwise requires it)
imx-gpu-viv PROVIDES virtual/libgles2 but was skipped: incompatible with machine apalis-imx8 (not in COMPATIBLE_MACHINE)
gpulib PROVIDES virtual/libgles2 but was skipped: incompatible with machine apalis-imx8 (not in COMPATIBLE_MACHINE)
imx-gpu-viv PROVIDES virtual/libgles2 but was skipped: missing required distro feature 'wayland' (not in DISTRO_FEATURES)
NOTE: Runtime target 'qtbase' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['qtbase', 'virtual/libgles2']
ERROR: Required build target 'torizon-core-docker' has no buildable providers.
Missing or unbuildable dependency chain was: ['torizon-core-docker', 'qtbase', 'virtual/libgles2']

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

By the way, more details on the current environment, you can find here:

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-tdx-linux"
MACHINE              = "apalis-imx8"
DISTRO               = "torizon"
DISTRO_VERSION       = "0.0.0-devel-20200427130523+build.0"
TUNE_FEATURES        = "aarch64"
TARGET_FPU           = ""
meta-toradex-torizon = "HEAD:8f527be635a889afc03f209c03573bcf9a6e7f8e"
meta-toradex-distro  = "HEAD:d2f191046b0481a73d178a8b189ce2e2ac2926f9"
meta-toradex-bsp-common = "HEAD:c61542ba4b1cf250459cc2e68e8739902492c613"
meta-oe              
meta-networking      
meta-filesystems     
meta-python          
meta-perl            = "HEAD:9d5f00ab18e37b9f58d9e8971a37621c595311d7"
meta-virtualization  = "HEAD:2bba10be28d4d7ce45d78a8429caaa6952785901"
meta-updater         = "HEAD:177081df3a793ee0e028b33bd416cdff97eee471"
meta-toradex-nxp     = "HEAD:77838d06a7e27b9cc0d9d572d0924a562a634862"
meta-freescale       = "HEAD:6ca16f44b8a2d148e74cf9c1a2eb8790e0bb0d51"
meta-freescale-3rdparty = "HEAD:bd63e443199e1eaa31962761d447e3fd0fac528d"
meta-yocto-bsp       
meta-poky            = "HEAD:6f73b728e2e5ad88c7b923ce30a0fdbe747a4ee1"
meta-security        = "HEAD:98a6664408f17560549b94f575e058ed84dd6a0d"
meta-lmp-base        = "HEAD:3f8596beab50fd502b911426f3cec70d38ff7c51"
meta                 = "HEAD:ff074f495dd4bb637618f790dd30e51e542cd30a"

Having realized hours in Internet research about this problem, it seems that the apalis IMX8 is not supported by now.
Although I have found a patch from June 2018 (https://patchwork.openembedded.org/patch/151975/), which carries about the IMX8 support, it is not part of the torizon manifest… I am wondering why…

Obviously, as there are some commercial images and toolchains holding qt5, there is a way to go…

So my questions are

  • How can I succeed
    in building the image?
  • Is this patch
    the way to go?
  • How can I apply this
    patch?
  • How to deal with the errors
    printed?

Thank you very much for your help.

Kindest regards,

Marcus

2

Greetings @Marcus,

Torizon is not really meant to be heavily customized like this. You can still do this and it is possible but we try to leverage containers instead for the purpose of customization.

We provide Debian based containers with Qt5 libraries as a reference: Qt Debian Container for Torizon | Toradex Developer Center

You can import Qt applications into this container and it should have the libraries needed to run. Otherwise you can apt-get any additional ones you require.

It is our goal in the future to provide better Qt support and eventual integration with the Qt creator IDE but unfortunately I can’t give any estimated timelines here.

Let me know if the Debian-Qt container works for you, and if not then please let me know why and perhaps any details about your project that might give some info.

Best Regards,
Jeremias

3

Dear Jeremias.
Dear Toradex.
Dear Community.

Thank you very much for your answer. Regrettably, I know this tutorial and have realized it already…
As the application development intends to consider the full graphical potential of Qt, for the first tests, I intended to start the CinematicExperience demo application. So far, I have not succeeded in starting this demo app.

  1. How would you proceed in starting this demo application by the Weston and Wayland containers presented at (Qt Debian Container for Torizon | Toradex Developer Center)?
  2. As the applications developed are intended to be updated over-the-air, from my point of view, the torizon image is the way to go. So, let’s assume to have each application provided by an individual docker container. For the development, I definitely require the SDK for the cross-compiling toolchain. This was the initial reason for rebuilding the torizon-docker image having the Qt5 layers in addition. I would like to build applications by the host system and provide applications over-the-air. Although I know the presence of commercial toolchains, the focus is set on non-commercial options. Hopefully, you see why I am still interested in the questions of my first post (How can I succeed in building the image? Is this patch the way to go? How can I apply this patch? How to deal with the errors printed?).
  3. Going one step further (that extends the initial post question but presents details about the project): Let’s assume to have realized the image and toolchain issued in the second question. I am not sure about the best way of providing the Qt libraries anyway: So in the one case, Qt is provided by the image created in the run of the toolchain building (see second question). Here, the over-the-air update is not enabled, if I understand torizon correctly. In the second case, Qt libraries are held by each application container provided. Here, the over-the-air update is enabled jointly with the application containers. So, when Qt libraries are updated, all the application-specific containers (or rather the corresponding docker images) need to be updated, which is effortful. In the third case, Qt is provided by an individual container, so that this Qt-specific container is updated by torizon’s over-the-air update mechanisms as well. Further application containers would require to be composed or to share the relevant folders of the library as volume. Here, on the one hand, updates are more efficient because Qt libraries are updated only once and not per application (second case). On the other hand, one needs to guarantee to have the containers in sync with the library. This addresses security issues and applications requiring different versions of Qt. So much about more details about the project. Hopefully, that helps. So, if you have further recommendations about the image design to go and the corresponding container design, I appreciate that much.

I am looking forward to hearing from you,

best,

Marcus

4

Hi @Marcus,

First of all thanks for the extensive detail this kind of feedback is much appreciated. Next let me try and answer/provide comments here as best I can.

How would you proceed in starting this
demo application by the Weston and
Wayland containers

So here what I would do is create a kind of test/evaluation container that builds and runs the cinematic experience demo app. For this container you can use our containers as a base and build on top of them, since these containers are arm-based it’d be similar to native compilation, at least in the sense you wouldn’t need a toolchain/cross-compilation SDK. Then you can just run the container on the module. This method is similar to how our Torizon IDE extensions function, they “cross-compile” by building applications in an intermediary SDK/toolchain container. We also have an article on generic C/C++ development on Torizon (IDE Extension | Toradex Developer Center), which can be loosely extended to Qt development.

I guess the above also comments on your concerns about needing to do a yocto build. Also let me just clarify that your approach is definitely still possible and could work. The only reason I’m suggesting against it is that if you were to create this Torizon + qt5 image, this configuration would be different enough that we at Toradex would have trouble supporting you on this if you were to run into further issues down the road.

Now as for your comments on updating Qt-Torizon applications/containers. The way I see, it either way if you want to update Qt libraries down the line this will require some building on your side, whether it be a new device image with updated libraries or new containers with updated libraries. Either method can use the default Torizon update mechanism. Though in my opinion building/testing/iterating on container images is quicker/easier than with yocto images. Also a small aside about libraries in containers. If you have say 3 Qt application containers that all use the same core set of libraries, what you can do is have a base docker image that all 3 are built on. This way you update and rebuild the base container then you just need to rebuild and redeploy the 3 end containers. So while yes you do need to rebuild and redeploy each application container, you are only really changing the base container image. Also this process can be easily automated to make sure everything is in sync.

So there’s my thoughts on your concerns/questions let me know if you have further questions or if I can clarify anything further.

Best Regards,
Jeremias