Like many teams, we see clear gains in development speed and bug resolution, and it strengthens our specification-driven approach and software component integration. At the same time, our projects often involve industrial, medical, or otherwise critical environments, which come with strict constraints on confidentiality, digital sovereignty, and long‑term control over our infrastructure.

Cloud-first AI tooling is not acceptable for a large part of our work. This is why we started building our own AI stack, designed from day one to be local, privacy-preserving, and specialized for embedded and edge software development.

What we are building

We’re developing an internal AI coding assistant, currently used on:

• our edgem1/verdin build system including TorizonOS

• The SO3/AVZ hypervisor

• LVGL projects and other UI stacks

• generic embedded and Linux-based repos

The assistant runs fully local: no source code or customer data ever leaves the machine. It is built around a modern open model (Qwen 3.6 35B MoE, quantized) serving as the core, with a harness that adds:

• RAG over code and docs (per-project ChromaDB collections)

• corpus-aware context (one “corpus” per project/repo)

• persistent memory and skills, allowing the assistant to learn from real usage across sessions

• optional fine-tuning via lightweight adapters when it becomes useful again

In other words, it is not “just a model on a GPU”, but an AI tooling layer tailored to our codebases and workflows.

Architecture, in practice

Our current deployment runs on a developer laptop (RTX 4060 8GB + 62GB RAM). This configuration is deliberately constrained: it forces us to focus, to rationalize the scope, and to validate the architecture and tooling on realistic, everyday hardware.

• Model server: Qwen3.6‑35B‑A3B in Q8_0 via llama.cpp, with hybrid offload

  • attention on GPU, experts in RAM

  • ~7 tokens/s in typical usage, offline only

• Front-end: a CLI chat client aware of the current working directory

• Tools exposed to the model:

  • bash, edit_file, append_file, write_file for code edits

  • web_search for explicit internet queries when allowed

  • remember, save_skill, search_history for long-term memory and procedure learning

• Knowledge layers:

  • system prompts and project rules

  • RAG corpora per repo

  • persistent memories and skills

  • cross-session history search

Thanks to our collaboration with the REDS (Reconfigurable Embedded Digital Institute) from HEIG‑VD (University of Applied Sciences in Yverdon-les-Bains), we also have access to high‑end GPU infrastructure (for example RTX 6000‑class GPUs with 96 GB of VRAM). This will allow us to:

• run heavier models or higher‑throughput instances when needed

• perform faster and more extensive fine‑tuning runs

• ~48 tokens/s in typical usage, offline only

• deploy a dedicated server‑grade instance of the assistant in the near future, while preserving the same architecture and local‑first design

Everything is orchestrated so that the assistant can read, navigate, search, and edit code in a controlled way, with guardrails on file size, number of tool calls per turn, and explicit confirmation for any non‑read‑only actions.

Corpora: how we structure knowledge

Central to this approach is the notion of a corpus: each project or workspace is its own corpus with:

• its own RAG index

• its own memories and skills

• project-specific rules and conventions

For example:

• edgem1 is a curated corpus built from our build system checkout (verdin, virt64, scripts, doc, etc.)

• any other repo (LVGL, SO3, u-boot, …) becomes a generic corpus indexed with a standard directory walker

The CLI automatically detects the active corpus from the current directory, or lets you pick one:

• edgem-chat — open a chat bound to the current repo

• edgem-chat --corpus lvgl — explicitly pick a known corpus

• edgem-chat --here — treat the current directory as an ad-hoc corpus

• edgem-reindex / edgem-index — (re)build the index for a given tree

Large multi-component workspaces can be split into multiple corpora so that, for example, a huge upstream tree like u‑boot doesn’t dilute the relevance of RAG for a smaller in‑house component.

Four learning loops, different time scales

One important lesson from our experiments is that the model is only one part of the system. The real performance comes from how we manage knowledge and learning around it.

We currently combine four learning loops, each with its own “clock”:

1. RAG

   • On‑the‑fly retrieval of code and documentation from the indexed corpora

   • No retraining required, index refresh via reindexing

2. Memory and skills

   • The assistant can persist facts and procedures (with confirmation)

   • These are re‑used in later sessions, effectively encoding habits and best practices

3. Curated datasets from real usage

   • We log selected good exchanges as training samples

   • We also build datasets from git history, documentation, “how‑to” procedures, and teacher‑student distillation on our own codebases

4. Fine-tuning adapters (QLoRA)

   • When needed, we can train small LoRA adapters on external GPUs (RunPod, or HEIG‑VD infrastructure)

   • Only a small fraction of weights is adapted, which keeps costs and deployment simple

Interestingly, our latest tests with Qwen3.6‑35B show that, on a focused benchmark of our LVGL/SO3/Verdin questions, the stock model already outperforms our previous fine‑tuned coder model. In that context, a well‑designed RAG + memory + skills setup matters more than aggressive fine‑tuning, at least for now.

Safety and reliability

Because this assistant can read and modify code, we’ve built in several safety mechanisms:

• automatic approval only for read‑only commands

• confirmation required for any write, run, or destructive action

• protection against full rewrites of large files

• per‑turn tool call budget and caching to avoid repeated commands

• explicit mechanisms to mark answers as “good” or “bad” so they are (or are not) used in future training

We also keep the model’s “thinking mode” disabled in this context, as it tends to waste tokens without bringing benefits for our type of tasks.

Why this matters for our services

For our customers, this infrastructure is a way to:

• accelerate development and debugging on complex embedded and edge platforms

• keep all source code and sensitive data within a trusted Swiss‑based infrastructure

• leverage the latest open models (Qwen, DeepSeek, Apertus, etc.) while retaining full control over deployment

• build project‑specific assistants that really “know” the codebase and its conventions

Our collaboration and proximity with REDS is a key asset here. It gives us access to cutting‑edge research around open models and agent frameworks, and allows us to validate ideas quickly on real industrial use cases. It also paves the way for a server‑grade deployment of this assistant on powerful, on‑premise GPU hardware in the near future.

We will continue to evolve this platform, refine our datasets, and specialize the assistant further for embedded and edge scenarios.

If you are interested in local AI assistants, RAG over real codebases, or agent frameworks for embedded systems, we’d be very happy to exchange experiences and ideas.

I also think that the projet features a nice architecture which makes great use of Docker containers. Smart choice, as it enables them to run on large variety of platforms, on GNU/Linux servers, on NASes or any appliance that supports OCI containers.

Home assistant is split into components, here are the main ones:

core - which is the central container, provides the web UI that is accessible on port 8123
and provides many integrations out of the box, Zigbee, KNX, etc..

supervisor - It sits in between the core container and the operating system, the core container communicates with the supervisor container over HTTP. The supervisor communicates with the services over Dbus.

operating system - The operating system is built with buildroot and is extended with external packages provided by the home assistant contributors. The kernel is also compiled by buildroot, popular ARM boards are supported Raspberry Pi, ODROID and the Asus Tinker board.

I've used the generic aarch64 configuration everything compiled without errors and it took around 2 hours. It was then very straight forward to get it to run in QEMU mainly due to the developer documentation being of good quality and pleasant to read. https://developers.home-assistant.io/docs/architecture_index

Upon first boot, I was surprised to see that the GRUB bootloader is used by default, which has an entry for A slot and the B slot. However, our objective at EDGEMTech is to use it with TorizonOS so the home assistant operating system will only be used as a reference.

The next step was to understand the scripts in buildroot-external/package/hassio which make use of the skopeo utility to fetch the container images and save them as tarballs.

Didn't know about the skopeo utility, it allows to inspect containers without needlessly pulling the image, copy images between image stores, convert images. It is worth exploring further if one works with docker often.

Stay tuned for more news about home assistant on TorizonOS in a couple of weeks

Zephyr ships with its own unit test framework (Ztest) and an orchestrator (Twister) that builds and runs those tests across emulators, simulators, and real hardware. This post walks through what a test looks like, how to wire one into your project, and — in the final chapter — how to make the same suite run across several board variants.

You can see this as a starter tutorial to write tests and make your projects more robust! 

1. Why Ztest + Twister?

Ztest: The in-tree unit test framework (#include <zephyr/ztest.h>). Provides ZTEST_SUITE, ZTEST, zassert_* macros, fixtures, and setup/teardown hooks.

Twister: The test runner. Discovers test cases via testcase.yaml, builds each one for every allowed platform, flashes/runs it, and produces a report.

Both ship with Zephyr, you do not need a third-party framework.

2. Anatomy of a Test Suite

A minimal test suite is a small Zephyr application with three files:

tests/
└── my_feature/
    ├── CMakeLists.txt   # builds the test binary
    ├── prj.conf         # Kconfig for the test build
    ├── testcase.yaml    # tells Twister what to do with it
    └── src/
        └── main.c       # the actual tests

That layout — one folder per suite, sitting under tests/ at the repo root — is the convention every Zephyr-based project I have worked with follows.

3. Writing the Test Code

Open src/main.c and start with a suite declaration, then add cases:

#include <zephyr/ztest.h>
#include <errno.h>
#include "pid_controller.h"
​
/* ZTEST_SUITE(name, predicate, setup, before, after, teardown) */
ZTEST_SUITE(pid_controller, NULL, NULL, NULL, NULL, NULL);
​
ZTEST(pid_controller, test_compute_output)
{
    /* identical setpoint and measurement -> no correction */
    zassert_equal(PID_Compute_Output(/*setpoint=*/100, /*measurement=*/100), 0);
​
    /* positive error -> positive (clamped) output */
    zassert_equal(PID_Compute_Output(/*setpoint=*/100, /*measurement=*/  0), 100);
​
    /* invalid gain configuration -> -EINVAL */
    zassert_equal(PID_Compute_Output(/*setpoint=*/-1,  /*measurement=*/  0), -EINVAL);
}

Common assertions

- Boolean checks: zassert_true(x) / zassert_false(x)
- Integer / enum equality: zassert_equal(a, b)
- Pointer equality: zassert_equal_ptr(a, b)
- NULL checks: zassert_is_null(p) / zassert_not_null(p)
- Compare n bytes: zassert_mem_equal(p, q, n)
- Floating-point / tolerance: zassert_within(a, b, tol)

Fixtures

When several cases need the same state, use a fixture:

struct fixture {
    size_t size;
    uint8_t buf;
};
​
static void *suite_setup(void)
{
    static struct fixture f;
    return &f;
}
​
static void before_each(void *f)
{
    struct fixture *fix = f;
    memset(fix->buf, 0xff, sizeof(fix->buf));
    fix->size = 0;
}
​
ZTEST_SUITE(my_suite, NULL, suite_setup, before_each, NULL, NULL);
​
ZTEST_F(my_suite, test_buffer_initialized)   /* note: ZTEST_F, not ZTEST */
{
    zassert_equal(fixture->size, 0);
    zassert_equal(fixture->buf, 0xff);
}

ZTEST_F automatically gives you a fixture pointer inside the test body.

4. Wiring it into the Build

prj.conf

The bare minimum:

CONFIG_ZTEST=y
CONFIG_NEWLIB_LIBC=y           # for printf/floats in assertions
CONFIG_DEBUG_OPTIMIZATIONS=y

Add whatever Kconfig your code-under-test needs (drivers, subsystems, etc.).

CMakeLists.txt

cmake_minimum_required(VERSION 3.20.0)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
​
project(my_feature)
​
target_sources(app PRIVATE
    src/main.c
    ${CMAKE_SOURCE_DIR}/../../src/modules/control/pid_controller.c
)
​
target_include_directories(app PRIVATE
    ${CMAKE_SOURCE_DIR}/../../src/modules/control
)

Tip — share common test plumbing. If you have repository-wide includes, mocks, or compile flags, factor them into a tests/<your_project>_test.cmake file and include(...) it at the top of each suite's CMakeLists.txt. It keeps every suite's CMake to a single screen.

testcase.yaml

This is Twister's manifest. The simplest possible version:

tests:
  acme.my_feature:
    platform_allow:
      - mps2/an521/cpu0
    tags:
      - acme

The test name is <group>.<suite> and is what you'll see in reports.

5. Running the Tests

From the project root, with the Zephyr environment activated:

# Run a single suite
west twister --clobber-output --jobs 1 -T tests/my_feature
​
# Run everything under tests/
west twister --clobber-output --jobs 1 -T tests
​
# Run on real hardware
west twister --hardware-map hardware-map.yaml \
             --device-testing --inline-logs \
             --clobber-output --jobs 1 -T tests

Twister deposits build artifacts and logs under twister-out/. Open twister-out/twister.log (or the per-suite handler.log) when something fails — Ztest prints the file, line, and the values that didn't match.

For quick local iteration without Twister, you can west build -b <board> tests/my_feature like any other Zephyr app and flash/run it directly.

6. Targeting Multiple Boards (the Multi-Target Chapter)

Real projects rarely have one board. You typically have:

• An emulator for tests with no hardware dependencies (native_sim, mps2/an521/cpu0, qemu_x86, …). These run in CI in seconds.

• One or more real board revisions (acme_node@0.1.0, acme_node@0.1.1, …) for tests that need actual peripherals (sensors, LEDs, flash).

Twister's platform_allow field is what controls this per test. Pick the narrowest set that still covers the test's intent:

# Pure logic — runs anywhere with a libc. Put it on the emulator.
tests:
  acme.pid_controller:
    platform_allow:
      - mps2/an521/cpu0
      - acme_node@0.1.0
      - acme_node@0.1.1
    tags: testing
# Driver / peripheral test — on-target only.
tests:
  acme.gpio_isr_ordering:
    platform_allow:
      - acme_node@0.1.0
      - acme_node@0.1.1
    tags:
      - testing
      - gpio
# Pure emulator (heavy logic that doesn't touch any DTS nodes).
tests:
  acme.signal_filter_stress:
    platform_allow: mps2/an521/cpu0
    tags: acme
    timeout: 180

Sharing per-board configuration

When every on-target test needs the same Kconfig or DTS overlays (for example, routing the test console out a USB CDC ACM port so Twister can read it), don't repeat it in each suite. Centralize it:

tests/
├── acme_test.cmake            # common CMake helper
├── acme_test.conf             # common Kconfig (on-target only)
└── boards/
    └── acme_console.overlay   # common DTS overlay (on-target only)

Then in the shared CMake helper, append them only when the target is a real board, not the emulator:

if(NOT ${BOARD} MATCHES "^mps2")
    list(APPEND CONF_FILE  ${PROJECT_ROOT}/tests/acme_test.conf)
    list(APPEND DTC_OVERLAY_FILE ${PROJECT_ROOT}/tests/boards/acme_console.overlay)
endif()
​
list(APPEND CONF_FILE ${CMAKE_SOURCE_DIR}/prj.conf)

The benefit: each individual testcase.yaml only declares what platforms the test is valid on, and CMake takes care of supplying the right overlays and configs for each one.

Per-board overlays (when you actually need them)

If a single board revision needs a different pin or a tweaked node, drop a board-specific overlay next to the suite:

tests/my_feature/
├── boards/
│   ├── acme_node_0_1_0.overlay
│   └── acme_node_0_1_1.overlay
├── prj.conf
└── ...

Zephyr automatically picks boards/<normalized_board_name>.overlay when building. No CMake changes required.

Rules of thumb

1. Default to the emulator. If the code under test does not touch DTS nodes or peripherals, put it on the QEMU/native platform only — those tests run in CI without hardware.

2. Hardware-only when unavoidable. Driver mutex ordering, LED animation, real flash, ADC scans — these belong on the on-target list.

3. List every supported board revision. It is tempting to list one and trust the others "work the same." They don't. List acme_node@0.1.0 and acme_node@0.1.1 so a DTS regression on one revision is caught immediately.

4. Tag aggressively. Tags let you slice runs in CI (--tag testing, --tag gpio) without editing yaml.

8. Conclusion

The mental model that makes Zephyr testing click is this: a Ztest suite is its own standalone Zephyr application — same build system, same Kconfig, same devicetree — that just happens to call ZTEST functions instead of main(). When it runs on mps2/an521/cpu0, it's a tiny firmware image running inside QEMU. When it runs on acme_node@0.1.0, it's a tiny firmware image running on the silicon, talking to real peripherals over real buses.

That framing is what makes the approach so powerful. You can exercise a single module, a single driver, or a single piece of business logic lifted out of the full application flow, with nothing else running around it to muddy the picture. No state machine in another thread, no UI events firing, no background work — just the unit under test and the assertions you wrote against it. If a sensor driver behaves correctly in its standalone suite but misbehaves in the application, you now know the bug is in integration, not in the driver itself. That is an enormous amount of information for very little code.

Whether you are validating a pure algorithm on the emulator or proving that a specific board revision wires up its LEDs the way you expect, the recipe is the same: a small folder, a main.c with a few ZTEST cases, and a one-line platform_allow. Build that habit once and every feature you add gets a matching safety net for free.

Stay tuned

A more advanced guide will come soon, covering some of the remaining more complex features proposed by Zephyr! 

It is to note that the image customization part of this post is not officially supported by Toradex and is more of a "dive deeper" in TEZI than an official guide. A future post will cover a more production ready procedure, while this one is more of a discovery/custom guide. 

TEZI introduction

TEZI is the official way to flash an Torizon OS image in Toradex ecosystem. It is a simple Linux running in RAM, flashed over USB after booting the board into recovery. The Toradex boards all come pre-flashed with TEZI in their eMMC, removing the need of setting up the recovery process.

TEZI's job is simple:

1. Set up the storage and network
2. Scan Toradex official feeds (network) and any storage peripherals (USB, SD Card)
3. Launch a UI over the HDMI listing the images and some settings
4. Flash the image once it is selected by the user
5. Ask to reboot

And voilà, TEZI's job is done! So what does TEZI look at to flash the image?

TEZI bundled files

After a successful Yocto build, the TorizonOS image is packaged as a tarball ready for TEZI:

torizon/build/deploy/images/verdin-imx8mp/torizon-docker-verdin-imx8mp-Tezi.tar

Extracting it gives:

.
├── image.json
├── imx-boot
├── torizon-docker-verdin-imx8mp.ota.tar.zst
├── u-boot-initial-env-sd
├── prepare.sh
├── wrapup.sh
├── marketing.tar
├── toradexlinux.png
└── LA_OPT_NXP_SW.html

The key files are:

• image.json:the descriptor that tells TEZI how to handle everything
• imx-boot: U-Boot + SPL, combined with LPDDR firmware and ARM Trusted Firmware
• torizon-docker-verdin-imx8mp.ota.tar.zst: the OSTree rootfs archive
• u-boot-initial-env-sd: the initial U-Boot environment

image.json

This file is what TEZI reads first. It describes the image metadata and, how each block device should be partitioned and populated. A standard, unmodified file looks like this:

{
   "config_format": "4",
   "autoinstall": false,
   "name": "Torizon OS",
   "description": "Torizon OS Linux with no containers pre-provisioned.",
   "version": "7.4.0-devel-20250930075455+build.0",
   "release_date": "2025-09-30",
   "u_boot_env": "u-boot-initial-env-sd",
   "prepare_script": "prepare.sh",
   "wrapup_script": "wrapup.sh",
   "supported_product_ids": ,
   "blockdevs": [
      {
         "name": "emmc",
         "partitions": 
      },
      {
         "name": "emmc-boot0",
         "erase": true,
         "content": {
            "filesystem_type": "raw",
            "rawfiles": 
         }
      }
   ]
}

Breaking down the important fields:

• autoinstall: when true, TEZI will install the image automatically upon detection, without any user interaction. Useful for headless provisioning.
• supported_product_ids: the list of Toradex product IDs this image supports. TEZI uses this to validate hardware compatibility before flashing.
• blockdevs: the core of the file. Describes what goes where on each block device.
  • emmc: the main eMMC partition, formatted as ext4, receives the OSTree rootfs.
  • emmc-boot0: the hardware boot partition (4 MiB), written in raw mode at offset 0 with imx-boot.
• prepare_script / wrapup_script: shell scripts that TEZI runs before and after flashing, respectively. Used for board-specific setup.

Customizing the flash

The standard TorizonOS image boots using Toradex's own U-Boot and device tree. In our project, we need to boot from our own ITB (Image Tree Blob), a U-Boot FIT image that bundles our custom kernel, device tree, and initramfs into a single signed artifact, using a custom boot script to load it.

TEZI supports copying additional files into the ext4 partition through the filelist key inside a partition's content block. We use this to inject our ITB and boot script at flash time, alongside the OSTree rootfs:

"content": {
   "label": "otaroot",
   "filesystem_type": "ext4",
   "mkfs_options": "-E nodiscard",
   "filename": "torizon-docker-verdin-imx8mp.ota.tar.zst",
   "uncompressed_size": 674.7265625,
   "filelist": 
}

TEZI extracts the rootfs archive first, then copies each file listed in filelist directly into the partition root. Both verdin-imx8mp.itb and boot.edgem.scr must be present alongside image.json on the USB drive.

The second change is setting "autoinstall": true. This instructs TEZI to skip the selection UI and flash immediately upon detecting the USB drive, making it possible to provision boards with no display and no operator interaction.

Once again, this is not the official way of modifying the TorizonOS image. To customize an image it without manually modifying those files, one must use TorizonCore Builder.

Flashing the board

Preparing a USB drive for deployment comes down to:

1. Extracting the Yocto-produced TEZI tarball onto an ext4-formatted USB stick.
2. Replacing imx-boot with our custom build (U-Boot + SPL + ATF).
3. Adding verdin-imx8mp.itb and boot.edgem.scr next to image.json.
4. Editing image.json to add the filelist entries and set autoinstall to true.

Once plugged in, TEZI handles the rest: it partitions the eMMC, writes the bootloader to emmc-boot0, extracts the OSTree rootfs, and copies the ITB and boot script into the ext4 partition. On the next power cycle, our custom U-Boot finds verdin-imx8mp.itb at the root of the partition and hands off control to it.

The result is a board fully provisioned through TEZI  in a single step, without even needing a display!

If you're building a battery-powered product on Zephyr, you'll spend more time on power management than almost anything else. Controlling the CPU idle state is only half the battle - the real wins come from suspending individual peripherals (sensors, buses, radios, displays) when they're not in use, and cutting power to entire groups of devices through power domains.

This post is a practical, code-first walkthrough of Device PM and Power Domains in the latest Zephyr. We'll go from zero to a working setup with full Devicetree, Kconfig, and C driver examples.

The Big Picture

Zephyr device PM has two modes:

- System-Managed

- Device Runtime PM

The preferred approach for anything non-trivial is Device Runtime PM

Power Domains layer on top of either mode. They model a shared power rail (a regulator, a load switch, an SoC internal domain) and propagate power on/off events to all child devices.

We'll focus on Device Runtime PM + Power Domains, since that's what real-world products use.

Step 1: Kconfig - Enabling the Subsystem

# prj.conf
​
# Core device PM support
CONFIG_PM_DEVICE=y
​
# Reference-counted runtime PM (get/put API)
CONFIG_PM_DEVICE_RUNTIME=y
​
# Power domain support
CONFIG_PM_DEVICE_POWER_DOMAIN=y
​
# Optional: helpful during development
CONFIG_PM_DEVICE_SHELL=y
CONFIG_DEVICE_SHELL=y

Step 2: Devicetree - Defining Your Power Domain and Devices

Let's say you have a board with a load switch on GPIO P0.14 that powers an I2C bus with a temperature sensor and an accelerometer. Here's the complete DTS:

/ {
    /*
     * A GPIO-controlled load switch powering the sensor rail.
     * 'power-domain-gpio' is a built-in Zephyr driver.
     */
    sensor_rail: sensor-power-rail {
        compatible = "power-domain-gpio";
        #power-domain-cells = <0>;
​
        enable-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
        startup-delay-us = <1500>;   /* time for rail to stabilize */
        off-on-delay-us = <10000>;   /* minimum off time before re-enabling */
​
        /*
         * Let Zephyr auto-enable runtime PM for this domain.
         * Without this, you'd need to call pm_device_runtime_enable()
         * manually during init.
         */
        zephyr,pm-device-runtime-auto;
    };
};
​
/* The I2C bus behind the load switch */
&i2c1 {
    status = "okay";
    clock-frequency = <I2C_BITRATE_FAST>;
​
    /* Declare this bus is powered by our domain */
    power-domains = <&sensor_rail>;
    zephyr,pm-device-runtime-auto;
​
    /* Temperature sensor on the bus */
    temp_sensor: tmp117@48 {
        compatible = "ti,tmp117";
        reg = <0x48>;
        power-domains = <&sensor_rail>;
    };
​
    /* Accelerometer on the same bus */
    accel: lis2dh@19 {
        compatible = "st,lis2dh";
        reg = <0x19>;
        irq-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
        power-domains = <&sensor_rail>;
    };
};

Key things to notice:

1. Both the bus and the devices declare power-domains = <&sensor_rail>. When all children release their references, the domain powers down automatically.

2. zephyr,pm-device-runtime-auto on the domain and bus means Zephyr enables runtime PM right after successful init - no extra code needed.

3. startup-delay-us gives the rail time to stabilize before child devices try to communicate. This prevents I2C NACK storms after power-up.

Step 3: The PM Action Callback - Heart of Every PM-Aware Driver

Every driver that supports power management must implement a callback that handles four actions:

TURN_ON  ──► SUSPENDED  ──► ACTIVE
                 ▲              │
                 │              │
              SUSPEND ◄────────┘
                 │
                 ▼
             TURN_OFF

• TURN_ON: Power domain came alive. Configure pins/hardware into a known suspended state.

• RESUME: Move from suspended to active. Initialize hardware, enable interrupts.

• SUSPEND: Move from active to suspended. Disable interrupts, put hardware to sleep.

• TURN_OFF: Power domain is going down. Disconnect pins to prevent backpowering through GPIOs.

Here's a complete example for a fictional gas sensor driver:

#include <zephyr/device.h>
#include <zephyr/drivers/i2c.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/pm/device.h>
#include <zephyr/pm/device_runtime.h>
​
#define DT_DRV_COMPAT acme_gas_sensor
​
struct gas_sensor_config {
    struct i2c_dt_spec bus;
    struct gpio_dt_spec alert_gpio;
};
​
struct gas_sensor_data {
    struct gpio_callback alert_cb;
    uint16_t last_reading;
};
​
/* ──────────────── PM helpers ──────────────── */
​
static int gas_sensor_hw_resume(const struct device *dev)
{
    const struct gas_sensor_config *cfg = dev->config;
    struct gas_sensor_data *data = dev->data;
    int ret;
​
    /* Get the bus so we can talk to the device */
    ret = pm_device_runtime_get(cfg->bus.bus);
    if (ret < 0) {
        return ret;
    }
​
    /* Wake the sensor from its internal sleep mode */
    uint8_t wake_cmd = 0x01;
    ret = i2c_write_dt(&cfg->bus, &wake_cmd, 1);
    if (ret < 0) {
        pm_device_runtime_put(cfg->bus.bus);
        return ret;
    }
​
    /* Enable the alert interrupt */
    gpio_add_callback(cfg->alert_gpio.port, &data->alert_cb);
    gpio_pin_interrupt_configure_dt(&cfg->alert_gpio, GPIO_INT_EDGE_TO_ACTIVE);
​
    /* Release bus -- we only need it during transactions */
    pm_device_runtime_put(cfg->bus.bus);
​
    return 0;
}
​
static int gas_sensor_hw_suspend(const struct device *dev)
{
    const struct gas_sensor_config *cfg = dev->config;
    struct gas_sensor_data *data = dev->data;
    int ret;
​
    /* Disable the alert interrupt */
    gpio_pin_interrupt_configure_dt(&cfg->alert_gpio, GPIO_INT_DISABLED);
    gpio_remove_callback(cfg->alert_gpio.port, &data->alert_cb);
​
    /* Put sensor into its internal low-power mode */
    ret = pm_device_runtime_get(cfg->bus.bus);
    if (ret < 0) {
        return ret;
    }
​
    uint8_t sleep_cmd = 0x00;
    ret = i2c_write_dt(&cfg->bus, &sleep_cmd, 1);
​
    pm_device_runtime_put(cfg->bus.bus);
​
    return ret;
}
​
static int gas_sensor_hw_turn_on(const struct device *dev)
{
    const struct gas_sensor_config *cfg = dev->config;
​
    /*
     * Power domain is ON. Configure pins into a known state.
     * The device starts suspended -- we just need safe pin states.
     */
    gpio_pin_configure_dt(&cfg->alert_gpio, GPIO_INPUT);
​
    return 0;
}
​
static int gas_sensor_hw_turn_off(const struct device *dev)
{
    const struct gas_sensor_config *cfg = dev->config;
​
    /*
     * Power domain is going OFF.
     * Disconnect GPIOs to prevent backpowering the sensor
     * through its alert pin when the rail is dead.
     */
    if (gpio_pin_configure_dt(&cfg->alert_gpio, GPIO_DISCONNECTED)) {
        /* Fallback if the GPIO driver doesn't support DISCONNECTED */
        gpio_pin_configure_dt(&cfg->alert_gpio, GPIO_INPUT);
    }
​
    return 0;
}
​
/* ──────────────── PM action callback ──────────────── */
​
static int gas_sensor_pm_action(const struct device *dev,
                                enum pm_device_action action)
{
    switch (action) {
    case PM_DEVICE_ACTION_RESUME:
        return gas_sensor_hw_resume(dev);
    case PM_DEVICE_ACTION_SUSPEND:
        return gas_sensor_hw_suspend(dev);
    case PM_DEVICE_ACTION_TURN_ON:
        return gas_sensor_hw_turn_on(dev);
    case PM_DEVICE_ACTION_TURN_OFF:
        return gas_sensor_hw_turn_off(dev);
    default:
        return -ENOTSUP;
    }
}
​
/* ──────────────── Public API ──────────────── */
​
static int gas_sensor_read(const struct device *dev, uint16_t *ppm)
{
    const struct gas_sensor_config *cfg = dev->config;
    struct gas_sensor_data *data = dev->data;
    int ret;
​
    /* Activate the sensor (and implicitly, the bus + power domain) */
    ret = pm_device_runtime_get(dev);
    if (ret < 0) {
        return ret;
    }
​
    /* Now the device is ACTIVE -- perform the read */
    ret = pm_device_runtime_get(cfg->bus.bus);
    if (ret < 0) {
        goto out;
    }
​
    ret = i2c_burst_read_dt(&cfg->bus, 0x10, (uint8_t *)ppm, sizeof(*ppm));
​
    pm_device_runtime_put(cfg->bus.bus);
​
out:
    /* Release. If no other users, sensor suspends, domain may power off. */
    pm_device_runtime_put(dev);
    return ret;
}
​
/* ──────────────── Init & instantiation ──────────────── */
​
static int gas_sensor_init(const struct device *dev)
{
    const struct gas_sensor_config *cfg = dev->config;
    struct gas_sensor_data *data = dev->data;
​
    if (!i2c_is_ready_dt(&cfg->bus)) {
        return -ENODEV;
    }
​
    if (!gpio_is_ready_dt(&cfg->alert_gpio)) {
        return -ENODEV;
    }
​
    gpio_init_callback(&data->alert_cb, gas_sensor_alert_handler,
                       BIT(cfg->alert_gpio.pin));
​
    /*
     * MUST be the last call in init.
     * This initializes the PM context and puts the device into the
     * correct initial state via the action callback (TURN_ON → RESUME).
     */
    return pm_device_driver_init(dev, gas_sensor_pm_action);
}
​
/* Define the PM context for instance 0 */
PM_DEVICE_DT_INST_DEFINE(0, gas_sensor_pm_action);
​
DEVICE_DT_INST_DEFINE(
    0,
    gas_sensor_init,     /* init */
    PM_DEVICE_DT_INST_GET(0),  /* pm */
    &gas_sensor_data_0,  /* data */
    &gas_sensor_cfg_0,   /* config */
    POST_KERNEL,
    CONFIG_SENSOR_INIT_PRIORITY,
    &gas_sensor_api
);

Practical Tips & Gotchas

1. The boot-time chattering problem

When runtime PM is enabled, each device's init function may briefly get and put the power domain. With 10 devices on a domain, this can toggle the physical power rail 10+ times during boot. Solution: hold the domain active during init:

#include <zephyr/init.h>
#include <zephyr/pm/device_runtime.h>
​
static const struct device *domain = DEVICE_DT_GET(DT_NODELABEL(sensor_rail));
​
static int hold_domain_during_boot(void)
{
    /* Keep the rail on through the entire POST_KERNEL init phase */
    return pm_device_runtime_get(domain);
}
​
static int release_domain_after_boot(void)
{
    /* All drivers are initialized -- let the domain idle */
    return pm_device_runtime_put(domain);
}
​
SYS_INIT(hold_domain_during_boot, POST_KERNEL, 0);
SYS_INIT(release_domain_after_boot, APPLICATION, 99);

2. Always guard TURN_OFF against backpowering

When a power rail goes down, any GPIO pin driving HIGH into a de-powered device will backpower it through its ESD diodes. Always disconnect or tri-state your outputs in TURN_OFF:

case PM_DEVICE_ACTION_TURN_OFF:
    /* Prefer GPIO_DISCONNECTED; fall back to GPIO_INPUT */
    if (gpio_pin_configure_dt(&cfg->cs_gpio, GPIO_DISCONNECTED) != 0) {
        gpio_pin_configure_dt(&cfg->cs_gpio, GPIO_INPUT);
    }
    return 0;

3. Use k_can_yield() guard in PM callbacks

If system-managed device PM is also enabled, your PM callback might be invoked from the idle thread, which cannot block. Guard blocking operations:

static int my_pm_action(const struct device *dev, enum pm_device_action action)
{
    if (!k_can_yield()) {
        return -ENOTSUP;
    }
​
    /* Safe to do blocking I2C/SPI operations here */
    /* ... */
}

4. Async put for bursty workloads

If your device does many short transactions with brief gaps, synchronous put/get on every transaction is wasteful. Use pm_device_runtime_put_async() with a delay to keep the device active through bursts:

/* Keep device active for 50ms after the last transaction, then suspend */
pm_device_runtime_put_async(dev, K_MSEC(50));

5. Shell debugging is your best friend

uart:~$ device list
devices:
- sensor-power-rail (active, usage=2)
- i2c@40003000 (active, usage=1)
- accel@19 (active, usage=1)
- temp_sensor@48 (suspended, usage=0)
- radio@0 (suspended, usage=0)

The usage=N count tells you exactly how many references are held. If a device is stuck active with usage=1 when you expect 0, you have a reference leak in a driver.

Summary

The full setup checklist:

1. Kconfig: Enable PM_DEVICE, PM_DEVICE_RUNTIME, and optionally PM_DEVICE_POWER_DOMAIN

2. DTS: Define your power domain node, add power-domains = <&domain> to child devices, use zephyr,pm-device-runtime-auto where appropriate

3. Driver: Implement a PM action callback handling all four actions (RESUME, SUSPEND, TURN_ON, TURN_OFF)

4. Driver init: End with pm_device_driver_init(dev, my_pm_action) and instantiate with PM_DEVICE_DT_INST_DEFINE

5. Consumers: Bracket every hardware access with pm_device_runtime_get()/pm_device_runtime_put()

The device runtime PM model with power domains is one of Zephyr's strongest features. It takes some effort to set up correctly, but once it's in place, your system only burns power on peripherals that are actually doing work - and that's the whole game in battery-powered products.

When building embedded Linux systems with Yocto, there are situations where you need to run some code very early in the boot process, before the root filesystem is even mounted. This is exactly what the initramfs (initial RAM filesystem) is for: a temporary root filesystem loaded into memory by the bootloader, used to prepare the environment for the real root mount. Examples can be decrypting a partition, mounting a special device and so on.

Yocto provides a useful framework to build and integrate an initramfs image directly into your distribution. In this post, we'll cover:

• How the initramfs framework works in Yocto
• How to set it up in your layer
• How to add a hook with a custom init script

Let's get into it.

Setup

The initramfs support in Yocto is built around a dedicated image recipe, typically based on core-image-minimal-initramfs, and a set of packagegroup recipes that bundle the necessary tools.

Enabling the initramfs image

In your local.conf or distro configuration, add the following:

INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"

INITRAMFS_IMAGE tells Yocto which image recipe to use as the initramfs. Setting INITRAMFS_IMAGE_BUNDLE to "1" instructs the kernel build to bundle the initramfs cpio archive directly into the kernel image, so the bootloader only needs to load a single binary.

The initramfs image recipe

The default core-image-minimal-initramfs recipe lives in meta/recipes-core/images/. It inherits core-image and pulls in a minimal package group:

PACKAGE_INSTALL = "\
    initramfs-framework \
    base-passwd \
    ${VIRTUAL-RUNTIME_base-utils} \
"

The key package here is initramfs-framework, which provides the modular init infrastructure we'll hook into.

The initramfs-framework package

initramfs-framework is a shell-based, modular init system designed specifically for Yocto initramfs images. It lives in meta/recipes-core/initrdscripts/ and provides:

• A main /init script that sources modules in order
• A set of built-in modules (e.g. udev, rootfs, nfsrootfs, ...)
• A clean hook mechanism to add your own modules

Modules are shell scripts placed in /init.d/ inside the initramfs, named with a numeric prefix to control execution order (e.g. 00-debug, 10-overlayroot).

Adding a Hook with a Custom Init Script

Now the interesting part. Say you need to run a custom script early in boot — for instance, to configure a network interface, check hardware, or set up an overlay. Here is how to do it cleanly using the initramfs-framework hook system.

1. Write the module script

Create a shell script following the initramfs-framework module convention. Each module must define two functions:

• <module>_enabled: Determine if your module should run. Returning 0 means your module should run, returning 1 means it is deactivated.
• <module>_run: Your custom module logic

#!/bin/sh
# modules/80-myhook

myhook_enabled() {
    return 0
}

myhook_run() {
    msg "Running my custom initramfs hook..."

    # Your logic here — e.g. load a kernel module, set up a mount, etc.
    modprobe mydriver

    msg "Custom hook done."
}

The msg helper is provided by initramfs-framework and writes to the console. It also offers some other logging wrappers such as fatal and warn.

2. Create a bbappend or new recipe

The cleanest way to integrate this into Yocto is to create a recipe in your custom layer that installs the module into the initramfs image.

Create a recipe file, e.g. recipes-core/initrdscripts/initramfs-myhook_1.0.bb:

SUMMARY = "Custom initramfs hook for my project"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "file://80-myhook"

S = "${WORKDIR}"

do_install() {
    install -d ${D}/init.d
    install -m 0755 ${WORKDIR}/80-myhook ${D}/init.d/80-myhook
}

FILES:${PN} = "/init.d/80-myhook"

Place your 80-myhook script under recipes-core/initrdscripts/files/80-myhook.

3. Add the package to your initramfs image

Either create a core-image-minimal-initramfs.bbappend in your layer, or create a custom initramfs image recipe. With the bbappend approach:

# recipes-core/images/core-image-minimal-initramfs.bbappend

PACKAGE_INSTALL:append = " initramfs-myhook"

And just like that, the minimal-initramfs is extended with your init script. A custom recipe would allow more customization on core-image-minimal-initramfs, but for this use case, extending the existing recipe is enough.

4. Build

Trigger the build as usual:

bitbake core-image-minimal-initramfs

Conclusion

The initramfs-framework in Yocto provides a solid, modular foundation for early boot customization. Rather than hacking a monolithic init script, you can slot in well-isolated modules that are easy to maintain and test independently. The pattern is always the same: write a module script, package it in a recipe, add it to the initramfs image and Yocto takes care of the rest.

This approach scales well as your project grows: need to add an overlayfs setup? A hardware self-test? An early network configuration? Each one becomes its own module with a clear numeric priority, living cleanly in your layer. It also bases itself on a well tested, actively maintained base.

A joint collaboration in Yverdon-les-Bains on Linux, AVZ virtualization, SO3 capsules, and safety-oriented LVGL user interfaces.

EDGEMTech and HEIG-VD are jointly developing an open-source embedded software environment that combines Linux, the AVZ virtualization layer, and SO3 capsules to host modular graphical applications. The objective is to provide a robust execution platform for embedded products where hardware access, application isolation, portability, and long-term maintainability must coexist without compromising user-interface richness.

Figure 1. High-level view of the software stack: Portainer-driven orchestration in Linux, multiple SO3 capsules hosting LVGL applications, and display front-end/back-end separation over the AVZ hypervisor.

1. Architecture overview

At the bottom of the stack, the AVZ hypervisor provides the virtualization layer used to partition the execution environment. Above it, the Linux domain remains the system anchor point: it hosts the services that need direct access to the physical hardware, keeps ownership of the low-level graphics drivers, and exposes the execution and orchestration services required to manage isolated application domains.

On top of this base, SO3 capsules can be instantiated as strongly isolated execution contexts dedicated to user-interface workloads. The diagram illustrates capsules hosting graphical applications written in C, C++, micro-Python and soon Rust, but the same model can be extended to other language bindings when relevant. Each capsule packages its own application logic together with the LVGL user-interface stack and the required runtime components.

2. Portainer orchestration and capsule lifecycle

A key part of the approach is the integration of Portainer for orchestration. A Portainer manager communicates with a SO3-enabled agent running in the Linux domain. This agent acts as the control bridge between the orchestration layer and the embedded virtualization environment.

From an operational standpoint, this makes it possible to deploy, update, stop, and supervise several capsules on the same target. Instead of embedding all graphical functions inside a single monolithic application, different LVGL-based apps can be packaged into separate capsules and managed independently. This is especially attractive for products that need distinct operating modes, customer-specific HMIs, service interfaces, or staged feature rollouts.

The same mechanism also opens the door to switching between capsules according to the active application context. In practice, one capsule can implement one HMI profile while another capsule implements a different one, with the orchestrator selecting which capsule is currently active or visible. This preserves a clean separation between applications while simplifying update strategies and fault containment.

3. Split graphics architecture and LVGL portability

One of the most interesting technical aspects of the architecture is the split between user-interface logic and graphics implementation. The LVGL application and its UI logic run inside the capsule, while the hardware-facing graphics components remain anchored in the Linux domain.

In the diagram, this split appears through the distinction between the display front-end driver on the capsule side and the display back-end driver on the Linux side, the latter itself relying on the native graphics stack and drivers such as DRM, framebuffer, or other platform-specific implementations. This separation keeps the application layer focused on UI behavior, widgets, layouts, and event handling, while the rendering and display integration can be adapted independently to the target hardware.

This design greatly improves portability. An LVGL application can be kept largely unchanged while the graphics back-end is retargeted to another SoC, another display controller, or another rendering path. The same UI logic can therefore be reused across product families with fewer modifications in the high-level application code. In other words, portability is obtained not by freezing the whole stack, but by isolating the platform-dependent layers where they belong.

4. LVGL Pro workflow and LVGL Safe perspective

The workflow can also benefit from the LVGL Pro editor, which provides a practical way to design the user interface and generate the corresponding target code. In this architecture, the generated application can then be packaged into a capsule and deployed through the orchestration layer, preserving a consistent pipeline from UI design to embedded deployment.

The safety-oriented dimension is equally important. LVGL Safe is highly relevant in this context because it complements the architectural isolation already provided by capsules and virtualization. When a UI is placed inside a strongly partitioned execution environment, and when its graphics path is explicitly controlled through front-end/back-end separation, LVGL Safe becomes an especially compelling candidate for applications that have stronger safety, robustness, or certification-driven requirements.

The combination of LVGL Safe and SO3 capsules therefore offers a promising route for highly critical environments in which a graphical interface is still required, but where fault containment, software partitioning, controlled updates, and predictable system behavior are mandatory design constraints.

5. Open-source engineering collaboration

Beyond the technical stack itself, this project also reflects the value of a close collaboration between industrial engineering and applied research. EDGEMTech brings product-oriented embedded software expertise, customer-facing constraints, and deployment pragmatism, while HEIG-VD contributes engineering depth, experimentation capacity, and a strong academic environment to structure and validate the approach.

Together, the goal is to consolidate a reusable open-source foundation for Linux-based virtualized embedded systems, capable of hosting advanced and portable HMIs with a clean separation of concerns between orchestration, application logic, and hardware-specific graphics integration.

We are currently preparing several showcases based on Raspberry Pi 4 platforms to illustrate this architecture in practice. More demonstrations and technical details will be shared soon.

This article is intended as a technical introduction to the ongoing collaboration. More implementation details, demonstrations, and feedback from field deployments will be shared as the project evolves.

We’re excited to announce that EDGEMTech SA will be attending Embedded World 2026 in Nuremberg on March 10-11.

Embedded World is one of the most important international gatherings for the embedded systems community. The event brings together experts in embedded hardware, firmware, software platforms, IoT, connectivity, HMI/GUI technologies, and system architecture. It’s always a great opportunity to explore the latest innovations, exchange ideas, and connect with industry leaders from across the ecosystem.

🎯 Why we’re attending

This year, our goals are to:

• Strengthen relationships with existing partners

• Meet new companies working in embedded and connected systems

• Explore emerging technologies and tooling

• Discuss upcoming projects and collaboration opportunities

• Stay closely aligned with industry trends and best practices

Although we won’t have a booth this year, our team will be present at the event and visiting several of our partners.

We’re also happy to share that our close partner LVGL will be attending and exhibiting at Embedded World. As many of you know, LVGL plays a key role in modern embedded GUI development, and we look forward to connecting with their team on-site as well.

🤝 Let’s connect in Nuremberg

If you’re attending Embedded World and would like to meet, we’d be delighted to connect in person. Whether you’re interested in:

• Embedded firmware development

• GUI and HMI solutions

• System architecture and optimization

• Product development support

• Or exploring potential partnerships

Feel free to reach out and schedule a time to meet during the event.

You can contact us:

• Via direct message here on the forum

• Or through our usual contact channels

We’re looking forward to a productive and inspiring few days in Nuremberg... and hopefully meeting some of you there!

Hello everyone! 

Following the article about Torizon VSCode Extension by my colleague Gabriel, I wanted to add a bit more explanation about how to effectively use it.

If you're getting started with the Torizon IDE Extension and wondering why your project has three Dockerfiles and a docker-compose file, this quick guide is for you. I'll use the cLvgl template as an example, but the same pattern applies to most C/C++ Torizon templates.

Overview

Every Torizon IDE C/C++ template includes these container-related files:

Let's walk through each one.

Dockerfile: Production Image

This is a multi-stage Dockerfile that both compiles and packages your app for production.

Stage 1 — build: Uses torizon/cross-toolchain-${IMAGE_ARCH} as a base. It installs cmake, copies your source code, and cross-compiles the application for your target architecture (arm64, armhf, etc.) in Release mode.

Stage 2 — deploy: Starts from a minimal torizon/debian image for the target platform. It copies only the compiled binary from the build stage (build-${IMAGE_ARCH}/bin) into the container. The final image is clean — no compiler, no build tools, just your app.

The entrypoint is simply:

CMD 

This is the image you'll push to a registry and deploy to your devices in the field.

Dockerfile.debug: Development/Debug Image

This Dockerfile builds a container specifically for remote debugging during development. Unlike the production Dockerfile, it does not compile your code. Instead it:

1. Starts from the same torizon/debian base image for the target platform.
2. Installs debug tooling: openssh-server, gdb, rsync, curl, and file.
3. Configures an SSH server on a custom port (DEBUG_SSH_PORT) so VS Code can connect via Pipe Transport and attach the debugger.

The SSH setup is intentionally insecure (empty password, root login permitted) — this is fine for a development container, but obviously not something you'd ship.

Notice that there's no COPY of source or build artifacts in this file. During the debug workflow, the IDE Extension's tasks handle copying the compiled output (built by the SDK container) into this container at deploy time. The container's only job at runtime is to run the SSH daemon:

CMD 

VS Code then connects over SSH, uploads the binary, and attaches GDB.

Dockerfile.sdk: Cross-Compilation Toolchain

This Dockerfile creates the SDK container — the environment where your code gets cross-compiled during development.

It's based on torizon/cross-toolchain-${IMAGE_ARCH} and installs cmake plus any additional build dependencies you need. The key thing is how it's used: the Torizon IDE Extension runs this container on your host machine with your project workspace bind-mounted into it:

-v ${workspaceFolder}:${APP_ROOT}

This means:

• The SDK container has access to your source code.
• Build outputs land directly in your workspace (e.g., build-arm64/).
• Incremental builds work — artifacts persist between sessions.
• The container runs as user torizon (not root).

You only need this file for compiled languages. Templates for interpreted languages (Python, Node.js, etc.) won't have a Dockerfile.sdk.

docker-compose.yml: Making it run!

The compose file defines two services, separated by profiles:

__container__-debug (profile: debug)

This service uses Dockerfile.debug. It:

• Forwards the DEBUG_SSH_PORT so VS Code can connect.
• Grants access to device nodes (/dev) via a bind mount and cgroup rules for tty, input devices, DRI (GPU), and framebuffer — essential for an LVGL app that needs to render to a display.
• Is only started when the debug profile is active.

__container__ (profile: release)

This service uses the production Dockerfile. It has the same device access and volume configuration as the debug service, but no SSH port forwarding. The image tag uses ${DOCKER_LOGIN} instead of ${LOCAL_REGISTRY}, meaning it's intended to be pushed to a remote registry.

The __container__ placeholder gets replaced with your actual project name when you create a project from the template.

How the profiles work

The Torizon IDE Extension activates the appropriate profile automatically:

• During development/debugging → docker compose --profile debug up
• For production/release testing → docker compose --profile release up

This means both services are defined in the same file but never run simultaneously.

Wrap up: How They Work Together

Here's how the three Dockerfiles fit into the development workflow:

1. You write code on your host machine.
2. Dockerfile.sdk → The IDE Extension builds the SDK container and runs cmake inside it (with your workspace bind-mounted) to cross-compile your code.
3. Dockerfile.debug → The IDE Extension builds the debug container, deploys it to the target device, copies the compiled binary into it, and VS Code attaches GDB over SSH.
4. Dockerfile → When you're ready to release, this multi-stage Dockerfile compiles and packages everything into a minimal production image.

Adding Custom Dependencies

You'll notice special labels like __torizon_packages_build_start__ and __torizon_packages_prod_start__ in the Dockerfiles. The IDE Extension uses these markers to automatically inject packages you configure via torizonPackages.json. You can also add packages manually between those labels.

Conclusion

Hopefully this clears up the role of each file in those templates! The Torizon IDE Extension handles most of the orchestration for you, but understanding what each Dockerfile does helps a lot when you need to customize your build or debug a deployment issue!