Build Torizon OS from Source With Yocto Project/OpenEmbedded
Introductionβ
To use Torizon OS without customizing the base image, refer to the Quickstart Guide for instructions on how to install it on your Toradex System-on-Module (SoM).
Before building Torizon OS with Yocto Project/Open Embedded, refer to TorizonCore Builder Overview to understand how the TorizonCore Builder tool can be used to customize a Torizon OS image without working directly with Yocto. This tool, provided by Toradex, simplifies the customization process and may be a more efficient option for many use cases.
Torizon OS, formerly known as TorizonCore, is the base operating system on which Torizon is built. It is a minimal, Yocto Projectβbased embedded Linux image. While most users focus on application development using containers, there are scenarios where customizing the base image becomes necessary to meet specific requirements.
The Toradex manifest repository provides the Repo manifest and setup scripts required for the Torizon OS build system. It is intended for users who need to modify, extend, or port Torizon OS to new hardware platforms. The Torizon OS build system is based on the Yocto Project and uses the OpenEmbedded build system, the BitBake task executor, and various BSP application layers.
This article presents two methods to build Torizon OS:
- Native Linux distribution: build Torizon OS directly on the host machine.
- Not all distribution and Yocto Project version combinations are supported. If the host distribution is not supported, BitBake will display a warning when you run the first
bitbakecommand. In such cases, the distribution may not be suitable for building Torizon OS, and using a Docker container should be considered.
- Not all distribution and Yocto Project version combinations are supported. If the host distribution is not supported, BitBake will display a warning when you run the first
- Docker container: build Torizon OS within a containerized environment
This article complies with the Typographic Conventions for Torizon Documentation.
Common Prerequisitesβ
This section lists the common prerequisites required, regardless of the chosen build method. Read carefully the information below before proceeding with either build option.
Manifest Branchβ
The manifest branch refers to the Git branch of the manifest repository used during setup. The branches in the Toradex Manifest Repository corresponding to Torizon OS versions are listed below:
| Torizon OS version | Branch |
|---|---|
| 7.x.y | scarthgap-7.x.y |
| 6.x.yΒΉ | kirkstone-6.x.y |
| 5.x.yΒΉ | dunfell-5.x.y |
| 0.0.0 | master |
- Versions 6.3.0 and earlier were released with the TorizonCore name.
The master branch is maintained to track changes in external layers. It is not recommended for productization, as builds may be unstable or broken for extended periods.
Manifest Fileβ
The manifest file refers to the specific file in the manifest repository used during setup. The files available for Torizon OS images are:
torizon/default.xmltorizon/integration.xmltorizon/next.xml
Toradex recommends using the torizon/default.xml manifest file, as the other manifest files are used by Toradex to track upcoming changes and may not be stable.
The path to the manifest files changed in Torizon OS 7. Previously, the path was torizoncore/<manifest>.xml, and now it is torizon/<manifest>.xml.
Torizon OS Distroβ
Within the Torizon Cloud ecosystem, formerly known as Torizon Platform, Toradex provides different versions of Torizon OS, which are referred to as "Distros" in the OpenEmbedded community. Each Distro corresponds to a specific kernel base and configuration.
The available Distros for Torizon OS are listed in the table below:
| Distro | Kernel Base | Kernel Config |
|---|---|---|
torizon | Downstream kernel from SoC vendor Default for iMX95, iMX8, AM69/TDA4, AM62 and AM62P based modules | Default Note: without Linux PREEMPT_RT patch |
torizon-upstream | Mainline kernel Default for iMX6 and iMX7 based modules | Default Note: without Linux PREEMPT_RT patch |
torizon-rt | Downstream kernel from SoC vendor | Fully preemptive Note: real-time with Linux PREEMPT_RT patch |
torizon-upstream-rt | Mainline kernel | Fully preemptive Note: real-time with Linux PREEMPT_RT patch |
Machineβ
The supported MACHINE targets refer to the specific hardware platforms for which Torizon OS can be built. Each MACHINE corresponds to a particular Toradex SoM and its associated BSP layers.
The available MACHINE targets for Torizon OS are listed in the table below:
| MACHINE | Corresponding Toradex SoM |
|---|---|
aquila-imx95 | Aquila iMX95 Note: supported on 7.5.0 or newer Torizon OS releases |
aquila-am69 | Aquila AM69/TDA4 |
verdin-imx95 | Verdin iMX95 Note: supported on 7.4.0 or newer Torizon OS releases |
verdin-imx8mp | Verdin iMX8M Plus |
verdin-imx8mm | Verdin iMX8M Mini |
verdin-am62p | Verdin AM62P Note: supported on 7.3.0 or newer Torizon OS releases |
verdin-am62 | Verdin AM62 |
toradex-smarc-imx95 | Toradex SMARC iMX95 Note: supported on 7.3.0 or newer Torizon OS releases |
toradex-smarc-imx8mp | Toradex SMARC iMX8M Plus Note: supported on 7.3.0 or newer Torizon OS releases |
apalis-imx8 | Apalis iMX8 |
apalis-imx6 | Apalis iMX6 |
colibri-imx8x | Colibri iMX8X V1.0C or newer |
colibri-imx7-emmc | Colibri iMX7D 1GB Note: equipped with eMMC flash |
colibri-imx6ull-emmc | Colibri iMX6ULL 1GB Note: equipped with eMMC flash |
colibri-imx6 | Colibri iMX6 |
Torizon OS Imageβ
The supported IMAGE targets refer to the specific Torizon OS images that can be built using the Yocto build system. Each IMAGE corresponds to a particular set of features and configurations for Torizon OS.
The available IMAGE targets for Torizon OS are listed in the table below:
| IMAGE | Description |
|---|---|
torizon-docker | Default image provided by Toradex
|
torizon-minimal | Torizon OS reference minimal image without a container engine Note: all other Torizon OS features are included. Refer to Torizon OS Yocto Reference Minimal Image for more information |
torizon-podman | Experimental image using Podman instead of Docker Note: all Torizon OS features are included |
Native Torizon OS Build Processβ
Prerequisitesβ
- A configured build environment as described in the Host Machine Setup for Building with Yocto documentation
- Read the Build a Reference Image with Yocto Project article
- Read the Custom Meta Layers, Recipes and Images in Yocto Project (hello-world Examples) article
For Secure Boot-enabled builds, refer to Secure Boot on Torizon OS documentation.
Setup Environmentβ
To setup the build environment and download the necessary metadata, follow the instructions below.
-
Make sure that Git user name and e-mail are configured:
$ git config --global user.email "email@email.com"
$ git config --global user.name "Name" -
Download the
repotool:$ mkdir ~/bin
$ PATH=~/bin:$PATH
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo -
Initialize the
repotool to download the manifest repository metadata. Make sure to specify the desired manifest branch and file:$ repo init -u git://git.toradex.com/toradex-manifest.git -b scarthgap-7.x.y -m torizon/default.xmltipFor reproducible builds, Toradex recommends using tagged versions to ensure consistency. If reproducibility is critical for your use case, consider fetching all source code during setup and storing it locally.
-
After a successful initialization, the
repotool will have created a.repodirectory in the current working directory. -
Sync the metadata to download the source code:
$ repo sync --no-clone-bundle -
Additionally, it might be necessary to specify proxy settings when downloading from behind a proxy:
$ export HTTP_PROXY=http://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
$ export HTTPS_PROXY=https://<proxy_user_id>:<proxy_password>@<proxy_server>:<proxy_port>
In some cases, Linux hosts may experience connectivity issues during downloads. Adjusting TCP/IP stack settings and disabling parallel downloads can help mitigate these issues. Root privileges are required to modify TCP settings:
$ sudo sysctl -w net.ipv4.tcp_window_scaling=0
$ repo sync -j1
Configure the Image Buildβ
The default DISTRO variable is automatically set based on the chosen MACHINE. To select a different DISTRO, specify it in the following command:
$ [DISTRO=<DISTRO>] [MACHINE=<MACHINE>] source setup-environment [BUILDDIR]
Build the Imageβ
To build the Torizon OS image, run the following command:
$ bitbake <IMAGE>
If an NXP MACHINE is selected and the ACCEPT_FSL_EULA="1" flag has not been previously added to the conf/local.conf file, a prompt will appear asking whether to review and accept NXPβs EULA. If the EULA is accepted, the flag is automatically added to conf/local.conf. If it is not accepted, the build fails until the EULA is accepted by adding ACCEPT_FSL_EULA="1" to conf/local.conf.
It is possible to accept the EULA automatically and skip the prompt by using the EULA variable in the setup-environment script. The following command will automatically accept NXP's EULA and add ACCEPT_FSL_EULA="1" to conf/local.conf:
$ [DISTRO=<DISTRO>] [MACHINE=<MACHINE>] EULA=1 source setup-environment [BUILDDIR]
Containerized Torizon OS Build Processβ
Prerequisitesβ
- Read the Build a Reference Image with Yocto Project article
- Read the Custom Meta Layers, Recipes and Images in Yocto Project (hello-world Examples) article
- A host machine with Docker installed
Additionally, for Windows hosts, the following prerequisites are required:
- WSL2
- For more information on setting up WSL2, refer to the Configure Build Environment for Torizon Containers documentation
- A suitable WSL2 Linux Distribution
- Ubuntu 18.04 was tested
For Secure Boot-enabled builds, refer to Secure Boot on Torizon OS documentation.
Build Configurationβ
Create a working directory where the Yocto build will be stored:
$ mkdir ~/yocto-workdir
For Windows, Toradex recommends to set up a working directory via WSL2 to handle the Linux filesystem dependencies of OpenEmbedded. This working directory will be used to store the resulting build files on the host machine.
-
Open a Windows command prompt and execute
wslto access the WSL2 Linux distribution -
Setup a folder for storing build files:
$ cd
$ explorer.exe . -
Copy the file path of the desired working directory for later use
Build the Imageβ
If an NXP MACHINE is selected, a prompt to accept the NXP/Freescale EULA appears before the build begins. Acceptance of the EULA is required for certain packages and the build proceeds only after the EULA is accepted.
Run the following docker run command to start the build container. Make sure to update <machine> and <image> flags with the desired MACHINE and IMAGE for the build:
$ docker run --rm -it --name=crops -v ~/yocto-workdir:/workdir --workdir=/workdir -e MACHINE=<machine> -e IMAGE=<image> torizon/crops:scarthgap-7.x.y startup-tdx.sh
After setting up the working directory in WSL2, run the following docker run command from the Windows command prompt. Make sure to update <machine> and <image> flags with the desired MACHINE and IMAGE for the build:
$ docker run --rm -it --name=crops -v \wsl$\Ubuntu\home\coj:/workdir --workdir=/workdir -e MACHINE=<machine> -e IMAGE=<image> torizon/crops:scarthgap-7.x.y startup-tdx.sh
Container Argumentsβ
The docker run commands above include the minimum required arguments to start the build container. Additional arguments can be passed to further configure the build or change its behavior. These arguments are passed as environment variables using the -e flag in docker run:
-e MACHINE=<machine>: Specifies the target machine for the image build. This is required and does not have a default value.-e DISTRO=<distro>: Specifies the Torizon DISTRO to be built. Defaults to eithertorizonortorizon-upstreambased on the chosen MACHINE.-e BRANCH=<branch>: Specifies the manifest repository branch. Defaults toscarthgap-7.x.y.-e MANIFEST=<manifest>: Specifies the manifest file to be used. Defaults totorizon/default.xml.-e IMAGE=<IMAGE>: Specifies the Yocto build recipe to be built. If not provided, the container will set up the build environment and start a shell without initiating a build.
Customizationβ
Enable Graphics Stackβ
Torizon OS releases are headless by default, meaning that graphics-related features are removed at the distribution level. This configuration does not affect the default Torizon OS image and the experimental image using Podman, as the required userspace graphics stack is provided through containerized applications.
For the Torizon OS reference minimal image, graphics support can be enabled to allow the use of the Torizon ecosystem without the Docker engine or containers, while still providing a graphical user interface for embedded applications.
To enable the graphics stack, add the following line to local.conf to revert the removal of Distro features related to Wayland and OpenGL reintroducing graphics support to the built Torizon OS image:
DISTRO_FEATURES_REMOVE:remove = " wayland opengl"
Custom Layersβ
All custom layers in Torizon OS must be version-controlled using Git. This requirement is due to how layer revision information is included with OSTree, which is essential for the system update and over-the-air (OTA) process in Torizon OS.
For more details on how to manage custom layers in Yocto and their integration with Torizon OS, refer to Custom Meta Layers, Recipes and Images in Yocto Project (hello-world Examples) article.
Deploy to Torizon Cloud Using Yoctoβ
Prerequisitesβ
Java must be installed on the host system to deploy a custom image to Torizon Cloud:
$ sudo apt install openjdk-21-jre
Setup Environmentβ
Variables can be configured to automatically push a custom Torizon OS image to a Torizon Cloud account during the Yocto build process. Update the path to the credential.zip file and specify the target hardware in conf/local.conf:
SOTA_PACKED_CREDENTIALS = "<path/to/credential.zip>"
SOTA_HARDWARE_ID = "verdin-imx8mp"
For more information about obtaining Torizon Cloud credentials, refer to How to Get Torizon Cloud credential.zip documentation.
After the build completes, the image is automatically pushed to the Torizon Cloud account and can be viewed in the Recent Packages tab.
Deploy to Torizon Cloud Using TorizonCore Builderβ
To deploy a custom image to Torizon Cloud, ensure the following requirements must be met:
- The OSTree and Aktualizr components remain unchanged in the Yocto build configuration, as they are responsible for system updates and the over-the-air (OTA) update mechanism in Torizon OS.
Build the image using Yocto and generate the output in the Toradex Easy Installer format. The build system stores the built image in the deploy/images/<machine> directory and includes the string Tezi in the file name. Then, use the TorizonCore Builder Tool to unpack the image and push it to Torizon Cloud.
Refer to the article Signing and Pushing Torizon OS and Application Packages to Torizon Cloud for more information about this process.
When building a custom Torizon OS image, users are totally responsible for regularly building and deploying updates to ensure the security and functionality of their devices.