TEZI compatible image build problem using Yocto/BSP

Hello! I’m trying to build reference image tdx-reference-multimedia-image using instructions from here for Colibri iMX6 Solo 256MB module v1.1 with Colibri Eval board. I try to build using BSP 5.7.0.
TEZI compatible image should build by default without any specific additions to local.conf file as I can understand. But bitbake build and deploy only zImage, dtb, rootfs tar …etc files and no image.json, device tree overlays and other files like in downloadable reference images.
I find instructions here to create custom visual of TEZI compatible image and add to my local.conf IMAGE_CLASSES_append = " image_type_tezi" . After that in deploy dir creates overlays dir and added files from tezi-metadata_0.3.bb but no image.json or full TEZI tar image.

  1. Where should I look to solve this problem?
  2. How can I understand that image_type_tezi.bbclass fully used in bitbake build?
  3. Is any problem if I build image using kas-container?


Hi @parus247,

Welcome to our community :rocket: ! Please feel free to roam around and explore.

This is indeed the right place to search.

I just did a clean build for the Colibri iMX6 with Yocto and I got the following structure on the deploy folder:

➜  images tree -L 2 | grep Tezi 
    ├── Colibri-iMX6_Reference-Multimedia-Image-Tezi_5.7.0-devel-20220808122045+build.0.tar
    ├── Verdin-iMX8MM_Reference-Multimedia-Image-Tezi_5.7.0-devel-20220728134551+build.0.tar

You can see that I have a build for the Verdin iMX8MM and another one for the Colibri iMX6 and both have a file called Module_Reference-Multimedia-Image-Tezi_BSPVERSION-Buildversion.tar. This is the file that you can use to flash your image on Toradex Easy Installer. If you extract the files on this tarball you can find an structure as such:

➜  Colibri-iMX6_Reference-Multimedia-Image-Tezi_5.7.0-devel-20220808122045+build.0 tree -L 1            
├── image.json
├── LA_OPT_NXP_SW.html
├── marketing.tar
├── prepare.sh
├── Reference-Multimedia-Image-colibri-imx6.bootfs.tar.xz
├── Reference-Multimedia-Image-colibri-imx6.tar.xz
├── SPL
├── toradexlinux.png
├── u-boot.img
├── u-boot-initial-env-spl
└── wrapup.sh

And it will have all the files needed for TEZI. If you do a clean build without any custom Tezi modification do you have a similar file? I could get this with the following local.conf:

# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at local.conf.extended
# which contains other examples of configuration which can be placed in this file
# but new users likely won't need any of them initially.
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

# Machine Selection
# You need to select a specific machine to target the build with. These are the
# machines which target the Toradex Apalis, Colibri and Verdin computer on
# module families:
#MACHINE ?= "apalis-imx6"
#MACHINE ?= "apalis-imx8"
#MACHINE ?= "apalis-tk1"
MACHINE ?= "colibri-imx6"
#MACHINE ?= "colibri-imx6ull"
#MACHINE ?= "colibri-imx6ull-emmc"
#MACHINE ?= "colibri-imx7"
#MACHINE ?= "colibri-imx7"
#MACHINE ?= "colibri-imx7-emmc"
#MACHINE ?= "colibri-imx8x"
#MACHINE ?= "verdin-imx8mm"
#MACHINE ?= "verdin-imx8mp"
# There are also a selection of emulated machines available which can boot and run
# in the QEMU emulator:
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"

# Where to place downloads
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
# The default is a downloads directory under TOPDIR which is the build directory.
DL_DIR ?= "/home/yocto/yp-downloads"

# Where to place shared-state files
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
# The default is a sstate-cache directory under TOPDIR.
SSTATE_DIR ?= "/home/yocto/yp-sstatecache"

# Where to place the build output
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
# The default is a tmp directory under TOPDIR.
#TMPDIR = "${TOPDIR}/tmp"

# Where to place images and sw packages
# This places the build output in parallel to build and layers thus
# if you have several build directories you need to adjust deploy
# to something unique, e.g. "${TOPDIR}/../deploy_fb" "${TOPDIR}/../deploy_x11"
DEPLOY_DIR = "${TOPDIR}/deploy"

# Package Management configuration
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
#  - 'package_deb' for debian style deb files
#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
#  - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to ipk:
PACKAGE_CLASSES ?= "package_ipk"

# SDK target architecture
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"

# Extra image configuration defaults
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
#  "dbg-pkgs"       - add -dbg packages for all installed packages
#                     (adds symbol information for debugging/profiling)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "dev-pkgs"       - add -dev packages for all installed packages
#                     (useful if you want to develop against libs in the image)
#  "ptest-pkgs"     - add -ptest packages for all ptest-enabled packages
#                     (useful if you want to run the package test suites)
#  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
#  "tools-debug"    - add debugging tools (gdb, strace)
#  "eclipse-debug"  - add Eclipse remote debugging support
#  "tools-profile"  - add profiling tools (oprofile, lttng, valgrind)
#  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
#  "debug-tweaks"   - make an image suitable for development
#                     e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
# package-management deploys the package meta data of deployed packeges
EXTRA_IMAGE_FEATURES ?= "debug-tweaks package-management"

# Additional image features
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
#   - 'buildstats' collect build statistics
#   - 'image-mklibs' to reduce shared library files size for an image
#   - 'image-prelink' in order to prelink the filesystem image
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"

# Runtime testing of images
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "1"

# Interactive shell configuration
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):

# Disk Space Monitoring during the build
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necesary to monitor /tmp, if there is no space left the build will fail
# with very exotic errors.
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \

# Shared-state files from other locations
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"

# Qemu configuration
# By default qemu will build with a builtin VNC server where graphical output can be
# seen. The two lines below enable the SDL backend too. By default libsdl2-native will
# be built, if you want to use your host's libSDL instead of the minimal libsdl built
# by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
#ASSUME_PROVIDED += "libsdl2-native"

# Hash Equivalence
# Enable support for automatically running a local hash equivalence server and
# instruct bitbake to use a hash equivalence aware signature generator. Hash
# equivalence improves reuse of sstate by detecting when a given sstate
# artifact can be reused as equivalent, even if the current task hash doesn't
# match the one that generated the artifact.
# A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
#BB_HASHSERVE = "auto"

# Toradex fitImage support (For EMMC modules)
# To enable fitimage, uncomment the following two lines
# KERNEL_CLASSES_append = " toradex-fitimage"
# KERNEL_IMAGETYPE_forcevariable = "${@'zImage' if d.getVar('TORADEX_FLASH_TYPE') == 'rawnand' else 'fitImage'}"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.

# Delete the the source/object/binary files once a package is built to preserve disk space
INHERIT += "rm_work"

# Add Toradex bbclasses
INHERIT += "toradex-mirrors toradex-sanity"

# Use this distro by default
DISTRO ?= "tdx-xwayland"

# Don't generate the mirror tarball for SCM repos, the snapshot is enough

#MACHINEOVERRIDES =. "default-nxp-proprietary-driver:"
#NXP_PROPRIETARY_DRIVER_LOCATION = "file:///home/yocto/yp-downloads"

# This file does not need to exist, if it does it can be used to influence machine specific
# configurations without copying the machine file.
include conf/machine/include/${MACHINE}.inc


Also, this is my Yocto build system file structure:

 Yocto tree -L 1
├── build
├── export
├── layers
├── yp-downloads
└── yp-sstatecache

About your points:

Please confirm the information above, you should have it by default.

You may find more details on the class itself. Did you check this file: image_type_tezi.bbclass « classes - meta-toradex-bsp-common.git - Toradex BSP layer, recipes common to all modules ?

We do have customers using kas, so you could use it if you think it suits you better.

Please tell us if this answer helps you :smiley:

Best regards,

Hello @gclaudino.tx . Thank you for your attention to newbie)

I’m try to build reference image using kas-container. I used this article for instruction. It is for Verdin iMX8M Plus, but I was thought colibri-imx6 should work fine too.
My kas-container yml config file:

Kas generate next local.conf file:

When kas-container finishes build reference image, I see next files in deploy dir without TEZI tar image:

I think that problem in kas-container config of local.conf. It generate MACHINE ??= "colibri-imx6" config going after include conf/machine/include/${MACHINE}.inc It’s single difference.
I can’t find simple way to config kas-container yml to get MACHINE config higher than include. It’s always generate it in the end of local.conf. I write a question in kas-devel@googlegroups.com.

So, I get TEZI compaible reference image as expected after clean build with repo on Ubuntu 20.04 LTS.

Thank you for your help and time!

Hi @parus247 !

Thanks for the update and tagging the post as solved and for sharing your final configuration. Unfortunately, there is not much information on Toradex Side about Kas so as you’ve done you’d probably need to go for other guides to it.

For this, you may also want to contact one of our partners for software development. You can find some of them here: Embedded Computing | Hardware & Software Service Partners

Also, please feel free to come back anytime in the future :smiley:

Best regards,

Hello @gclaudino.tx

I have an answer from kas developer:

My question is why " include conf/machine/include/${MACHINE}.inc " defined in local.conf ?

Hi @parus247,

This configuration is made because some of the machine configurations made by us have a .inc format instead of a .conf like one would expect nowadays. We’re migrating some files but it will need to stay like this for a while.

What you could also do is use a container with crops as it’s used by some of our other FAE’s if you’re not able to contour this using kas.

Here you can find a sample dockerfile:

/home/prjs/yocto/build$ cat Dockerfile 
FROM crops/poky

USER root

RUN apt-get update && apt-get install --no-install-recommends --no-install-suggests -y \
    repo default-jdk \
    && dpkg --add-architecture i386 \
    && apt-get update \
    && apt-get install libpolkit-gobject-1-dev:i386 libglib2.0-dev-bin:i386 g++-multilib libssl-dev:i386 libcrypto++-dev:i386 zlib1g-dev:i386 python3-distutils -y \
    && apt-get autoremove -y \
    && apt-get purge -y --auto-remove \
    && rm -rf /var/lib/apt/lists/*
USER usersetup

Best regards,

1 Like