Linux BSP 2.8 & Qt problem

Hi all,

lately I followed guidelines in:

https://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux

and ALL related guidelines in order to have a 2.8 BSP supporting Qt for my Colibri T20 EVM target.

Apparently at last all installation procedures were duly fulfilled…

I got an Colibri-T20_LXDE-Image_2.8.1 directory with the update.sh script aimed to updated my 2.3 BSP
EVM target (N.B. a problem I already signalled is pending).

But now I figured out that even no sources of the kernel and U-boot are present under /opt/oe-core of my
Linux Fedora 27 software development PC.

Where can I find them ?

Of course I would like to get the kernel sources actually supporting Qt, which I believed to be available
after so long a procedure.

Thank you for your attention.

I’m not exactly sure why you would expect what exactly to be found where exactly. However as the U-Boot boot loader and/or Linux kernel have precious little too do with the details of your user space configuration (e.g. you running Qt rather than LXDE) I don’t see why resp. SDK would include any such sources. For a discussion about compiling resp. parts incl. where exactly to find resp. sources please have a look at the following article on our developer website.

Thank you for your prompt response.

I believed that U-boot and kernel sources should be available because on related guideline

https://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)

I found:

For our Linux image starting from V2.0 we use OpenEmbedded core. Layers from git.toradex.com are used together with a number of other layers.

oe-core installation and configuration (and the later build) will setup the following directory structure

oe-core/
±- build
¦ ±- conf
¦ ±- downloads
¦ ±- tmp-glibc
¦ ±- sstate-cache
±- deploy
±- layers
±- meta-angstrom
±- meta-browser
(… other layers)
±- openembedded-core

… under the ‘build’ tree is the configuration of what is to be built,
the downloaded sources …

Moreover as the update.sh utility actually can update u-boot and kernel as well on EVM, I took for granted that u-boot and kernel sources should be available, in order to patch them for our custom board and update them again…

Anyway from your argumentation I understand that Qt support on EVM is confined to user space, than to Root File System only…Have I to use the Root File System I find say in Colibri-T20_LXDE-Image_2.8.1/rootfs ?

Thank you in advance.

Thank you for your prompt response.

You are very welcome.

I believed that U-boot and kernel sources should be available because on related guideline

https://developer.toradex.com/knowledge-base/board-support-package/openembedded-(core)

I found:

For our Linux image starting from V2.0 we use OpenEmbedded core. Layers from git.toradex.com are used together with a number of other layers.

oe-core installation and configuration (and the later build) will setup the following directory structure

oe-core/ ±- build ¦ ±- conf ¦ ±- downloads ¦ ±- tmp-glibc ¦ ±- sstate-cache ±- deploy ±- layers ±- meta-angstrom ±- meta-browser (… other layers) ±- openembedded-core

… under the ‘build’ tree is the configuration of what is to be built, the downloaded sources …

No, not really. OE is a build system based on recipes. Each and every one of them downloads stuff, does it’s thing (e.g. configure/compile whatever) and then removes it again unless rm_work is removed from your local.conf.

Moreover as the update.sh utility actually can update u-boot and kernel as well on EVM, I took for granted that u-boot and kernel sources should be available, in order to patch them for our custom board and update them again…

No, update.sh just installs whatever is already available built as binary, no sources involved at all.

Anyway from your argumentation I understand that Qt support on EVM is confined to user space,

No, any Qt support is purely user space and has nothing directly to do with any boot loader and/or kernel.

than to Root File System only…Have I to use the Root File System I find say in Colibri-T20_LXDE-Image_2.8.1/rootfs ?

Sorry, but I really do NOT understand at all what exactly it is that you are trying to achieve but I doubt your current understanding of how things work in OE is quite accurate. What exactly is it that you want to do with those sources and why exactly can’t you just take those from where I already pointed you to before?

Thank you for your clarifications.

About…

Sorry, but I really do NOT understand at all what exactly it is that you are trying to achieve but I doubt your current understanding of how things work in OE is quite accurate. What exactly is it that you want to do with those sources and why exactly can’t you just take those from where I already pointed you to before?

Sure I will take the sources where you pointed to…

I am accustomed to it: for our custom Colibri T20 based board once I retrieved V2.3 and successfully modified U-boot,kernel and Root File System according to our specifications…

Please believe me that my “expectations” about sources rely on the crosscorrelation of the amount of guidelines aimed to add Qt support to T20 Linux environment…but this is not point.

Please explain me at last…
Where - if any exists - in the target Linux environment is the “support” and “interface” towards the software development PC running qtcreator ?

I long for your clarification…

Thank you in advance for your patience.

Please explain me at last… Where - if any exists - in the target Linux environment is the “support” and “interface” towards the software development PC running qtcreator ?

I don’t know, if i understand you correct. Are you looking an api or interface documentation? Usually you create an bsp image with including qt layer and copy this to the module. Then you create your qt application on the host and deploy it to the module. This is the whole procedure to run your QT Application on the module.

At last all is explained.
Thank you all for your patient and prompt support

you are welcome. Enjoy creating QT applications on toradex modules.