Reset device tree configuration

Applicable for

1. Article purpose[edit | edit source]

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

The peripheral can be assigned to different contexts/software components, depending on the final product needs. Refer to How to assign an internal peripheral to an execution context article for guidelines on this configuration .

2. Reset controller providers[edit | edit source]

There are 2 reset controller providers in STM32MP1. Each are represented by node(s) in the device tree description. Their node must define a value for specifier #reset-cells.

STM32MP1 RCC reset controllers, most of the system reset controllers actually.
SCMI reset domains are reset controllers registered by the SCMI drivers.
The STM32MP1 uses SCMI reset domains to abstract RCC secure reset controllers.

This article describes the device configuration where RCC TZEN ("security support" chapter) security hardening is enabled.

3. DT bindings documentation[edit | edit source]

The device tree binding documents are stored either in the given applicable components listed below, or in the Linux kernel repository:

As RCC internal peripheral is both a reset and a clock controller, the device tree binding is same document.

TF-A BL2:
- for STM32MP13x lines docs/devicetree/bindings/clock/st,stm32mp13-rcc.txt
- for STM32MP15x lines docs/devicetree/bindings/clock/st,stm32mp1-rcc.txt

OP-TEE:
- for STM32MP13x lines documentation/devicetree/bindings/clock/st,stm32mp13-rcc.yaml
- for STM32MP15x lines Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml

U-Boot, Linux^® OS:
- for STM32MP1 Series Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml

See also the SCMI device tree configuration.

4. DT configuration[edit | 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.

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

The RCC 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.

4.2. DT configuration (board level)[edit | edit source]

If a Linux driver needs a reset signal, it should be declared in its DT node as shown below:

resets = <phandle> : List of phandle and reset specifier pairs, one pair for each reset signal that affects the device, or that the device manages.

Example with non secured device:

i2c2: i2c@40013000 {
	compatible = "st,stm32f7-i2c";
	reg = <0x40013000 0x400>;
	clocks = <&rcc I2C2_K>;
	resets = <&rcc I2C2_R>;
       ...
};

Example with secured device:

i2c4: i2c@5c002000 {
	compatible = "st,stm32f7-i2c";
	reg = <0x5c002000 0x400>;
	clocks = <&scmi_clk CK_SCMI_I2C4>;
	resets = <&scmi_reset RST_SCMI_I2C4>;
       ...
};

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

The STM32CubeMX tool can be used to configure the STM32MP1 device and get the corresponding platform configuration device tree files.
The STM32CubeMX may not support all the properties described 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, which are preserved from one generation to another. Refer to STM32CubeMX user manual for further information.

6. References[edit | edit source]

Please refer to the following links for additional information: