RISAF device tree configuration

Applicable for

1. Article purpose[edit source]

The purpose of this article is to explain how to configure the RISAF peripheral using the device tree mechanism, relying on the bindings documentation, that is the description of the required and optional device-tree properties.

The RISAF peripheral configuration can only be done by the CPU running in TDCID mode.

2. DT bindings documentation[edit source]

The RISAF driver will configure the memory regions referenced in the "memory-region" property. Those regions' security configuration resides in the "st,protreg" property and they must be within the memory range defined by the "st,mem-map" property..

The device tree binding documents are stored either in the given applicable components listed below:

OP-TEE:
- Reserved-memory device tree bindings: Memory region and its RIF configuration
- RISAF device tree bindings RISAF bindings

3. DT configuration[edit source]

This hardware description is a combination of the STM32 microprocessor device tree files (.dtsi extension) and board device tree files (.dts extension). See the Device tree for an explanation of the device-tree file organization.

STM32CubeMX can be used to generate the board device tree. Refer to How to configure the DT using STM32CubeMX for more details.

RISAF is used to assign memory regions and sub regions to one or more security domains (secure, privilege, compartment). The definition of these regions/sub regions resides in the board-resmem device tree file and their secure configuration resides in the board-rif device tree file. Both are fully customizable.

Information

Note: For now, RISAF sub regions are not supported.

3.1. DT configuration (STM32/SoC level)[edit source]

The RISAF node is located in the device tree file for the software components supporting the peripheral and listed in the above DT bindings documentation paragraph.

Warning

This device tree part is related to STM32 microprocessors. It must be kept as is, without being modified by the end-user.

The RISAF nodes are defined at SoC device file level as:

 //Comments
 
 risaf1: risaf@420a0000 {
       compatible = "st,stm32mp25-risaf";
       reg = <0x420a0000 0x1000>;
       clocks = <&rcc CK_BUS_BKPSRAM>;
       st,mem-map = <0x0 0x42000000 0x0 0x2000>;      //Memory range covered by the RISAF (8KBytes BKPSRAM)
 };
 ...
 risaf4: risaf@420d0000 {
       compatible = "st,stm32mp25-risaf-enc";      //Indicates that the RISAF instance supports encryption
       reg = <0x420d0000 0x1000>;
       clocks = <&rcc CK_BUS_RISAF4>;
       st,mem-map = <0x0 0x80000000 0x1 0x00000000>;      //Memory range covered by the RISAF (4GBytes DDR)
 };

3.2. DT configuration (board level)[edit source]

The objective of this chapter is to explain how to enable and configure the RISAF DT nodes for a board.

Memory regions and security configurations should be done in specific board device tree files (board-resmem (regions) board-rif (secure configuration))

3.2.1. DT configuration (board level) - board device tree[edit source]

Most of the RISAF instances are default enabled at SoC level. RISAF 2 (OCTOSPI) and RISAF 5 (PCIE) instances should be enabled at board level as some boards may not implement these features.

 &risaf2 {
       status = "okay";
 };
 
 &risaf5 {
       status = "okay";
 };

3.2.2. DT configuration (board level) - resmem board device tree[edit source]

This device tree file contains all board dependent reserved memory nodes declaration. All memory regions under RISAF protection should be declared here. Example for a RISAF 4 topology:

 /* DDR reserved memory declaration */
 tfm_code: tfm-code@80000000 {
       reg = <0x0 0x80000000 0x0 0x100000>;
       no-map;
 };
 
 cm33_cube_fw: cm33-cube-fw@80100000 {
       reg = <0x0 0x80100000 0x0 0x800000>;
       no-map;
 };
 
 tfm_data: tfm-data@80900000 {
       reg = <0x0 0x80900000 0x0 0x100000>;
       no-map;
 };
 
 cm33_cube_data: cm33-cube-data@80a00000 {
       reg = <0x0 0x80a00000 0x0 0x800000>;
       no-map;
 };
 
 ipc_shmem: ipc-shmem@81200000 {
       reg = <0x0 0x81200000 0x0 0x100000>;
       no-map;
 };
 
 spare1: spare1@81300000 {
       reg = <0x0 0x81300000 0x0 0xcc0000>;
       no-map;
 };
 
 bl31_context: bl31-context@81fc0000 {
       reg = <0x0 0x81fc0000 0x0 0x40000>;
       no-map;
 };
 
 op_tee: op-tee@82000000 {
       reg = <0x0 0x82000000 0x0 0x2000000>;
       no-map;
 };
 
 linuxkernel: linuxkernel@84000000 {
       reg = <0x0 0x84000000 0x0 0x76800000>;
       no-map;
 };
 
 gpu_reserved: gpu-reserved@fa800000 {
       reg = <0x0 0xfa800000 0x0 0x4000000>;
       no-map;
 };
 
 ltdc_sec_layer: ltdc-sec-layer@fe800000 {
       reg = <0x0 0xfe800000 0x0 0x800000>;
       no-map;
 };
 
 ltdc_sec_rotation: ltdc-sec-rotation@ff000000 {
       reg = <0x0 0xff000000 0x0 0x1000000>;
       no-map;
 };
 
 linuxkernel2: linuxkernel2@100000000 {
       reg = <0x1 0x00000000 0x0 0x80000000>;
       no-map;
 };

Notice that there's no secure configuration present in this extract.

Information

The topology of the memory zones and the number/size of each zone are fully customizable as long as the regions do not overlap and are within the memory range defined in the st,mem-map property of the RISAF.

Warning

Changing the topology of these zones may require an update of configuration in the associated software components.

3.2.3. DT configuration (board level) - secure configuration board device tree[edit source]

This device tree file contains all board customizable security configurations . All memory regions that one wishes to configure and enable should appear in this file. Example for a RISAF 4 memory zone configuration:

 //Comments
 ...
 &bl31_context {
       st,protreg = <RISAFPROT(RISAF_REG_ID(7), RIF_CID1_BF, RIF_CID1_BF, RIF_CID1_BF, RIF_SEC, RIF_ENC_EN, RIF_BREN_EN)>;
 };
 
  //OP-TEE zone (ID:8) is enabled, encrypted, secure and accessible in read/write/priv/npriv by CID1 and CID0
 &op_tee {
       st,protreg = <RISAFPROT(RISAF_REG_ID(8), RIF_CID1_BF, RIF_CID1_BF, RIF_UNUSED, RIF_SEC, RIF_ENC_EN, RIF_BREN_EN)>;
 };
 
 &linuxkernel1 {
       st,protreg = <RISAFPROT(RISAF_REG_ID(9), RIF_CID1_BF|RIF_CID4_BF, RIF_CID1_BF|RIF_CID4_BF, RIF_UNUSED, RIF_NSEC, RIF_ENC_DIS, RIF_BREN_EN)>;
 };
 
 &gpu_reserved {
       st,protreg = <RISAFPROT(RISAF_REG_ID(10), RIF_CID1_BF|RIF_CID4_BF, RIF_CID1_BF|RIF_CID4_BF, RIF_UNUSED, RIF_NSEC, RIF_ENC_DIS, RIF_BREN_EN)>;
 };
 
 ...
 //All the memory zones covered by the RISAF 4 that will be configured by its driver
 &risaf4 {
       memory-region= <&tfm_code>, <&cm33_cube_fw>, <&tfm_data>, <&cm33_cube_data>, <&ipc_shmem>, <&spare1>, <&bl31_context>, <&op_tee>, <&linuxkernel1>, <&gpu_reserved>, <&ltdc_sec_layer>, <&ltdc_sec_rotation>, <&linuxkernel2>;
 };

Information

If a zone is not referenced in the memory-region property, it will not be configured by the RISAF driver and will inherit from the RISAF primary region configuration configuration which is fixed to secure, privileged and TDCID accesses only.

Information

For more information on the RISAFPROT macro, please refer to the RISAFPROT section of the Memory region bindings

4. How to configure the DT using STM32CubeMX[edit source]

The STM32CubeMX tool can be used to configure the STM32MPU device and get the corresponding platform configuration device tree files.
STM32CubeMX may not support all the properties described in DT binding files listed in the above DT bindings documentation paragraph. If so, the tool inserts user sections in the generated device tree. These sections can then be edited to add some properties, and they are preserved from one generation to another. Refer to STM32CubeMX user manual for further information.

5. Debug the configuration[edit source]

It is possible to dump the RISAF configurations using a Debugfs entry in the Linux kernel. Each probed RISAF instance will have an associated entry in the debugfs. To learn more on this subject, please visit: RIF configuration dump in Linux kernel

6. References[edit source]

Refer to the following links for additional information: RIF overview