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!

Today, SO3 is an open-source project available on GitHub:

👉 https://github.com/smartobjectoriented/so3

SO3 is not meant to compete with production-grade embedded operating systems like FreeRTOS or Zephyr. Those systems are designed to be dropped into countless real-world products. SO3 has a different goal: it is deliberately focused on deep understanding. It is built for exploring low-level interactions with the CPU, memory subsystem, and peripherals, with as little conceptual noise as possible.

Minimal Code, Real OS Concepts

Despite its small codebase, SO3 implements most of the core mechanisms you would expect from a modern operating system:

• strict separation between user space and kernel space

• virtual memory management

• support for running as a hypervisor

This minimal surface is intentional. SO3 aims to expose how these mechanisms work rather than hide them behind layers of framework code.

AVZ, Capsules, and Coexisting with Linux

When SO3 runs as a hypervisor, it takes the name AVZ (Agency Virtualizer)—a name inherited from earlier stages of the project. In this configuration, AVZ can host Linux, but that’s only part of the story.

What makes AVZ particularly interesting is that SO3 itself can run alongside Linux, at the same time, on the same hardware. Multiple SO3 instances can coexist simultaneously, each running in a fully memory-isolated environment called a capsule.

These capsules provide strong isolation guarantees and open the door to experimentation with secure execution environments, partitioning, and mixed-criticality systems—all without the complexity of a large hypervisor codebase.

Modern Tooling, Familiar Interfaces

Over time, SO3 has grown beyond its early experimental roots:

• It is now fully compatible with the musl C standard library

• Its networking capabilities are built on the well-known lwIP TCP/IP stack

This makes it possible to write real applications for SO3 while still staying close to the metal.

Used in Real Projects: LVGL Continuous Integration

While SO3 remains focused on education and experimentation, it has also found practical use in real-world workflows. Notably, SO3 is used in the LVGL continuous integration infrastructure to execute non-regression tests on the LVGL codebase.

In this context, SO3 provides a controlled and deterministic execution environment, making it particularly well-suited for automated testing of low-level and graphics-related code.

Where SO3 Runs Today

SO3 currently runs on:

• QEMU ARM platforms (32-bit and 64-bit)

• The Raspberry Pi family

This makes it accessible both for fast experimentation in emulation and for hands-on work with real hardware.

A Learning Tool First—and Proud of It

• SO3 is not about being everything to everyone. It is about clarity, control, and understanding. Whether you are curious about operating system internals, virtualization, or low-level ARM platforms, SO3 offers a compact and honest environment where nothing is too abstracted to learn from.

In short: SO3 is small by design—but it goes very deep.

• https://github.com/smartobjectoriented/so3
• https://www.nongnu.org/lwip/2_1_x/index.htm
• https://musl.libc.org/
• https://lvgl.io

QR codes have become a ubiquitous way to encode and share information, URLs, contact details, configuration parameters, and more. With LVGL, embedding a QR code into your embedded UI is straightforward. In this post, we’ll explore how to use QR codes in LVGL, discuss the limits of QR code sizing on embedded displays, and take a step back to reflect on the design philosophy behind these clever square patterns.

Using QR Codes in LVGL

Starting from LVGL v8, the library includes a built-in widget for generating and displaying QR codes.

Here's a simple example:

int main(lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");) {
  return 0;
}

lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");
}

int main(lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");) {
  return 0;
}

lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_black(), lv_color_white());
lv_qrcode_update(qr, "https://www.edgemtech.com");
}

This snippet creates a 100x100 pixel QR code in black on a white background. The lv_qrcode_update function encodes the string into the QR pattern.

Display Limitations and Scaling

The size of your QR code is constrained by:

• The screen resolution
• The desired readability (especially when using a camera)
• The error correction level and data complexity

LVGL supports scaling the QR pattern with pixel-perfect precision. However, embedded displays often have limited resolution. For example, on a 128x128 screen, you might only fit a version 2 QR code (~25x25 modules) cleanly, assuming each module is 4-5 pixels.

⚠️ Rule of thumb: Always scale each module (square) to at least 3x3 pixels for reliable scanning.

A Word on QR Code Structure

QR codes are built using a defined standard (ISO/IEC 18004), consisting of:

• Finder patterns: the large corner squares
• Alignment patterns: help correct distortion
• Timing patterns: guide scanning across rows/columns
• Error correction: allows reading even if damaged

The LVGL QR widget internally uses a compact QR generation algorithm, based on qrcodegen, optimized for embedded use. You won’t need to implement these patterns yourself, but understanding them helps debug issues (e.g., too much data, unreadable codes).

Philosophy: More Than a Matrix

What makes QR codes elegant is their balance between redundancy and compression. They:

• Handle data loss gracefully with Reed-Solomon error correction
• Encode multiple formats (text, binary, etc.)
• Remain visually consistent while encoding vastly different content

In an embedded system, this philosophy matches our priorities: reliability, compactness, and clarity. With LVGL, you can embed this visual language into your UI effortlessly.

LVGL QR Code Integration Limitations

While the QR code widget in LVGL provides a convenient interface for rendering QR codes, it’s important to be aware of its design constraints and lack of configurability, especially if you need finer control for production-level applications.

🔚Conclusion

LVGL’s QR code integration is simple, efficient, and well-suited for many embedded use cases, especially where memory and performance matter.

It gets the job done when you need to display a basic QR code, and it integrates cleanly into the LVGL object model using lv_canvas. However, it stops short of offering full control. Features like error correction level, mask pattern selection, quiet zone size, and detailed error feedback are fixed or not exposed. For most developers, this may not be an issue, but for those needing fine-tuned QR generation (e.g., for branding, versioning, or resilience), the current implementation feels limiting.

That said… who knows? Maybe a patch is on the way to bring these missing features to LVGL. Stay tuned 😉

Hard realtime systems is the third axis of competences we have at EDGEMTech.

It concerns all aspects (development, tuning and optimization, porting, debugging, etc.) related to hard realtime systems (mainly x86 and ARM Linux-based systems).

Do not hesitate to contact our expert Daniel Rossier for any advice.

Have you ever thought that x86 would gradually leave the world of embedded systems?

The Sapphire Edge+ VPR-4616-MB is a Mini-ITX motherboard that includes the AMD Versal AI Edge VE2302 device plus an AMD Ryzen Embedded R2314 processor, along with a flexible I/O interface to connect to various peripherals and sensors.

Our Engineers are on hand to give you the necessary expertises in hard realtime systems based on Linux for your new development, if you envisage to start a new product or to port an existing realtime sy

If your embedded system requires real-time constraints, don't worry! The Linux operating system remains a top choice. With significant advancements in the upstream RT-PREEMPT extension over the past three years, you can now run applications on isolated CPU cores with minimal latency and jitter.

However, some specific use cases—particularly those requiring hard real-time performance in user-space applications—can be tricky. Combining RT and non-RT tasks in the same environment may lead to interference, and implementing non-GPL closed-source code within the kernel only adds to the complexity.

For these challenges, the EVL (Xenomai 4) extension is a powerful alternative to RT-PREEMPT. Here’s why

:

• Out-of-Band (OOB) Functions: Guarantee hard real-time conditions across execution paths, ensuring deterministic behavior for critical tasks.
• Clean RT/Non-RT Separation: Isolates the real-time domain from standard Linux tasks, minimizing interference.
• Scalable Architecture: Works seamlessly on popular ARM-based SoCs, such as Raspberry Pi, NXP, TI platforms, making it versatile for various embedded projects.
• Hard Real-Time User-Space Applications: Ideal for scenarios where real-time functionality must remain closed-source without relying on kernel modifications.

Whether you're tackling hard real-time constraints, maintaining user-space applications, or working with ARM-based systems, EVL offers an innovative and reliable solution.

It's definitely worth considering for your next project!