Zephyr + Linux sur STM32MP2: Résoudre la mémoire et la sécurité pour une opération à faible consommation

Introduction

Dans le monde de l’embarqué, la question n’est plus de savoir quel OS utiliser, mais comment les faire fonctionner ensemble ?

Les SoC modernes estompent la frontière entre les microcontrôleurs temps réel et les processeurs d’application. Des puces comme le STM32MP2 de STMicroelectronics intègrent à la fois un Cortex-A35, capable d’exécuter une distribution Linux complète, et un Cortex-M33, conçu pour des tâches temps réel déterministes et à faible latence. Deux cœurs, une seule puce : le meilleur des deux mondes.

Cette architecture hybride est de plus en plus pertinente pour les applications industrielles. Considérons quelques scénarios courants :

• • Sécurité : un cœur temps réel peut surveiller les capteurs et déclencher des réponses de sécurité avec une latence garantie, indépendamment de ce que fait l’OS applicatif.
  • Faible consommation : le processeur applicatif peut être mis en veille pour économiser de l’énergie tandis que le cœur temps réel continue de surveiller l’environnement et décide quand réveiller le système.
  • Délestage : les tâches d’acquisition temps réel critiques (échantillonnage ADC, interrogation de capteurs, contrôle de moteur, etc.) s’exécutent sur le M33, tandis que les traitements lourds, comme la FFT, l’inférence IA ou le rendu UI, s’exécutent sur l’A35 sous Linux.

Cependant, cette puissance a un coût : avoir deux systèmes d’exploitation partageant la même puce introduit des défis de configuration non triviaux : la disposition de la mémoire, les frontières de sécurité et la synchronisation inter-cœurs doivent toutes être soigneusement coordonnées à chaque niveau de la pile.

Notre démo se concentre sur le scénario de faible consommation : Zephyr s’exécute sur le Cortex-M33, lisant en continu les données des capteurs et gérant l’affichage i2c, tandis que Linux sur le Cortex-A35 gère les traitements plus lourds et peut être mis en veille et réveillé de manière transparente, sans perdre un seul échantillon. Ce qui suit documente exactement ce qu’il a fallu faire pour que cela fonctionne.

 [L’introduction est en français, le reste du texte en anglais]

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.