Registered User mNo edit summary |
Registered User m (remove comment after discussion with Nathalie) Tag: 2017 source edit |
||
| (47 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
{{ApplicableFor | |||
|MPUs list=STM32MP15x, STM32MP21x, STM32MP23x, STM32MP25x | |||
|MPUs checklist=STM32MP13x, STM32MP15x, STM32MP21x, STM32MP23x, STM32MP25x | |||
}} | |||
{{TrustedDomainApplicability | TDflavor = M33-TD| applicable = no}} | |||
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. | 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. | ||
== System overview== | == System overview== | ||
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: | 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<sup>®</sup> Cortex<sup>®</sup>-A processor optimized to run the Linux<sup>®</sup> based OS. | ||
* | * An Arm<sup>®</sup> Cortex<sup>®</sup>-M processor to run a RTOS optimized for microcontrollers or a bare-metal application. | ||
* | * '''Internal or External memories''' with access granted for both CPU cores processors: | ||
** To load and execute | ** To load and execute processor firmware images. | ||
** To share buffers for inter processing communication through a messaging infrastructure. | ** To share buffers for inter processing communication through a messaging infrastructure. | ||
* [[IPCC internal peripheral| | * An [[IPCC internal peripheral|inter-processor communication controller]] peripheral allowing a signaling system by a dedicated mailbox. | ||
* | * '''Internal peripheral resources''' that can be assigned to one of the processors. | ||
[[File:copro-hw-overview.png|link=]] | [[File:copro-hw-overview.png|900px|link=]] | ||
==Functional features and design== | ==Functional features and design== | ||
In order to manage the | In order to manage the remote processor, 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. | ||
These frameworks are introduced in chapters below with links to dedicated articles for further explanation. | |||
[[File:copro-sw-overview.png|link=]] | [[File:copro-sw-overview.png|900px|link=]] | ||
{{Info | The '''stm32_m0_rproc''' driver is specifically designed for the Cortex<sup>®</sup>-M0+ for use with {{ApplicableFor/CategoryAssignment | STM32MP25x}} }} | |||
===Load and control the Cortex-M firmware=== | ===Load and control the Cortex-M firmware=== | ||
The Linux OS integrates the[[Linux remoteproc framework overview | RemoteProc]] framework that allows to load firmware and control remote processors. | The Linux OS integrates the[[Linux remoteproc framework overview | RemoteProc]] framework that allows to load firmware and control remote processors. | ||
===Resources management (for shared peripheral, clocks, GPIOs...)=== | ===Resources management (for shared peripheral, clocks, GPIOs...)=== | ||
==== {{MicroprocessorDevice | device=15}} ==== | |||
The [[Resource_manager_for_coprocessing | resource manager]] proposes services to manage common resources and avoid any conflict. | The [[Resource_manager_for_coprocessing | 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_internal_peripheral| ETZPC]] table. | * '''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_internal_peripheral| ETZPC]] table. | ||
:* On Cortex-A: At boot time, the ETZPC and Linux device tree are configured according to the [[TF-A_overview|TF-A]]<sup>®</sup> device tree (refer to [[How to assign an internal peripheral to | :* On Cortex-A: At boot time, the ETZPC and Linux device tree are configured according to the [[TF-A_overview|TF-A]]<sup>®</sup> 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. | :* On Cortex-M: the service is implemented by the '''Resource manager''' utilities. | ||
* ''' | * ''' Remote processor resource configuration set''': services available in the Cortex<sup>®</sup>-A, running Linux, to configure the system resources needed to operate the peripheral on the Cortex<sup>®</sup>-M. The service is implemented by '''rproc_srm'''<ref name="rproc_srm_core.c">{{CodeSource | Linux kernel | drivers/remoteproc/rproc_srm_core.c| resource manager core driver rproc_srm_core.c}}</ref> <ref name="rproc_srm_dev.c">{{CodeSource | Linux kernel | drivers/remoteproc/rproc_srm_dev.c| resource manager device driver rproc_srm_dev.c}}</ref> drivers. | ||
==== {{MicroprocessorDevice | device=2}} ==== | |||
At boot time the [[Resource_Isolation_Framework_overview | resource isolation framework (RIF)]] configure the system to manage common resources and to assign/isolate/share peripherals. | |||
===Inter processor communication=== | ===Inter processor communication=== | ||
Inter processor communication is based on '''RPMsg''' framework and '''Mailbox''' mechanisms. | Inter processor communication is based on '''RPMsg''' framework and '''Mailbox''' mechanisms. | ||
==== RPMSG framework ==== | |||
*On Cortex-A: | [[File:copro-sw-ipc-overview.png|900px|link=]] | ||
:* The [[Linux remoteproc framework overview | RemoteProc]] framework is in charge of enabling the IPC on Linux side, based on information available in the firmware [[ | |||
*On Cortex<sup>®</sup>-A: | |||
:* The [[Linux remoteproc framework overview | RemoteProc]] framework is in charge of enabling the IPC on Linux side, based on information available in the firmware [[Interprocessor communication – resource table | resource table]]. | |||
:* The RPMsg service is implemented by the [[Linux RPMsg framework overview| RPMsg]] framework. | :* The RPMsg service is implemented by the [[Linux RPMsg framework overview| RPMsg]] framework. | ||
:* The | :* The mailbox service is implemented by the [[Linux Mailbox framework overview| stm32_ipcc mailbox ]] framework. | ||
*On Cortex-M: | *On Cortex<sup>®</sup>-M: | ||
:* The RPMsg service is implemented by the [ | :* The RPMsg service is implemented by the [https://www.openampproject.org OpenAMP] library. | ||
:* The Mailbox service is implemented by the HAL_IPCC driver. | :* Some RPMsg virtual drivers (TTY, I2C, INTC, ...) are implemented in the {{CodeSource | STM32CubeMP1 | Middlewares/Third_Party/OpenAMP/virtual_driver}}({{MicroprocessorDevice | device=15}}) and {{CodeSource | STM32CubeMP2 | Middlewares/Third_Party/OpenAMP/virtual_driver}}({{MicroprocessorDevice | device=2}}) | ||
:* The Mailbox service is implemented by the {{CodeSource | STM32CubeMP1 | Middlewares/Third_Party/OpenAMP/mw_if/platform_if/mbox_ipcc_template.c}}({{MicroprocessorDevice | device=15}}) and {{CodeSource | STM32CubeMP2 | Middlewares/Third_Party/OpenAMP/mw_if/platform_if/mbox_ipcc_template.c}}({{MicroprocessorDevice | device=2}}). | |||
==== Mailbox client interface==== | |||
[[File:copro-sw-ipc-mailbox-overview.png|900px|link=]] | |||
*On Cortex<sup>®</sup>-A: | |||
:* The mailbox client char device<ref>{{CodeSource | Linux kernel | drivers/mailbox/mailbox-client_cdev.c}}</ref> is in charge of providing a /dev/mailbox<0> user space interface to communicate with the Cortex<sup>®</sup>-M, relying on a memory region and the mailbox service. | |||
:* The mailbox service is implemented by the [[Linux Mailbox framework overview| stm32_ipcc mailbox ]] driver. | |||
*On Cortex<sup>®</sup>-M: | |||
:* The application directly accesses to the shared memory. | |||
:* The mailbox service is implemented by the HAL_IPCC driver. | |||
{{Info| In the [[#Embedded software|STM32 MPU Embedded Software distribution]], the Mailbox client interface is used for communication with the Cortex<sup>®</sup>-M0+ on {{MicroprocessorDevice | device=2}}. This interface could also be utilized for communication with the Cortex<sup>®</sup>-M33 ({{MicroprocessorDevice | device=2}}) or Cortex<sup>®</sup>-M4 ({{MicroprocessorDevice | device=15}}). }} | |||
==References== | |||
<references /> | |||
<noinclude> | <noinclude> | ||
Latest revision as of 10:10, 1 July 2025
 Trusted domain applicability
|
This article is not applicable to M33-TD flavor  of STM32MP2 series
|
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 processor optimized to run the Linux® based OS.
- An Arm® Cortex®-M processor to run a RTOS optimized for microcontrollers or a bare-metal application.
- Internal or External memories with access granted for both CPU cores processors:
- To load and execute processor firmware images.
- 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 one of the processors.
2. Functional features and design[edit | edit source]
In order to manage the remote processor, 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.
| Information
|
| The stm32_m0_rproc driver is specifically designed for the Cortex®-M0+ for use with STM32MP25x lines |
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.
- Remote processor resource configuration set: services available in the Cortex®-A, running Linux, to configure the system resources needed to operate the peripheral on the Cortex®-M. The service is implemented by rproc_srm[1] [2] drivers.
2.2.2. STM32MP2 series[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.
2.3.1. RPMSG framework[edit | edit source]
- 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 framework.
- 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 (STM32MP2 series)
- The Mailbox service is implemented by the Middlewares/Third_Party/OpenAMP/mw_if/platform_if/mbox_ipcc_template.c (STM32MP15x lines ) and Middlewares/Third_Party/OpenAMP/mw_if/platform_if/mbox_ipcc_template.c (STM32MP2 series).
2.3.2. Mailbox client interface[edit | edit source]
- On Cortex®-A:
- The mailbox client char device[3] is in charge of providing a /dev/mailbox<0> user space interface to communicate with the Cortex®-M, relying on a memory region and the mailbox service.
- The mailbox service is implemented by the stm32_ipcc mailbox driver.
- On Cortex®-M:
- The application directly accesses to the shared memory.
- The mailbox service is implemented by the HAL_IPCC driver.
| Information
|
| In the STM32 MPU Embedded Software distribution, the Mailbox client interface is used for communication with the Cortex®-M0+ on STM32MP2 series. This interface could also be utilized for communication with the Cortex®-M33 (STM32MP2 series) or Cortex®-M4 (STM32MP15x lines ).
|
3. References[edit | edit source]
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 