RIFSC internal peripheral

Applicable for

1. Article purpose[edit | 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 | edit source]

The RIFSC (RIF Security Controller) peripheral is the control interface of the RIF (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 , 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, Cortex-M33®, and Cortex®-M0+.

Main RIFSC configuration is under TDCID processor responsibility, but all execution contexts can read it. Moreover, it is possible to modify the 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 the security level of this resource.
A privilege execution context owning a resource can modify the 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 | edit source]

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

3.1. Boot time assignment[edit | edit source]

As soon as the STM32MP2 is powered up, the Cortex®-A35 starts to execute the ROM code, which configures and verifies the RIFSC configuration to ensure the isolation of its execution. It then executes the FSBL TF-A in secure mode, which can temporarily 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 accesses the RIFSC to verify if a resource can be accessed by Cortex®-A35 non-secure execution. If required, U-Boot can acquire the RIF semaphore associated with the resource to grant the access.

3.1.1. On STM32MP2 series[edit | edit source]

Click on to expand or collapse the legend...

⬚ 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.
☐ 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.
✓ 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
Domain	Peripheral	Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)	Comment
Security	RIFSC	RIFSC	✓	☑	☑

3.2. Runtime assignment[edit | 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 the selected peripherals to be assigned to the different hardware execution context of the platform before their execution. Firmware running on the other execution contexts accesses RIFSC to verify if they can access a peripheral before trying to program it.

3.2.1. On STM32MP25x lines [edit | edit source]

Click on 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, but this configuration is not supported in STM32 MPU Embedded Software distribution.
☐ 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.
✓ 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
Domain	Peripheral	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+ (STM32Cube)	Comment
Security	RIFSC	RIFSC	☑^OP-TEE	⬚	☐	☐

4. Software frameworks and drivers[edit | edit source]

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

Linux^®:
- Firewall bus driver
- Firewall bus header
U-Boot:
- RIFSC driver
- RIF header
OP-TEE:
TF-A:
- RIFSC driver
TF-M:
- platform/ext/target/stm/common/devicetree/include/dt-bindings/rif/stm32mp25-rifsc.h
- platform/ext/target/stm/common/stm32mp2/native_driver/src/rif/stm32_rifsc.c

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

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

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