Debian Containers for Torizon
Introduction
Toradex provides a set of lightweight, Debian-based Docker container images for Torizon, derived from the Debian Slim Image variant of the current Debian stable release. These containers serve as foundations for application development on Torizon, offering a hierarchy of images with minimal installed packages and disabled manual pages.
While you can use any container, Toradex’s containers simplify tasks such as:
- Running graphical applications.
- Accessing specific hardware features like GPU and VPU.
- Utilizing maintained images tested for specific modules.
- Operating without running as root by default.
The container offerings include:
- Console-only base container.
- Container with a modern Wayland-based Weston compositor.
- Qt-Wayland-based container supporting common Qt backends like Wayland and EGLFS.
- Chromium and Cog-based containers for displaying web content and single-page applications.
- .NET Containers for both Console and GUI applications.
- Containers containing Cross-Compilers.
- Containers to test products during the hardware bring-up phase.
Each container builds upon the previous one, adding more features to closely match the minimal dependencies of various applications. Being Debian-based, they allow further package installation using the apt command as required by user applications. The container images are freely available on Docker Hub. These containers are also used as a base when using the templates from the Torizon IDE extension.
This article complies with the Typographic Conventions for Torizon Documentation.
Platform-specific Torizon Debian Containers
We support variations of the same container images for each of the SoC families present in the Toradex portfolio. This is due to the specific userspace libraries needed to properly make use of the vendor-maintained kernels.
Each SoC-specific container will have the SoC family name in the container name, following the <container-registry-user>/<container-name>-<soc-platform-name>:<tag> format. For example, the container responsible for the Wayland-based Weston compositor for the AM62 SoC for the major 4 release is torizon/weston-am62:4. Another example is the console-only base Debian image for the i.MX8 platform, named torizon/debian-imx8:4.
Additionally, we provide containers that don't have a platform specifier appended to the image names (using the previous example, this image would be just torizon/weston). These images are used when the upstream kernel is selected to be shipped with Torizon OS (for the i.MX6 and i.MX7 families, for example).
Each SoC-specific container family has a custom Debian package feed maintained by Toradex, with the packages themselves being attested from our GitHub builds under the torizon organization.
Note that the same packages might have different versions across platforms. For example, on Torizon OS 7, we ship Weston 12 for iMX8 devices while shipping Weston 10 for the iMX6 and iMX7. In general, the strategy is to cover our test suite and not break use-cases during a major release. For platforms that heavily rely on non-upstreamed forks such as iMX8, the strategy is to ship the same versions of key userspace applications that one would get if using Yocto. There is no list of these 'key' applications, but in general, these are applications that require special code to make use of hardware-specific features, such as GPU acceleration, such as Weston, OpenCV, Chromium, etc.
Container Version Matrix
A list of all the currently supported platforms and each container for a given platform follows:
Platform: am62
| Name | Major |
|---|---|
| debian-am62 | 4 |
| wayland-base-am62 | 4 |
| wayland-base-dev-am62 | 4 |
| wayland-gtk3-am62 | 4 |
| weston-am62 | 4 |
| qt5-wayland-am62 | 4 |
| qt5-wayland-examples-am62 | 4 |
| qt6-wayland-am62 | 4 |
| qt6-wayland-examples-am62 | 4 |
| qt6-wayland-tests-am62 | 4 |
| graphics-tests-am62 | 4 |
| chromium-am62 | 4 |
| cog-am62 | 4 |
| dotnet8-am62 | 4 |
| aspdotnet8-am62 | 4 |
| dotnet8-wayland-am62 | 4 |
| dotnet8-gtk3-am62 | 4 |
Platform: am62p
| Name | Major |
|---|---|
| debian-am62p | 4 |
| wayland-base-am62p | 4 |
| wayland-base-dev-am62p | 4 |
| wayland-gtk3-am62p | 4 |
| weston-am62p | 4 |
| qt5-wayland-am62p | 4 |
| qt5-wayland-examples-am62p | 4 |
| qt6-wayland-am62p | 4 |
| qt6-wayland-examples-am62p | 4 |
| qt6-wayland-tests-am62p | 4 |
| graphics-tests-am62p | 4 |
| chromium-am62p | 4 |
| cog-am62p | 4 |
| dotnet8-am62p | 4 |
| aspdotnet8-am62p | 4 |
| dotnet8-wayland-am62p | 4 |
| dotnet8-gtk3-am62p | 4 |
Platform: imx8
| Name | Major |
|---|---|
| cross-toolchain-arm64-imx8 | 4 |
| debian-imx8 | 4 |
| wayland-base-imx8 | 4 |
| wayland-base-dev-imx8 | 4 |
| wayland-gtk3-imx8 | 4 |
| weston-imx8 | 4 |
| qt5-wayland-imx8 | 4 |
| qt5-wayland-examples-imx8 | 4 |
| qt6-wayland-imx8 | 4 |
| qt6-wayland-examples-imx8 | 4 |
| qt6-wayland-tests-imx8 | 4 |
| qt6-enterprise-demo-imx8 | 4 |
| weston-touch-calibrator-imx8 | 4 |
| graphics-tests-imx8 | 4 |
| chromium-imx8 | 4 |
| cog-imx8 | 4 |
| dotnet8-imx8 | 4 |
| aspdotnet8-imx8 | 4 |
| dotnet8-wayland-imx8 | 4 |
| dotnet8-gtk3-imx8 | 4 |
Platform: imx95
| Name | Major |
|---|---|
| debian-imx95 | 4 |
| wayland-base-imx95 | 4 |
| wayland-base-dev-imx95 | 4 |
| wayland-gtk3-imx95 | 4 |
| weston-imx95 | 4 |
| qt5-wayland-imx95 | 4 |
| qt5-wayland-examples-imx95 | 4 |
| qt6-wayland-imx95 | 4 |
| qt6-wayland-examples-imx95 | 4 |
| qt6-wayland-tests-imx95 | 4 |
| weston-touch-calibrator-imx95 | 4 |
| graphics-tests-imx95 | 4 |
| chromium-imx95 | 4 |
| cog-imx95 | 4 |
| dotnet8-imx95 | 4 |
| aspdotnet8-imx95 | 4 |
| dotnet8-wayland-imx95 | 4 |
| dotnet8-gtk3-imx95 | 4 |
Platform: upstream (note the lack of -<platform> in this case)
| Name | Major |
|---|---|
| cross-toolchain-arm | 4 |
| cross-toolchain-ssh-arm | 4 |
| cross-toolchain-arm64 | 4 |
| cross-toolchain-ssh-arm64 | 4 |
| debian | 4 |
| wayland-base | 4 |
| wayland-base-dev | 4 |
| wayland-gtk3 | 4 |
| weston | 4 |
| qt5-wayland | 4 |
| qt5-wayland-examples | 4 |
| qt6-wayland | 4 |
| qt6-wayland-examples | 4 |
| qt6-wayland-tests | 4 |
| weston-touch-calibrator | 4 |
| graphics-tests | 4 |
| chromium | 4 |
| cog | 4 |
| dotnet8 | 4 |
| aspdotnet8 | 4 |
| dotnet8-debug | 4 |
| dotnet8-wayland | 4 |
| dotnet8-gtk3 | 4 |
| rt-tests | 4 |
| stress-tests | 4 |
Tags and Versioning
Our Debian container images use semantic versioning for releases and are tagged accordingly. Notably, we avoid using the latest tag, which is the default tag when pulling an image without tags. Instead, we recommend users use the CT_TAGS environment variables that are available in all Torizon OS deployments. To learn more, read our dedicated article Torizon OS Containers Tags and Versioning.
As a rule of thumb, Torizon OS 6 uses major 3 tags, such as torizon/weston-vivante:3, while Torizon OS 7 uses major 4 tags, such as torizon/debian-imx8:4, and so forth. We neither guarantee nor test that images built for Torizon OS 7 will be compatible with Torizon OS 6.
Details about our Images
This section gives more details about our Debian-based images and how they can improve the development process.
In contrast with previous versions of Torizon Debian, images are built for the specific architecture of the SoC family (for example, the i.MX8 family only contains 64-bit cores, so all images for those particular devices are only built for the arm64 instruction set architecture) with the exception of the upstream images (those images that do not contain a SoC specifier), which are built for arm64, armv7 and amd64 architectures.
When pulling an image, the architecture choice will match the one of the host, although issuing a --platform specifier such as docker pull --platform=linux ... can be used to forcefully specify the intended architecture. Similarly, when building on top of Torizon images, docker build --pull --platform=<IMAGE_ARCH> ... can be used to enforce the build architecture as well.
Two points from our base image (which are carried through to the other images that inherit from it) are worth highlighting. For this, please take a look at our upstream variant base Dockerfile hosted on GitHub.
Firstly, we configure a default, non-root torizon user inside each container. The user is added to the correct groups by a custom script which simplifies permissions and access to the base Torizon OS system from the container.
COPY users-groups.sh /users-groups.sh
RUN ./users-groups.sh \
&& rm users-groups.sh
Secondly, the enablement of the package repository feed provided by Toradex is performed by the following Dockerfile instructions:
echo "Types: deb\n\
URIs: https://feeds1.toradex.com/debian/snapshots/$TORADEX_SNAPSHOT\n\
Suites: testing\n\
Components: main non-free\n\
Signed-By: /usr/share/keyrings/toradex-debian-repo.gpg" > /etc/apt/sources.list.d/toradex.sources \
&& echo "Package: *\nPin: origin feeds1.toradex.com\nPin-Priority: 900" > /etc/apt/preferences.d/toradex-feeds
For more information about how our custom Debian feeds enable hardware acceleration from the container, read our engineering-oriented blog about Hardware Acceleration in Containers.
Aditionally, each image has automated tests for the hardware-specific portions, which guarantee that the hardware and kernel are properly working from the base containers. For more information about tests and our release cycle, refer to our Containers Tags and Versioning page.
You can browse our GitHub repository toradex/torizon-containers and see exactly what is included in each of our Debian images.