Zephyr + Linux on STM32MP2: Solving Memory and Security for Low-Power Operation

Introduction

In the embedded world, the question is no longer which OS should I use, but how can I make them work together?

Modern SoCs are blurring the line between real-time microcontrollers and application processors. Chips like the STM32MP2 from STMicroelectronics integrate both a Cortex-A35, capable of running a full Linux distribution, and a Cortex-M33, designed for deterministic, low-latency real-time tasks. Two cores, one chip: the best of both worlds.

This hybrid architecture is increasingly relevant for industrial applications. Consider a few common scenarios:

• • Safety: a real-time core can monitor sensors and trigger safety responses with guaranteed latency, independently of what the application OS is doing.
  • Low-power: the application processor can be suspended to save energy while the real-time core continues to monitor the environment and decide when to wake the system up.
  • Offloading: hard real-time acquisition tasks (ADC sampling, sensor polling, motor control, etc.) live on the M33, while heavy processing, like FFT, AI inference, UI rendering, runs on the A35 under Linux.

However, this power comes with a cost: having two operating systems share the same chip introduces non-trivial configuration challenges: memory layout, security boundaries, and inter-core synchronization all need to be carefully coordinated across every layer of the stack.

Our demo focuses on the low-power scenario: Zephyr runs on the Cortex-M33, continuously reading sensor data and managing the i2c display, while Linux on the Cortex-A35 handles heavier processing and can be put to sleep and woken up transparently, without losing a single sample. What follows documents exactly what it took to make that work.

Demo Overview

The demo runs on a STM32MP257F-DK board and is split across two runtimes that communicate via OpenAMP over a shared memory region.

Zephyr: The Real-Time Side (Cortex-M33)

Zephyr owns the real-time responsibilities:

• Data acquisition (hc-sr04): data is fetched continuously, with strict timing guarantees.
• RT Displaying (ssd1306): real-time sensor values are displayed in the dedicated screen, giving immediate visual feedback independent of Linux.
• OpenAMP master: Zephyr acts as the OpenAMP master, initiating and managing the communication channel with Linux.

Linux: The Application Side (Cortex-A35)

Linux handles the heavier, less time-critical workload:

• Qt6 application: a graphical interface shows date/time to simulate computationally intensive data processing. The kind of task that would be unreasonable on a microcontroller.
• OpenAMP via serial: Linux communicates with Zephyr through the OpenAMP virtual serial interface, receiving sensor data for processing and display.
• libgpiod application: monitors the User-1 button to trigger entry into low-power sleep mode (s2idle).
• Wake-up trigger: a physical interrupt to WAKE-UP button brings the system back from sleep, resuming Linux and re-establishing communication with Zephyr.

OPTEE-OS: The security configuration (Cortex-A35)

OP-TEE is a TEE (Trusted Execution Environment), which runs in the A35 ARM TrustZone. It is responsible for the initialization of security peripherals like the RIF that we will see below.

The goal: demonstrate a credible low-power embedded system where Linux can sleep and wake up, while Zephyr seamlessly keeps running and buffering data.

The Challenge Behind: Memory Configuration between the cores

State of the Art: The STM32MP2 Security Model and Power Mode

• An open RIF configuration devicetree (which can be found in the OPTEE-OS in-tree files), no strict peripheral lockdown, suitable for a development/demo context.
• A custom Buildroot system aligned with the latest OpenSTLinux release, ensuring compatibility with upstream version.

Regarding the power mode, with the v6.2.0 of OpenSTLinux, the most low-power mode we can reach with the SoC is the LP_Stop2 mode (see in the table below). In this mode, the VDDCPU (vdd of the A35) is OFF and the DDR is in self-refresh mode. The self-refresh mode refers to the mode where the DDR retains data with very low consumptions, but it cannot be accessed. Only the VDDCORE (vdd of the m33) is kept ON.

The Sleep Mode and the Memory Problem

When Linux loads the Zephyr firmware onto the M33 via remoteproc, the firmware binary is placed in DDR by default, as specified in the Linux device tree. That works fine in the usual setup. But when the system enters deep sleep, the DDR goes into self-refresh mode. The M33 then tries to reach the DDR which completely breaks the system triggering a panic error.

To resolve this issue, the firmware should use another memory which is kept alive during the A35 sleep mode. So the SRAM1 and RETRAM have been selected. But even in the open RIF configuration, the SRAM1 is configured for Secure usage. So all Linux, OPTEE-OS and Zephyr devicetrees need to be updated to reflect these changes.

The fix is a three-layer change:

1. Move the M33 firmware to SRAM1 and RETRAM (Linux device tree)

The remoteproc memory region is redirected from DDR to SRAM1 and RETRAM, which remains powered during sleep. The memory-region of the m33_rproc node is updated to reflect the change:

2. Grant non-secure world access to SRAM1 (OP-TEE device tree)

3. Configure Zephyr to link against SRAM1 and RETRAM addresses (Zephyr devicetree overlay)

The OpenAMP Vring Problem

The solution: a SLEEP/WAKE handshake.

• Before entering deep sleep, Linux sends a SLEEP signal to Zephyr over OpenAMP.
• Zephyr receives the signal, acknowledges it, and takes over full responsibility: it continues reading
  sensor data and buffers it locally. Zephyr stops sending data through OpenAMP.
• After waking up, Linux sends a WAKE signal.
• Zephyr flushes its buffer back to Linux, restoring continuity of data as if the sleep never happened.

This approach keeps DDR usage minimal during active operation, allows a clean sleep mode, and ensures no data is lost across the sleep boundary.

Conclusion

The system works. Linux sleeps, Zephyr keeps sampling, and when Linux wakes up, it gets back every data point it missed.

The more interesting takeaway is what it took to get there: a coordinated change spanning the Linux device tree, the OP-TEE security configuration, and Zephyr’s linker map. None of these three layers is hard in isolation, however, together they form a pattern you will encounter on any heterogeneous SoC where power management and inter-core communication need to coexist.

One last note on the demo setup: sleep is triggered by a physical button press, which makes it easy to demonstrate on stage. In a real product, that button can be replaced by any interrupt source (for e.g., a distance threshold detected by Zephyr itself and signalled to Linux over OpenAMP, a timer, an external GPIO, etc). The sleep/wake handshake described here is agnostic to the trigger, so the architecture supports autonomous operation without modification.