Torizon is a new Linux-based software platform that simplifies the process of developing and maintaining embedded software. It allows you to configure the system for your use case quickly and easily, so you can focus on application development instead of Linux builds.
Torizon fully supports the following modules, which use eMMC as flash storage:
Raw NAND-based modules are currently supported only by experimental releases and they may not be supported in the stable versions of TorizonCore:
Browse for Torizon resources from the tabs below.
Follow our Step-by-step Getting Started Guide for fully supported modules as an overview step to get you set up in no time.
After you have completed it, check the other tabs from the current article, where you can find a list of Torizon features as well as a list of related articles.
TorizonCore is installed via the Toradex Easy Installer that comes pre-installed in Toradex SoMs from factory. Install the TorizonCore image with Docker runtime:
Install TorizonCore image with Docker runtime
Upon booting one can login using the following users:
root
torizon
Check out ongoing projects on Toradex Labs:
Development Environment for Torizon using Visual Studio with the Torizon Microsoft Environment. Check out how it works!
Flash status and lifespan made easy, provided via a web UI in the Flash Analytics Tool. Check out our webinar on Flash Memory in Embedded Linux Systems for an overview of how it works.
Torizon is an embedded computing platform that makes it easy to develop robust and scalable products. An initial overview is provided in the Torizon page on the Toradex website. The main Torizon component is TorizonCore: a minimal embedded Linux image that has the base for OTA services and an optional container runtime.
TorizonCore binary images are provided by Toradex with different configuration options. Whenever possible you should use TorizonCore image with Docker runtime:
| Image | Description |
|---|---|
| TorizonCore image with Docker runtime | Full-featured image containing Docker and OTA. The preferred image, provides the full Torizon experience. |
| TorizonCore image | minimal image only containing OTA. Can serve as a base for customers building custom images using OpenEmbedded and planing to leverage TorizonCore update system. |
All images above have a Linux kernel built with and without PREEMPT_RT real-time patch applied. The versions with PREEMPT_RT are experimental. A chart illustrating the variations and the relation between them is provided below:
TorizonCore Images - click to see in full resolution
The latest builds can be obtained by enabling the Toradex Continous Integration (CI) Server feed in the Toradex Easy Installer Feeds dialog, and some images or variants from the table above may be availble only in the CI server.
Docker containers are the base in which Torizon relies for application development. You are able to run any image built for your respective module's architecture. Along with TorizonCore we provide a default container as a sort of friendly starting environment.
TorizonCore is built with Over-The-Air Updates capabilities and Torizon also provides server-side capabilities. The overview is provided in a separate article:
The traditional device tree development and deployment process is laborious. Torizon uses device tree overlays hoping to somewhat streamline this process. With overlays, you just create a small snippet containing the hardware changes you need.
Toradex provides a public release roadmap for the TorizonCore platform:
The full-featured image is rather large taking up most of the space on the raw NAND-based modules. As such it is not recommended to experiment with containers on these devices since there isn't much space for containers as is. In the future, we hope to slim down the footprint. Alternatively, the Balena based image is slimmer by about ~70MB, although fully unsupported by Toradex.
In our i.MX6-based Debian containers we are using the Armada X.org DDX driver which seems to have worked fine in our tests but, it might show stability issues.
The error is probably related to missing session management inside the container.
Make sure to clear the U-Boot environment by using env default -a && env save.
