Torizon imx6 COMPATIBLE_MACHINE not set correct

Technical Support
, , ,
1

Hello,

I think the COMPATIBLE_MACHINE for the IMX6 is not correct set for Torizon.
If I add this to the local.conf :

MACHINE = "apalis-imx6"
IMAGE_INSTALL_append  += " imx-gpu-viv"

I get:

Parsing recipes: 100% |###############################################################################################################################################################################################################################################| Time: 0:01:19
Parsing of 2882 .bb files complete (0 cached, 2882 parsed). 4145 targets, 555 skipped, 3 masked, 0 errors.
WARNING: No recipes available for:
  /home/dragon/test_yocto/build-torizon/conf/../../layers/meta-sensgit-imx6-torizon/recipes-kernel/linux/linux-toradex_4.14-2.x.bbappend
NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to PREFERRED_PROVIDERS
NOTE: selecting linux-toradex-mainline to satisfy virtual/kernel due to PREFERRED_PROVIDERS
NOTE: selecting opkg-native to satisfy opkg-native due to PREFERRED_PROVIDERS
NOTE: selecting opkg-utils-native to satisfy virtual/update-alternatives-native due to PREFERRED_PROVIDERS
NOTE: selecting u-boot-toradex to satisfy virtual/bootloader due to PREFERRED_PROVIDERS
NOTE: selecting linux-toradex-mainline to satisfy runtime kernel-modules due to PREFERRED_PROVIDER_virtual/kernel = linux-toradex-mainline
NOTE: selecting networkmanager to satisfy virtual/network-configuration due to PREFERRED_RPROVIDER
NOTE: selecting glibc to satisfy runtime ldd due to PREFERRED_PROVIDER_virtual/libc = glibc
ERROR: Nothing RPROVIDES 'imx-gpu-viv' (but /home/dragon/test_yocto/build-torizon/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-podman.bb RDEPENDS on or otherwise requires it)
imx-gpu-viv was skipped: incompatible with machine apalis-imx6 (not in COMPATIBLE_MACHINE)
imx-gpu-viv was skipped: incompatible with machine apalis-imx6 (not in COMPATIBLE_MACHINE)
NOTE: Runtime target 'imx-gpu-viv' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['imx-gpu-viv']
NOTE: Target 'torizon-core-podman' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['torizon-core-podman', 'imx-gpu-viv']
ERROR: Required build target 'torizon-core-podman' has no buildable providers.
Missing or unbuildable dependency chain was: ['torizon-core-podman', 'imx-gpu-viv']

Summary: There was 1 WARNING message shown.

In the recipe he asked for the (mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)

My goal is to use “eglfs” in Torizon for the imx6, but I think this is a Torizon bug.

How can I set COMPATIBLE_MACHINE in Torizon for the imx6 to mx6q?

Best Regards

2

Greetings @Alias_Alias,

I don’t quite think the COMPATIBLE_MACHINE is actually the problem as the error message states it is. The default top-level machine config that the TorizonCore build uses is here: meta-freescale-3rdparty/apalis-imx6.conf at master · Freescale/meta-freescale-3rdparty · GitHub

As you can see MACHINEOVERRIDES includes mx6q, meaning this should be picked up by the COMPATIBLE_MACHINE check. You can try a sanity check and add apalis-imx6 to the COMPATIBLE_MACHINE variable and see if it truly is a matter of machine incompatibility.

That being said the greater issue here is that I believe there will be more issues with trying to integrate imx-gpu-viv. Since this particular package pulls in a lot of dependencies, which may lead to quite a customization effort.

Another question I have is that if you’re going customize TorizonCore to this extent why not use our non-Torizon BSP? Or is there a feature of Torizon you want to use as well?

Finally there may be a method in which you can get eglfs support in a container on Torizon. You’ll need to download the Boot2Qt easy installer image from here. Then unpack the archive file and grab the rootfs tarball and transfer it to your module.

You should then be able to use docker import on this rootfs tarball to create a Boot2Qt container image. Since this is Boot2Qt it should then have the eglfs support. That being said, this solution is not well-tested and a little hacky.

Let me consult some of my colleagues about this and see if I can get you a better answer here.

Best Regards,
Jeremias

3

Greetings @jeremias.tx,

I think I have made a mistake with the eglfs. One of our most important requirements is that we need a distribution which we can update “over the air”. That’s why we will and must use Torizon.

First let me clarify my goals:

  1. Add a Device-Tree LVDS overlay
  2. Add a Touchscreen-Linux-Driver (TOUCHSCREEN_GOODIX)
  3. Build a container based on the container debian-qt5-wayland with a qt5 application
  4. Setting up a “Developer Tools Container for TorizonCore and qt5 application” for the QT-Creator

My approach here is:

  1. (Add a Device-Tree LVDS overlay ) Use this article as a basic information.
  • I have created this overlay for the BSP3 : my.dts
  • I now have to adapt this device tree to a device tree overlay. Or is it possible to use a whole other device tree in Torizon ?
  • The examples only show how to setup “one” LVDS display. Is there an example for two LVDS displays like in my overlay (my.dts)?
  1. (Touchscreen-Linux-Driver (TOUCHSCREEN_GOODIX) ) I think I have here two options:
  • init torizon yocto / build the sdk (bitbake torizon-core-podman -c populate_sdk) / install and source the SDK / checout torizon kernel / export ARCH=arm / make apalis_imx6_defconfig / make menuconfig ( add the TOUCHSCREEN_GOODIX = y) / copy the zImage to a Torizon-Image / flash the image
  • init torizon yocto / build the sdk (bitbake torizon-core-podman -c populate_sdk) / install and source the SDK / checout torizon kernel / export ARCH=arm / make apalis_imx6_defconfig / make menuconfig ( add the TOUCHSCREEN_GOODIX = m) / copy the kernel-module to the toradex base image / aktivate the module
  • What do you think about the two Options? Is there a better way ?
  1. (container debian-qt5-wayland ) I start here
  • What do I have to change to use the LVDS display?
  1. (Developer Tools Container for TorizonCore and qt5 application) I think I have to start with this.
  • Where is the repository and the dockerfile for this container
  • Can I use this container as a base cross compile container for a container debian-qt5-wayland?
  • Is there a better way to create such Container for QT-Creator ?

Sorry for that long answer, but Torizon and Docker are so new and unusual to the BSP-Style that I have to ask like this.

Best Regards,

Alias_Alias

4

Hi @Alias_Alias,

Let me try and go through your questions one by one here. Also, so does this mean the EGLFS requirement is no longer an issue, or?

I now have to adapt this device tree
to a device tree overlay. Or is it
possible to use a whole other device
tree in Torizon ?

So you can just modify/use a new device tree rather than overlays. For larger changes it is even preferred, as overlays are really meant for minor changes that might make an entire re-compile tedious. On boot Torizon loads the device tree from this location on the filesystem: /boot/ostree/torizon-{some checksum}/. In this directory you can find the kernel and device tree binary files, you need just substitute your own and then reboot the device.

The examples only show how to setup
“one” LVDS display. Is there an
example for two LVDS displays like in
my overlay (my.dts)?

At the moment we don’t have an example of this exact use-case available. But like I stated above you can just use your own device tree rather than creating overlays.

What do you think about the two
Options? Is there a better way ?

So either option here should work, it depends on your use case if you want the driver loadable as a module or not.

Some small notes however. The kernel defconfig for Torizon isn’t available with the kernel source, we actually construct the defconfig during yocto build time from config fragments. As a workaround you can just copy the kernel config from your device at, /proc/zconfig.gz, and use this as your defconfig. Also it’s not necessary to use a yocto-built toolchain for the kernel I’ve found that using the latest toolchain we list here, should suffice.

Finally you can replace the kernel with your own custom kernel using the same method as I’ve mentioned above with the device tree.

What do I have to change to use the
LVDS display?

If I recall correctly I believe the graphical containers display to all connected displays with additional displays extending the current display. So if you just want it to display on LVDS only you can, disable the HDMI in the device tree and only have your LVDS display connected. With that it should use the LVDS as the display and fit properly.

Where is the repository and the
dockerfile for this container

I don’t believe we have the dockerfile for this public yet as it’s meant to be used in conjunction with our IDE extensions, rather than standalone. I can check internally for more info here though.

Can I use this container as a base
cross compile container for a
container debian-qt5-wayland?

You should be able to. I will say for the C/C++ support on our IDE extension (I assume you’re using C for Qt), Visual Studio has this while our Visual Studio Code extension has this support coming soon. So depending on your preferred IDE you may need to wait a bit.

Is there a better way to create such
Container for QT-Creator ?

At the moment we unfortunately don’t have official integration with the Qt Creator IDE. This however is something we’re working towards together with the Qt Company. Though I can’t give any rough dates/roadmaps at the moment about this.

I hope I was able to answer your questions, please let me know if you have any more questions or if I can clarify anything I just said.

Best Regards,
Jeremias

5

Greetings @jeremias.tx,

I will now start to test the device trees. Thanks for that awsome feedback.
I will write to you early next week, If everything is ok or if I’m strugle with some thing.

Best Regards,
Alias_Alias

6

Hi @Alias_Alias

Is everything Ok or do you still have any issues?

Best regards,
Jaski