1. Article purpose[edit | edit source]
This article explains how to configure the software that assigns a peripheral to a runtime and/or boot time context.
 Information
|
The assignment concept remains the same for the whole STM32MP1 series but the Arm®-Cortex®-M4 execution context and STM32Cube components are only available on STM32MP15x lines  , so ones should ignore them while reading this article in STM32MP13x lines perspective
|
2. Introduction[edit | edit source]
A peripheral can be assigned to a runtime context and/or a boot time context via the configuration defined in the device tree. The device tree can be either generated by the STM32CubeMX tool or edited manually.
2.1. On STM32MP1 series[edit | edit source]
The assignment can be strengthened by an hardware mechanism: the ETZPC internal peripheral, which is configured by the OP-TEE secure OS. The ETZPC internal peripheral isolates the peripherals for the Cortex-A secure or the Cortex-M context. The peripherals assigned to the Cortex-A non-secure context are visible from any context, without any isolation.
The components running on the platform after OP-TEE execution (such as U-Boot, Linux and STM32Cube) must have a configuration that is consistent with the assignment and the isolation configurations.
The components running on the platform before OP-TEE execution (such as TF-A bootloader) are not impacted by EZPC configuration.
2.2. On STM32MP2 series[edit | edit source]
The assignment can be strengthened by an hardware mechanism: the RIF firewall The RIF internal peripheral isolates the peripherals for the:
- Arm dual core Cortex-A35 secure (Trustzone), running ROM code and TF-A BL2 at boot time, and running OP-TEE and/or TF-A BL31 at runtime
- Arm dual core Cortex-A35 non secure , running U-Boot at boot time, and running Linux at runtime
- Arm Cortex-M33 secure (Trustzone), running TF-M
- Arm Cortex-M33 non-secure , running STM32Cube
The following sections describes how to configure software components accordingly.
3. STM32CubeMX generated assignment[edit | edit source]
3.1. On STM32MP1 series[edit | edit source]
The screenshot below shows the STM32CubeMX user interface:
- I2C2 peripheral is selected, on the left
- I2C2 Mode and Configuration panel, on the right, shows that this I2C instance can be assigned to the Cortex-A7 non-secure or the Cortex-M4 (that is selected) runtime context
- I2C mode is enabled in the drop down menu
| Information
|
| The context assignment table is displayed inside each peripheral Mode and Configuration panel but it is possible to display it for all the peripherals in the Options menu via the Show contexts option |
The GENERATE CODE button, on the top right, produces the following:
- The OP-TEE device tree with the ETZPC configuration that isolates the I2C2 instance (in the example) for the Cortex-M4 context.
- The U-Boot device tree widely inherited from the Linux one, just below
- The Linux kernel device tree with the I2C node disabled for Linux and enabled for the coprocessor
- The STM32Cube project with I2C2 HAL initialization code
The Manual assignment section, just below, illustrates what STM32CubeMX is generating as it follows the same example.
| Information
|
| In addition of this generation, the user may have to manually complete the system resources configuration in the user sections embedded in the STM32CubeMX generated device tree. Refer to How to configure system resources for details. |
3.2. On STM32MP2 series[edit | edit source]
Please refer directly to the STM32CubeMX user manual by clicking to help or F1 in the CubeMX user interface. Then go to RIF configuration chapter.
4. Manual assignment[edit | edit source]
This section gives step-by-step instructions, per software components, to manually perform the peripherals assignments.
It takes the same I2C2 example as the previous section, that showed how to use STM32CubeMX, in order to make the move from one approach to the other easier.
4.1. On STM32MP1 series[edit | edit source]
4.1.1. OP-TEE[edit | edit source]
The assignment follows the ETZPC device tree configuration, with below possible values:
- DECPROT_S_RW for the Cortex-A7 secure (Secure OS like OP-TEE)
- DECPROT_NS_RW for the Cortex-A7 non-secure (Linux)
- As stated earlier in this article, there is no hardware isolation for the Cortex-A7 non-secure so this value allows accesses from any context
- DECPROT_MCU_ISOLATION for the Cortex-M4 (STM32Cube)
Example:
@etzpc: etzpc@5C007000 {
st,decprot = <
DECPROT(STM32MP1_ETZPC_I2C2_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
>;
};
| Information
|
| The value DECPROT_NS_RW can be used with DECPROT_LOCK as last parameter. In Cortex-M4 context, this specific configuration allows the generation of an error in the resource manager utility while trying to use on Cortex-M4 side a peripheral that is assigned to the Cortex-A7 non-secure context. If DECPROT_UNLOCK is used, then the utility allows the Cortex-M4 to use a peripheral that is assigned to the Cortex-A7 non-secure context. |
Moreover, the OP-TEE OS may use STM32MP1 resources. OP-TEE STM32MP1 drivers register the device driver they intend to use in a secure context according to OP-TEE device tree. Only devices with device tree property "status = "okay"" are probed.
In the example, as I2C2 is assigned to Cortex-M4 context, I2C2 node should be disabled in OP-TEE device tree:
&i2c2 {
status = "disabled";
}
4.1.2. U-Boot[edit | edit source]
Each assignable peripheral is declared in the U-Boot device tree.
If a peripheral is not assigned to Cortex-A7 non-secure context, its node should be disabled.
Example:
&i2c2 {
status = "disabled";
};
| Information
|
| U-Boot does not perform any check with regards to ETZPC configuration before accessing to a peripheral. In case of inconsistency an illegal access is generated. |
| Information
|
| U-Boot checks the consistency between ETZPC isolation configuration and Linux kernel device tree configuration to guarantee that Linux kernel do not access an unauthorized device. In order to avoid the access to an unauthorized device, the U-Boot fixes up the Linux kernel device tree to disable the peripheral nodes which are not assigned to the Cortex-A7 non-secure context. |
4.1.3. Linux kernel[edit | edit source]
Each assignable peripheral is declared twice in the Linux kernel device tree for STM32MP15x lines :
- Once in the soc node from arch/arm/boot/dts/st/stm32mp151.dtsi , corresponding to Linux assigned peripherals
- Example: i2c2
- Once in the m4_rproc node from arch/arm/boot/dts/st/stm32mp15-m4-srm.dtsi , corresponding to the Cortex-M4 context. Those nodes are disabled, by default.
- Example: m4_i2c2
In the board device tree file (*.dts), each assignable peripheral has to be enabled only for the context to which it is assigned, in line with TF-A configuration.
As a consequence, a peripheral assigned to the Cortex-A7 secure has both nodes disabled in the Linux device tree.
Example:
&i2c2 {
status = "disabled";
};
...
&m4_i2c2 {
status = "okay";
};
| Information
|
| In addition of this assignment, the user may have to complete the system resources configuration in the device tree nodes. Refer to How to configure system resources for details. |
4.1.4. STM32Cube[edit | edit source]
There is no configuration to do on STM32Cube side regarding the assignment and isolation. Nevertheless, the resource manager utility, relying on ETZPC configuration, can be used to check that the corresponding peripheral is well assigned to the Cortex-M4 before using it.
Example:
int main(void)
{
...
/* Initialize I2C2------------------------------------------------------ */
/* Ask the resource manager for the I2C2 resource */
ResMgr_Init(NULL, NULL);
if (ResMgr_Request(RESMGR_ID_I2C2, RESMGR_FLAGS_ACCESS_NORMAL | \
RESMGR_FLAGS_CPU1, 0, NULL) != RESMGR_OK)
{
Error_Handler();
}
...
if (HAL_I2C_Init(&I2C2) != HAL_OK)
{
Error_Handler();
}
}
4.2. On STM32MP2 series[edit | edit source]
Refer to STM32MP2_firewall_configuration.
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.