This article provides an overview of the management of the heterogeneous asymmetric architecture implemented in the STM32 MPU microprocessor family. It provides information on mechanisms put in place to help developers to design software in the multiprocessor system.
1. System overview[edit | edit source]
The STM32 MPU multiprocessor system allows to run independent firmwares on each CPU core. The below subsystems are involved in the management of the coexistence of the two CPU subsystems:
- An Arm® Cortex®-A acting as main processor and optimized to run the Linux® based OS.
- An Arm® Cortex®-M coprocessor which can run the RTOS optimized for microcontrollers or a bare-metal application.
- Internal memory regions with access granted for both the master and/or the slave processors:
- To load and execute coprocessor firmware and define static common structures.
- To share buffers for inter processing communication through a messaging infrastructure.
- An inter-processor communication controller peripheral allowing a signaling system by a dedicated mailbox.
- Internal peripheral resources that can be assigned to the master or the slave processor.
2. Functional features and design[edit | edit source]
In order to manage the coprocessor system, a list of services is proposed relying on the open-source RemoteProc and RPMsg frameworks. These frameworks are introduced in chapters below with links to dedicated articles for further explanation.
2.1. Load and control the Cortex-M firmware[edit | edit source]
The Linux OS integrates the RemoteProc framework that allows to load firmware and control remote processors.
[edit | edit source]
2.2.1. STM32MP15x lines 
[edit | edit source]
The resource manager proposes services to manage common resources and avoid any conflict.
- Peripheral assignment request: the mechanism used to ensure that a peripheral is reserved for a processor usage. The principle is that a firmware requests the peripheral before starting to use it, relying on the ETZPC table.
- On Cortex-A: At boot time, the ETZPC and Linux device tree are configured according to the TF-A® device tree (refer to How to assign an internal peripheral to an execution context for details).
- On Cortex-M: the service is implemented by the Resource manager utilities.
- Coprocessor resource configuration set: services available in the main processor (Cortex-A running Linux) to configure the system resources needed to operate the peripheral on the coprocessor. The service is implemented by rproc_srm[1] [2] drivers.
2.2.2. STM32MP25x lines [edit | edit source]
At boot time the resource isolation framework (RIF) configure the system to manage common resources and to assign/isolate/share peripherals.
2.3. Inter processor communication[edit | edit source]
Inter processor communication is based on RPMsg framework and Mailbox mechanisms.
- On Cortex-A:
- The RemoteProc framework is in charge of enabling the IPC on Linux side, based on information available in the firmware resource table.
- The RPMsg service is implemented by the RPMsg framework.
- The Mailbox service is implemented by the stm32_ipcc mailbox driver.
- On Cortex-M:
- The RPMsg service is implemented by the OpenAMP library.
- Some RPMsg virtual drivers (TTY, I2C,INTC,...) are implemented in the Middlewares/Third_Party/OpenAMP/virtual_driver (STM32MP15x lines ) and Middlewares/Third_Party/OpenAMP/virtual_driver (STM32MP25x lines )
- The Mailbox service is implemented by the HAL_IPCC driver.
3. References[edit | edit source]
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.