Last edited 6 months ago

RIFSC internal peripheral

Applicable for STM32MP25x lines

1. Article purpose[edit source]

The purpose of this article is to:

  • briefly introduce the RIFSC peripheral and its main features,
  • indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
  • list the software frameworks and drivers managing the peripheral,
  • explain how to configure the peripheral.

2. Peripheral overview[edit source]

The RIFSC (RIF Security Controller) peripheral is the control interface of the Resource Isolation Framework. It provides configuration registers to:

  • define access right (CID, secure and privilege level) for each peripheral protected by a RISUP
  • define initiator peripheral bus behavior by setting CID, secure and privilege level (RIMU)
  • define low power RAM memory protection (RISAL)
  • define JTAG DAP configuration

On STM32MP25x lines More info.png, there are:

  • 118 RISUP to protect the different instances of peripherals. RISUP default configuration is non-secure, unprivileged and CID filtering disabled.
  • 16 RIMU, one in front of each bus initiator peripheral (ETR, SDMMC1, SDMMC1, SDMMC3, USB3DR, USBH, ETH1, ETH2, GPU, LTDC, VDEC and VENC). By default RIMU are set in non-secure, unprivileged and CID inheritance from associated peripheral RISUP (except for ETR and LTDC for which inheritance is not possible).
  • 3 RISAL to protect LPSRAM1, LPSRAM2 and LPSRAM3. By default LPSRAM accesses are defined as non-secure, unprivileged and Cortex-M33 and Cortex-M0+.

Main RIFSC configuration is under TDCID processor responsibility, but all execution context can read it. Moreover it is possible to modify RISUP configuration according to following rules:

  • Only the TDCID execution context can modify the CID filtering configuration of this resource
  • A secure execution context owning a resource can modify security level of this resource
  • A privilege execution context owning a resource can modify privilege level of this resource

The RIFSC configuration is preserved in low power mode.

Refer to the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

3. Peripheral usage[edit source]

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm® Cortex®-A processor(s), and the STM32CubeMPU Package running on the Arm® Cortex®-M processor.

3.1. Boot time assignment[edit source]

As soon as the STM32MP2 is powered up, The Cortex-A35 starts to execute the ROM code which configures and verifies RIFSC configuration to guarantee the isolation of its execution. It then executes the FSBL TF-A in secure mode which can temporally reconfigure some Cortex-A35 assigned peripherals from non-secure to secure to be compliant with its execution model. The SSBL U-Boot executed in non-secure mode will access RIFSC to verify a resource could be accessed by Cortex-A35 non-secure execution. If required, U-Boot can acquire the RIF semaphore associated to the resource to grant the access.

3.1.1. On STM32MP2 series[edit source]

Click on How to.png to expand or collapse the legend...

  • means that the peripheral can be assigned to the given boot time context.
  • means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.

Domain Peripheral Boot time allocation Comment How to.png
Instance Cortex-A35
secure
(ROM code)
Cortex-A35
secure
(TF-A BL2)
Cortex-A35
non-secure
(U-Boot)
Security RIFSC RIFSC

3.2. Runtime assignment[edit source]

In Cortex-A35 main processor mode, the Cortex-A35 is the TDCID processor which means Cortex-A35 secure execution can completely configure the RISFC. In this mode OP-TEE is in charge of the RISFC configuration before the startup of the other execution context. This allows to assign the selected peripherals to the different HW execution context of the platform before their execution. Firmware running on the other execution contexts will access RIFSC to verify if they can access to a peripheral before trying to program it.

3.2.1. On STM32MP25x lines More info.png[edit source]

Click on How to.png to expand or collapse the legend...

STM32MP25 internal peripherals

Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:

  • means that the peripheral can be assigned to the given runtime context.
  • means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32MP25 reference manuals.

Domain Peripheral Runtime allocation Comment How to.png
Instance Cortex-A35
secure
(OP-TEE /
TF-A BL31)
Cortex-A35
non-secure
(Linux)
Cortex-M33
secure
(TF-M)
Cortex-M33
non-secure
(STM32Cube)
Cortex-M0+
Warning.png
(STM32Cube)
Security RIFSC RIFSC OP-TEE

4. Software frameworks and drivers[edit source]

Below are listed the software frameworks and drivers managing the RIFSC peripheral for the embedded software components listed in the above tables.

5. How to assign and configure the peripheral[edit source]

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
According to selected assignment, STM32CubeMX is generating the RIFSC device tree configuration that will be programmed by the secure OS running on the TDCID processor.
This tool also helps to enable the peripheral support in the different SW components by generating:

  • partial device trees enabling selected peripherals for the OpenSTLinux software components,
  • HAL initialization code for the STM32CubeMPU Package for selected peripherals.

6. References[edit source]