1. Article purpose[edit | edit source]
The purpose of this article is to explain how to configure the BSEC using the device tree mechanism, relying on the bindings documentation, that is the description of the required and optional device-tree properties.
2. DT bindings documentation[edit | edit source]
Generic information about NVMEM is available in the NVMEM overview.
The device tree binding documents for BSEC are stored either in the given applicable components listed below, or in the Linux kernel repository:
- TF-A BL2:
- OP-TEE:
- STM32 BSEC device tree bindings: documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
- U-Boot, Linux® OS:
- STM32 BSEC device tree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
- generic NVMEM devicetree bindings: Documentation/devicetree/bindings/nvmem/nvmem.yaml , Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
3. 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.
3.1. DT configuration (STM32/SoC level)[edit | edit source]
The BSEC node and NVMEM node are located in the device tree file for the software components, supporting the peripheral and listed in the above DT bindings documentation paragraph.
3.2. DT configuration (board level)[edit | edit source]
The objective of this chapter is to explain how to enable and configure the BSEC DT nodes for a board.
Peripheral configuration should be done in specific board device tree files (board dts file).
3.2.1. BSEC node append[edit | edit source]
The board definition in the device tree may include some additional board-specific OTP declarations, for example to add a NVMEM data cell:
&bsec {
calib@20 {
reg = <0x20 0x2>;
};
board_id: board_id@ec {
reg = <0xec 0x4>;
st,non-secure-otp;
};
oem_enc_key@170 {
reg = <0x170 0x10>;
st,non-secure-otp-provisioning;
};
};
Only lower OTP (32 on STM32MP1 series and 128 on STM32MP2 series) 32-bit data words are accessible by the non-secure world by default; OP-TEE needs to manage exceptions in BSEC PTA to allow some upper OTPs to be accessed by the non-secure world, through secure world services for very specific needs as described in documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml .
This exceptions are defined by the OTP declaration in the secure world device tree with a 32-bit length granularity (that is, 4 bytes):
- using the st,non-secure-otp property to allow a read/write
- using the st,non-secure-otp-provisioning property to allow a write until the first programmed value or permanent lock; used for secrets used by secure world but provisioned by the non-secured world.
See example core/arch/arm/dts/stm32mp135f-dk.dts .
4. How to configure the DT using STM32CubeMX[edit | 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. References[edit | edit source]
Please refer to the following links for additional information:
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 