1. Article purpose[edit source]
The purpose of this article is to describe the different requirements on system configuration (RIF, RCC) to guarantee a correct execution of the ROM code in all the supported execution contexts.
2. Introduction[edit source]
The STM32MP2 ROM code is executed in different contexts:
- Cold boot to load the FSBL-A or the FSBL-M depending on main processor selection. In this context, Cortex-M33 and other master peripherals are under reset.
- Standby exit to reload FSBL-A and restart Cortex-A35. In this context, Cortex-M33 and other master peripherals are under reset. But part of the system is initialized (Mainly RIF)
- D1Standby exit to (re)load FSBL-A and restart Cortex-A35. In the context, Cortex-M33 and other master peripherals could be running. Moreover system is fully initialized (RIF, RCC...)
Depending on main processor selection (Cortex-A35 TDCID or Cortex-M33 TDCID) ROM code has or not the right to modify system configuration under TDCID responsibility. Moreover ROM code execution shall not impact rest of system during D1Stanby exit sequence.
Some rules on system configuration (RIF, RCC...) must be applied to guarantee STM32MP2 ROM code execution and isolation in the different contexts:
3. ROM code peripheral assignment[edit source]
3.1. Principles[edit source]
ROM code shall be able to access all resources required for its execution whatever ROM execution context (Cold boot, Standby exit and D1 Standby exit).
Depending on ROM code execution context, part of the system could be already configured and running. System configuration should be compliant with ROM code resource needs.
- RIF configuration including RIFSC and RIF-aware peripherals
- RCC clock tree configuration
At each execution ROM code checks resource access rights based on RIF registers (RIFSC and RIF-aware).
Two controls are possible:
Resource control type | What is controlled | How |
---|---|---|
Ensuring direct access | The ROM code first checks that either resource access rights are not set, or are statically assigned to A35 ; if yes it sets resource security level according to its needs. Indeed security level used by SW ecosystem could be different from ROM code one. | The ROM code checks that either CID filtering is not configured, or is configured static and assigned to the A35. If yes it sets resource security level according to its needs. |
Checking access | The ROM code first checks that resource security level correspond to its needs, then it checks that either resource is statically assigned to A35, or that resource is shared via its semaphore, and semaphore can be taken within 10 ms. | The ROM code first checks that resource security level ; then it checks that either CID filtering is configured static and assigned to the A35, or CID filtering is configured dynamic (meaning resource is shared via a semaphore) and semaphore can be taken within 10 ms. |
3.2. Secure peripherals[edit source]
The ROM code always does a "check access" control on these peripherals:
Peripheral | RIF resource number | RIF block | Comment | Secure level checked |
---|---|---|---|---|
BSEC | R103 | RCC | 1 | |
BSEC | R70 | RCC | 1 | |
CPU PWR1 | R2 | PWR | power control | 1 |
STGEN | R33 | RCC | flexgen | 1 |
CPU1 | R70 | RCC | lowpwr,irq,iwdg,reset regs access | 1 |
In case of secure boot when the chip is in CLOSED-LOCKED state, the ROM code always does a "check access" control on these peripherals:
Peripheral | RIF resource number | RIF block | Secure level checked |
---|---|---|---|
RNG | R92 | RIFSC | 1 |
PKA | R93 | RIFSC | 1 |
SAES | R94 | RIFSC | 1 |
HASH | R95 | RIFSC | 1 |
CRYP1 | R96 | RIFSC | 1 |
SYSRAM/RISAB2 | R74 | RCC | 1 |
BSEC | R103 | RCC | 1 |
CA35SS | R106 | RCC | 1 |
3.3. Non-secure peripherals[edit source]
ROM code is ensuring and checking access to the non-secure peripherals used during its execution.
ROM code adapt list of non-secure peripherals according to selected boot source.
3.3.1. SDMMC1 access ensure[edit source]
Checked in the following boot selection:
- Cortex-A35 main processor
- Boot from eMMC SDMMC1
- Boot from SD-Card SDMMC1
- Cortex-M33 main processor single boot device
- Boot from eMMC SDMMC1
- Boot from SD-Card SDMMC1
- Cortex-M33 main processor dual boot device
- Boot Cortex-M33 from sNOR and Cortex-A35 from eMMC SDMMC1
- Boot Cortex-M33 from sNOR and Cortex-A35 from SD-Card SDMMC1
- Boot Cortex-M33 from Hyperflash and Cortex-A35 from eMMC SDMMC1
- Boot Cortex-M33 from Hyperflash and Cortex-A35 from SD-Card SDMMC1
The following table list resources associated to SDMMC1.
Function | RIF resource number | RIF block | Resource description | Secure level checked |
---|---|---|---|---|
Root Clock SDMMC1 | R51 | RCC | Flexgen 51 | 0 |
Clock GPIOE | R94 | RCC | GPIO E clock config | 0 |
IO voltage protection | R6 | PWR | VDDIO1 (PWR_C8) | 1 |
GPIO PE3 | R3 | GPIOE | SDMMC1_CK | 0 |
GPIO PE2 | R2 | GPIOE | SDMMC1_CMD | 0 |
GPIO PE4 | R4 | GPIOE | SDMMC1_D0 | 0 |
SDMMC1 | R76 | RIFSC | SDMMC1 controller | 0 |
3.3.2. SDMMC2 access ensure[edit source]
Checked in the following boot selection:
- Cortex-A35 main processor
- Boot from eMMC SDMMC2
- Boot from SD-Card SDMMC2
- Cortex-M33 main processor single boot device
- Boot from eMMC SDMMC2
- Boot from SD-Card SDMMC2
- Cortex-M33 main processor dual boot device
- Boot Cortex-M33 from sNOR and Cortex-A35 from eMMC SDMMC2
- Boot Cortex-M33 from sNOR and Cortex-A35 from SD-Card SDMMC2
- Boot Cortex-M33 from Hyperflash and Cortex-A35 from eMMC SDMMC2
- Boot Cortex-M33 from Hyperflash and Cortex-A35 from SD-Card SDMMC2
The following table list resources associated to SDMMC2.
Function | RIF resource number | RIF block | Resource description | Secure level checked |
---|---|---|---|---|
Root Clock SDMMC2 | R52 | RCC | Flexgen 52 | 0 |
Clock GPIOE | R94 | RCC | GPIO E clock config | 0 |
IO voltage protection | R5 | PWR | VDDIO2 (PWR_C7) | 1 |
GPIO PE14 | R14 | GPIOE | SDMMC2_CK | 0 |
GPIO PE15 | R15 | GPIOE | SDMMC2_CMD | 0 |
GPIO PE13 | R13 | GPIOE | SDMMC2_D0 | 0 |
SDMMC2 | R77 | RIFSC | SDMMC1 controller | 0 |
3.3.3. OCTOSPI1 access ensure[edit source]
Coming soon |
Note:
- IOM not reconfigured in D1Standby exit --> right configuration to be done by ecosystem SW
- FMC R0 common register not reconfigured in D1Standby exit --> right configuration to be done by ecosystem SW
4. ROM code secure context isolation[edit source]
4.1. Principles[edit source]
- guarantee that all secure IPs used by ROM code can't preempted by another secure processor running in parallel of the ROM code.
- Guarantee that no bus master processors and peripherals can access ROM code resources (peripheral and memories)
--> No master with CID1 and Secure RIF configuration shall be active during ROM code execution
table droit d'accès avec common + lock in case of M33TD
4.2. Rules Secure peripherals RIF protection[edit source]
table avec resources