Toradex Apalis i.MX8

The official Mender documentation explains how Mender works. This is simply a board-specific complement to the official documentation.

Board description

The Apalis i.MX8 is a System on Module based on the NXP® i.MX 8 family of embedded System on Chips (SoCs). The i.MX 8 series of applications processors, part of the EdgeVerse™ edge computing platform, is a feature- and performance-scalable multicore platform that includes single-, dual- and quad-core families based on the Arm Cortex architecture—including combined Cortex-A72 + Cortex-A53, Cortex-A35, Cortex-M4 and Cortex M7-based solutions for advanced graphics, imaging, machine vision, audio, voice, video and safety-critical applications.

URL: NXP i.MX 8QM Computer on Module - Apalis iMX8
Wiki: Apalis iMX8 | Toradex Developer Center

Test results

The Yocto Project releases in the table below have been tested by the Mender community. Please update it if you have tested this integration on other Yocto Project releases:

Yocto Project Build Runtime
dunfell (Yocto 3.1 / Toradex BSP 5.3.0) :test_works: :test_works:
dunfell (Yocto 3.1 / Toradex BSP 5.4.0) :test_works: :test_works:

Build Means that the Yocto Project build using this Mender integration completes without errors and outputs images.
Runtime Means that Mender has been verified to work on the board. For U-Boot-based boards, the integration checklist has been verified.

Getting started


  • A supported Linux distribution and dependencies installed on your workstation/laptop as described in the Yocto Mega Manual
    • NOTE. Instructions depend on which Yocto version you intend to use.
  • Google repo tool installed and in your PATH .

Configuring the build

Setup Yocto environment

Set the Yocto Project branch you are building for:

Create a directory for your mender-toradex setup to live in and clone the
meta information.

mkdir mender-toradex && cd mender-toradex

Select the appropriate Toradex BSP version:


Initialize repo manifest:

repo init -u git:// \
    -b refs/tags/${TORADEX_BSP_VERSION} \
    -m tdxref/default.xml

Download mender manifest:

wget --directory-prefix .repo/local_manifests \

Fetch layers in manifest:

repo sync -j$(nproc)
cd .repo/local_manifests/
ln -sf ../../layers/meta-mender-community/scripts/mender-no-setup-layers.xml .
cd ../..

Setup build environment

Initialize the build environment:

. export

Add Mender layers:

bitbake-layers add-layer $(pwd)/../layers/meta-mender/meta-mender-core/
bitbake-layers add-layer $(pwd)/../layers/meta-mender-community/meta-mender-toradex-nxp/

Add optional Mender demo layer:

# Omit this, if you intend to use this build in production
bitbake-layers add-layer $(pwd)/../layers/meta-mender/meta-mender-demo/

Apply Mender configuration to build environment:

cat ../layers/meta-mender-community/templates/local.conf.append >> conf/local.conf
cat ../layers/meta-mender-community/meta-mender-toradex-nxp/templates/local.conf.append  >> conf/local.conf
echo "TORADEX_BSP_VERSION = \"toradex-bsp-${TORADEX_BSP_VERSION}\"" >> conf/local.conf

NOTE! You need to accept the Freescale EULA at ‘…/sources/meta-freescale/EULA’. Please read it and in case you accept it, add:


in your local.conf.

Configure Mender server URL (optional)

This section is not required for a successful build but images that are generated by default are only suitable for usage with the Mender client in Standalone deployments, due to lack of server configuration.

You can edit the conf/local.conf file to provide your Mender server configuration, ensuring the generated images and Mender Artifacts are connecting to the Mender server that you are using. There should already be a commented section in the generated conf/local.conf file and you can simply uncomment the relevant configuration options and assign appropriate values to them.

Build for Hosted Mender:

# To get your tenant token:
#    - log in to
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
MENDER_TENANT_TOKEN = "<copy token here>"

Building the image

You can now proceed with building an image:

MACHINE=apalis-imx8 bitbake tdx-reference-minimal-image

Replace tdx-reference-minimal-image with your desired image target.

Using the build output

After a successful build, the images and build artifacts are:

  • deploy/images/apalis-imx8/Apalis-iMX8_Reference-Minimal-Image.mender
  • deploy/images/apalis-imx8/Apalis-iMX8_Reference-Minimal-Image.mender_tezi.tar

The .mender_tezi.tar is used to provision the device storage for devices without Mender running already, and is compatible with the Toradex Easy Installer.

On the other hand, if you already have Mender running on your device and want to deploy a rootfs update using this build, you should use the Mender Artifact files, which have .mender suffix. You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client only in Standalone deployments.

Flash instructions

Refer to the Toradex Easy Installer instructions for more details.

If this post was useful to you, please press like, or leave a thank you note to the contributor who put valuable time into this and made it available to you. It will be much appreciated!

1 Like

Hi, my product is using Apalis iMX8 but we defined a new MACHINE for it (instead of using the default “apalis_imx8”) because we are using a custom-built carrier board instead of the evaluation board. In this case, can I still leverage the board integration codes that you have developed?

Looking at the local.conf append file in meta-mender-community, those variables for Apalis iMX8 contain a “_apalis-imx8” suffix, so it seems to me that it only works if my MACHINE is “apalis_imx8”. Is my understanding accurate?

Hi @karhin

With the code currently implemented that is correct. One possibility would be to add a separate override to indicate that your machine is an Apalis iMX8. Something like


may work. But I am curious why you felt the need to use a custom machine for a different carrier board? We normally use the same MACHINE with a different device tree overlay to modify the settings for the carrier board. What features in your setup require a custom MACHINE? Maybe I can suggest an alternative.


1 Like

Hi @drewmoseley,

Thank you so much for your prompt response.

But I am curious why you felt the need to use a custom machine for a different carrier board?

Reason is because we are creating our own dtb (instead of using overlay on top of the eval board DT), but the “apalis-imx8” machine conf file was specifying to use the eval board dtb. So we thought we shall define a new custom MACHINE as long as we are creating a new dtb.
Thinking further, perhaps we shall just create an append file to overwrite the device tree setting (KERNEL_DEVICETREE) in apalis-imx8 machine .conf file?

Yeah, I think that is probably the easiest. I guess I misspoke with I said we use overlays for carrier boards; we actually use separate DTBs but the same MACHINE for carrier boards.


1 Like

I have a Toradex Colibri IMX8XQXP. Would the process for getting that to work be similar ?

Probably so. I don’t believe there is anything unique about the colibri-imx8, just needs someone to do the work.