Compiling OpenEmbeded V2.7b3

Hi,
I have this hardware configuration:
Colibri IMX7S module, Aster carier board and Fusion 7" multi-touch display

My developing machine is Ubuntu 16.04 64 bit.

I want to make some software with QT creator, so I need to compile:
meta-toolchain-qt5, angstrom-qt5-x11-image and device tree for Fusion 7" multi-touch display

I follow this instructions:

But the problem is that these instructions are very confusing!
I try to do it one week but I am not successful. So now I delete everything and I want start again. I like to make clarification of which steps in this manuals I have to do and which not.

By the way, why you guys do not providing the most using targets to download already compiled?

It is possible to customize device three directly in OpenEmbeded or it is nessesary build it separatly from linux kernel source code?

Regards,
Peter.

But the problem is that these instructions are very confusing! I try to do it one week but I am not successful. So now I delete everything and I want start again. I like to make clarification of which steps in this manuals I have to do and which not.

You would need to be slightly more specific if you expect us to help you in any way.

By the way, why you guys do not providing the most using targets to download already compiled?

What exactly do you mean by “most using targets”? There are about a zillion of possibilities and I am really sorry that our binary demo images are not exactly adhering to your particular requirements.

It is possible to customize device three directly in OpenEmbeded or it is nessesary build it separatly from linux kernel source code?

Of course it is possible to customise the device tree directly from within OpenEmbedded e.g. by appending resp. Linux kernel recipe and patching the same.

Hi, I was start building of “meta-toolchain-qt5” again and now I am waiting for result…

Do I need to add line PACKAGECONFIG_FONTS_append_pn-qtbase = " fontconfig" into “local.conf” file if I want to build target “angstrom-qt5-x11-image”?

Do I need to have this line added If I want to compile only SDK “meta-toolchain-qt5”?

What I have to do if I decide to cancel building, then change something in “local.conf (like fontconfig)” and then start building again. Do I have to delete something or run some “clean” script?

I am not sure which SDK I need. I need QT library, touch screen, low-level GPIO functions and communicate with second M4 core. Do I need “bitbake -k meta-toolchain-qt5” or “bitbake angstrom-qt5-x11-image -c populate_sdk”? What is difference between them?

You do need PACKAGECONFIG_FONTS_append_pn-qtbase = " fontconfig" if you want additional fonts support in Qt5, no matter which recipe you build.

In my experience, it is pretty safe to cancel bitbake. I would recommend cancel it only with a single Ctrl+C, since in that case it can safely end the task it is currently running. If you press Ctrl+C twice, then the task gets aborted, which is problematic for some tasks (usually double Ctrl+C is even fine if only download/compile tasks are running).

Not sure what you mean with low-level GPIO access. Linux manages GPIOs in the OS kernel, the user space access is through sysfs exclusively (with Linux 4.1). The sysfs GPIO access is file based and there is no need for a library. However, you can use a user space library such as libsoc (see also Using GPIO from Qt-Application - Technical Support - Toradex Community).

The meta-toolchain-qt5 comes from meta-qt5. It gives you a complete Qt5 toolchain, but not with additional packages which might be required for your image… Whereas if you use bitbake angstrom-qt5-x11-image -c populate_sdk, it generates a Qt5 toolchain with all packages included in the image (plus Qt5 toolchain support thanks to inherit statement in the image recipe).

I can tell that while building angstrom=lxde-target without and with Qt5, both times my bitbake failed. There are quite a few bugs in Morty, and one I found is actually building the package “fontconfig” (in …/meta/recipes-graphics/ directory).

I found a workaround: I introduced Pyro’s fontconfig package (2.12.4 from main stream), swapping Morty’s fontconfig 2.12.1 (I guess this is also generic one).

Here is a full transcript, so you can observe better:

[user@localhost /]$ cd ~/toradex/Qt5-plus-x11/oe-core/layers/openembedded-core/meta/recipes-graphics/
[user@localhost recipes-graphics]$ ls -al
total 192
drwxrwxr-x. 48 user user 4096 Sep  4 21:11 .
drwxrwxr-x. 20 user user 4096 Sep  4 21:01 ..
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 builder
drwxrwxr-x.  2 user user 4096 Sep  4 21:01 cairo
drwxrwxr-x.  2 user user 4096 Sep  4 21:01 cantarell-fonts
drwxrwxr-x.  4 user user 4096 Sep  4 21:01 clutter
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 cogl
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 drm
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 eglinfo
drwxrwxr-x.  3 user user 4096 Aug 28 13:35 fontconfig <<========================
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 fontconfig_2.12.1 <<=================
drwxrwxr-x.  3 user user 4096 Sep  4 21:01 freetype
.
. [snap]
.
drwxrwxr-x.  2 user user 4096 Sep  4 21:01 xorg-util
drwxrwxr-x.  4 user user 4096 Sep  4 21:01 xorg-xserver
drwxrwxr-x.  2 user user 4096 Sep  4 21:01 xrestop
drwxrwxr-x.  2 user user 4096 Sep  4 21:01 xvideo-tests
[user@localhost recipes-graphics]$ ls -al fontconfig
total 16
drwxrwxr-x.  3 user user 4096 Aug 28 13:35 .
drwxrwxr-x. 48 user user 4096 Sep  4 21:11 ..
drwxrwxr-x.  2 user user 4096 Aug 28 13:35 fontconfig
-rw-rw-r--.  1 user user 2245 Aug 28 13:35 fontconfig_2.12.4.bb
[user@localhost recipes-graphics]$ 

This then compiled, and produced very good load.

My two cent worth advise.
nobody

I can assure you that @nobody else run into that issue so far.

No clue, Marcel.tx, why? I actually use as host Fedora 26 x86_64 bare metal. This fontconfig 2.12.1 package always comes to me to bite me back… But this solution (fontconfig 2.12.4) I somehow invented out of desperation as workaround works for me.

nobody

Yup. Correct.

[user@localhost ~]$ uname -a
Linux localhost.localdomain 4.12.12-300.fc26.x86_64 #1 SMP Mon Sep 11 17:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[user@localhost ~]$ gcc --version
gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[user@localhost ~]$ 

But I made target system with Qt5 support for TORADEX Colibri iMX6 using Fedora 26. No any containers, but there are few workarounds. Well… Anyway, I am too lazy to revert to F25, since I use Fedora 26 since March 2017.

nobody

Thanks but we really do not support any such configuration, I’m sorry.

https://fedoraproject.org/wiki/Releases/27/Schedule

Fedora 27 is due on October 24, 2017. Fedora 25 will be abandoned (by Fedora support and community) exactly a month later. Do these dates clearly speak for themselves, don’t they? :wink:

nobody

We clearly state that @nobody would need to use a lightweight container to build the same in such a configuration. However if you do like solving issues like the one described please consider doing so with the help of whoever.

Not really sure why using the lightweight container should be a requirement while building YOCTO???

Just in contrary, should be not, IMHO!

Thank you,
nobody

It is not a requirement if you use the supported Distro version. Yocto and OpenEmbedded always only supported a subset of Distro/Version to build. This is the list of supported distributions for the Morty/2.2 release:

http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#detailed-supported-distros

Now since you are not running a supported version, these days it is a industry best practice to just use a container which runs the supported distribution on your Fedora installation… It is not a requirement, it is a work around which allows to easily fulfill the requirement…

YES, now I got the idea after Stefan’s answer. It is obvious to me that container should NOT be a host requirement, but I wanted to see the answers (to judge the knowledge of TORADEX support). :wink:

It is now clear to me. TORADEX does not plan to move beyond Fedora 25, for Morty development/set up.

Upon introducing Rocko, Fedora 26 will be introduced for it, following (probably) YOCTO Project recommendations.

In other words: two YOCTO releases (Morty, Rocko), two host (F25, F26) strategies!

(regarding host Fedora, I do my own magic, and I really appreciate and value TORADEX support to me on that one)

nobody

Fedora 26 uses GCC 7.1.1 and is not currently supported by our BSP. You can try running lightweight Linux container with Fedora 24 or 25, and compiling within it.