This article describes how the STM32MP2 series firewall should be configured to allow STM32 MPU Embedded Software distribution execution.
1. Overview[edit source]
The objective of this articles is to provide guidelines for system firewall configuration taking into account the different platform constraints.
On STM32MP2 series, system firewall to protect internal RAM, external memories and internal peripheral is realized by Resource Isolation Framework.
A minimal coherent RIF configuration is required to execute STM32 MPU Embedded Software distribution and support the different low power modes.
2. RIF initial hardware configuration[edit source]
The RIF is made up of several protection units like described in Resource Isolation Framework overview.
The initial hardware configuration depends on the type of peripheral/memory to protect and their usage by the ROM code.
- RIFSC RISUP protected peripherals: Non-secure, Unprivileged and CID filtering disabled.
- RIFSC RIMU for bus master peripherals: Non-secure, in RISUP inherited CID mode. This implies a CID0 for all bus master peripherals as RISUP initial configuration is CID filtering disabled.
- RISAF protected external memories: Default region0 only accessible by main processor (TDCID) in secure mode (CID1 Secure when Cortex-A35 is the main processor, CID2 secure when Cortex-M33 is the main processor).
- RISAB protected internal memories: No CID filtering, but security level depends on protected memory.
- GPIO: GPIO is RIF-aware. By default, Secure, Unprivileged and no CID filtering.
- RCC: RCC is RIF-aware. By default, Non-secure, Unprivileged and CID filtering disabled.
According to above statement, a minimal RIF configuration should be performed by the secure OS running on main processor (TDCID) to allow a correct and coherent execution for the embedded SW:
- Secure level of GPIO should be aligned with execution level of SW component in charge of IO configuration.
- Secure level of RISAB should be aligned with execution level of SW component in charge of IO configuration.
- RISAF regions should be programmed to allow the different bus master.
3. ROM code constraints[edit source]
The STM32MP25x lines 
ROM code which is running on Cortex-A35, shall be certified SESIP level3. This implies a certain number of security and isolation rules to guarantee ROM code execution:
- All secure and non secure HW resources required by ROM code shall be accessible respectively to the Cortex-A35 secure and non-secure each time the ROM code is executed (cold boot, application reset, low power exit).
- RIFSC RISUP configuration associated to ROM code resources shall allow Cortex-A35 access
- It shall not be possible to change RIF configuration of secure resources used by ROM code during its execution.
- When Cortex-M33 is the main processor (TDCID), RIFSC RISUP configuration associated to ROM code secure resources must be locked.
- No active bus master peripheral shall have same RIF configuration as Cortex-A35 secure context executing secure ROM code.
- If a RIFSC RIMU of a bus master peripheral is defined as Secure and CID1, its associated clock must be disabled during ROM code execution.
ROM code is checking RIFSC and RISAB1&2 (dedicated to SYSRAM protection) configurations. If one setting doesn't match ROM code requirements, ROM code stops its execution and goes in failure.
4. STM32MPU Embedded Software default configuration[edit source]
STM32MPU Embedded Software proposes a default ecosystem configuration that:
- enables Cortex-A35 and Cortex-M33 secure OS
- enables isolation between Cortex-A35 and Cortex-M33
- enables LTDC secure layer
- enables authenticated Cortex-M33 coprocessor
To do that, RIF is configured with the following rules:
Device tree configuration is available in external device tree repository.
5. STM32MPU Embedded Software open configuration[edit source]
6. How to configure RIF[edit source]
The memory mapping is defined in each SW component device tree file using Reserved_memory bindings. Customer can change name, based address, size and access rights of each region according to its product needs.
To ensure the consistency of the system, memory declarations of each SW component have to be updated according to the expected configuration.
ST recommends to use CubeMX tools to generate coherent memory mapping with associated access rights.