Steps to run a QML application on IMX7D with Non commercial licence

Hi everyone.

We are trying to develop a proof of concept for the GUI of an interface, and decided to use QT as graphic engine, and a Colibri IMX7D as hardware platform, as this is the best fit in term of price, and power consumption.

I’m really new in the linux dev world (only previous experience was with raspberry pi), and I initially thought it would be straightforward to get QT up and running. It seems I was wrong. I’ve established a plan of what I need to do, but I would like to see with you if I’ve got everything.

My goal is the following: having an embedded linux, with Qt installed on it, capable of building a QT application on its own, and capable of display in software mode a QML application.

Here is my understanding of what needs to be done:

Step 1: Prepare the yocto image

  • My PC is a mac, so I need to setup a virtual machine with Ubuntu 18.04
  • Follow this instruction (up to the section “Building”) to download everything I need
  • Customize the device tree (is it at this step, before building the image?) thanks to this instructions

Step 2: incorate Qt

  • Add somehow meta-qt5 to my build. There is several ressources on the forum such here to help me, but I haven’t still looked that much into it.
  • Will I be able to compile application on the target with just this? Or do I need something else

Step 3: build it

Step 4: Flash it

  • Put back the Easy Installer thanks to this instructions
  • Flash my Linux.

Step 5: Qt application

  • I would need to use the software renderer, and I shall be good to go.

Does it sounds about right? Am I missing some stuff, or have you got any advice?

Thanks a lot!

Regards

Hi @ParalaX

This sounds basically good. Did you already try it? meta-qt5 is included in our repo manifest. You can follow this guide:
https://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux#build-with-openembedded-layers

However, don’t expect it to be super fast because of the mesa software acceleration. A better approach would be to use the software renderer without using X11. So you would just need to compile the console image and add the qt libraries to your image as described here:
https://www.toradex.com/community/questions/18808/qt5-linuxfb-and-removing-egls-providers-from-qtbas.html

I would recommend to start this way and post your issues here if something fails.

Regards,
Stefan

Hi,

Thanks a lot for your answer. So in the past few days, I managed to get a Yocto image with a qmake on it, and boot from the sd card.

Next step is to get actual stuff compiling (I just checked that I had qmake), then modify the kernel to add everything I need.

I’ll post question here if it arise, and I’ll try to add a summary of what I did, so it can serve someone later :slight_smile:

Regards,

Matthieu

Hi,

So I’ve been trying to compile a QML program lately, without success. My goal is to compile for the moment a simple “QML” hello world.
#include <QtQuick/QQuickView>
#include

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);

    QQuickView view;
    view.setSource(QUrl("qrc:///main.qml"));
    view.show();
    return app.exec();
}

Unluckily, I’ve not been able to make it work. Indeed, my compilation (on the target) gives the following error (in the linker):

undefined reference to `QQuickView::QQuickView(QWindow*)' 
undefined reference to `QQuickView::setSource(QUrl const&)'
undefined reference to `QQuickView::~QQuickView()'

In my layer.conf, I’ve got the following, in addition to your base layer.conf:

IMAGE_INSTALL_append = "qtbase-plugins \
    qtbase-tools \
    qtbase-examples \
    qtdeclarative \
    qtdeclarative-plugins \
    qtdeclarative-tools \
    qtdeclarative-examples \
    qtdeclarative-qmlplugins \
    qtsensors \
    qtserialport \
    qtquickcontrols \
    qtquickcontrols2 \
"
PACKAGECONFIG_append_pn-qtbase = "qtquickcompiler tools debug developer examples no-opengl tests widgets"

#DISTRO_FEATURES_remove = "x11 wayland"
IMAGE_INSTALL_remove = "eglinfo-x11" 

I then bitbake the console image.

I’ve tried several Qt configuration, and tried to play a bit with the x11 settings, but this always lead to the same messages.

Any idea?

Regards,

Matthieu

Hi @ParalaX!

Are you cross-compiling via Qt Creator?

Did you configure the SDK with these instructions?

Do any of the built-in Qt demos run?

Hi @gustavo.tx,

Thanks for your answer. In fact I want to use the cross-compiling, I need to compile on the target directly. So I didn’t configure any SDK.

Regards,

Matthieu

Hi @ParalaX!

Do you want to cross-compile or do you want to compile natively on the target?

If you want to compile on the target, make sure you add

packagegroup-sdk-target

to your recipe too.

Thanks for your answer. The goal is to build on target. I’ve added your line in my IMAGE_INSTALL_append, however it doesn’t change anything: while I can compile a simple “Hello World” Qt console application, I can’t compile a QML application (with the linker error described above) or a Qt Widget application (missing at compilation time)

Hi @ParalaX!

How are you doing the compilation on the target?

In fact I’ve never trying compiling a QML project outside Qt Creator, but I suppose it runs qmake with all the proper arguments. Maybe there are some references missing there?

Hi,

So I finally got it: it was me that ware making the mistake of running qmake --project, thus reinitializing everything (it was quiet a dumb mistake to be honest…)

I still have a few issues with the fonts, and how to apply the patch for the touchscreen then I’ll be fully operational :slight_smile: I’ll look into it and come back if I can’t get it working, but I think I’m almost there :slight_smile:

Thanks for your help!

Hi,

So I’ve managed to apply my patch, unluckily it’s still not working. I can see the device in dmesg, it’s identified correctly. But no touch input.

The mouse is working correctly, so I don’t think I miss something in my image.

Any idea?

Matthieu

Hi @ParalaX!

Can you run evtest and check if there’s any output when you touch the screen?

If there’s output there, you might have to configure the correct environment variables for Qt to use the correct input device.
If there’s no output in evtest, it might be something with your device tree configuration or the device itself.

Hi @gustavo.tx !

Thanks :slight_smile: I didn’t know that tool. So I ran it and go this:

    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min        0
      Max      799
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min        0
      Max      479
    Event code 55 (ABS_MT_TOOL_TYPE)
      Value      0
      Min        0
      Max        2
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max    65535
    Event code 59 (ABS_MT_DISTANCE)
      Value      0
      Min        0
      Max        1
Properties:
  Property type 1 (INPUT_PROP_DIRECT)

But nothing happens when I press on the screen.

I attach you the patch I apply on the device tree (taken from the getting started with the screen, but modified to work with the latest version of the image, which is 3.0b3 in my case). Is it possible there is a mistake in the interrupt or something?

diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 217ddf0bcf75..b1805140642d 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -171,7 +171,7 @@
 		interrupt-parent = <&gpio1>;
 		interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* SODIMM 28 */
 		reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30 */
-		status = "disabled";
+		status = "okay";
 	};
 
 	touch: touchrevf0710a@10 {
@@ -321,11 +321,11 @@
 };
 
 &pwm2 {
-	status = "okay";
+	status = "disabled";
 };
 
 &pwm3 {
-	status = "okay";
+	status = "disabled";
 };
 
 &pwm4 {
@@ -383,7 +383,7 @@
 	pinctrl_gpiotouch: touchgpios {
 		fsl,pins = <
 			MX7D_PAD_GPIO1_IO09__GPIO1_IO9		0x74
-			MX7D_PAD_GPIO1_IO10__GPIO1_IO10		0x14
+			MX7D_PAD_GPIO1_IO10__GPIO1_IO10		0x74
 		>;
 	};
 };

I’m pretty sure the patch is applied: I’ve tried inducing an error inside, and if I bit bakes it warns me of a problem.

I guess it must be related to either a defect hardware (but I’ve got no way to be sure), or some interrupt badly configured, as the I2C is working?

Regards,

Matthieu

Hi @ParalaX!

Are you using the Colibri Evaluation Board? If you’re using any other carrier board (such as the Aster), the pin assignment will be different and that may justify why you see no interrupts triggered.

Hi, thanks a lot!

That was indeed the problem…

So everything works great now. Again, thanks a lot for your time and all :slight_smile:

I’ll update later my initial question with my findings, as it will maybe help someone else later.

Regards,

Matthieu

Perfect that it works. Thanks for your feedback.

Best regards,
Jaski