BSEC device tree configuration

1 Article purpose

Warning

This article explains how to configure BSEC at boot time.

This article describes the BSEC configuration performed using the device tree mechanism, which provides a hardware description of the BSEC peripheral.

2 DT bindings documentation

Generic information about NVMEM is available in the NVMEM overview.

The following binding-related documentation explains how to write device tree files for BSEC:

• TF-A: tf-a/docs/devicetree/bindings/soc/st,stm32-romem.txt"
• Linux^® BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
• Linux^® generic NVMEM devicetree bindings: Documentation/devicetree/bindings/nvmem/nvmem.txtyaml and Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml

3 DT configuration

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 split.

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 level)

The STM32MP1 BSEC node is located in stm32mp157cthe file stm32mp151.dtsi4 (see Device tree for further explanation).

 / {
 ...
 	soc {
 ...
 		bsec: nvmem@5c005000 {
 			compatible = "st,stm32mp15-bsec";
 			reg = <0x5c005000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
  
 			part_number_otp: part_number_otp@4 {
 				reg = <0x4 0x1>;
 			};
 			ts_cal1: calib@5c {
 				reg = <0x5c 0x2>;
 			};
 			ts_cal2: calib@5e {
 				reg = <0x5e 0x2>;
 			};
 		};
 ...
 	};
 ...
 };

Please refer to the NVMEM overview for the bindings common with the Linux^® kernel.

3.2 DT configuration (board level)

3.2.1 STM32MP1 BSEC node append

Board The board definition in the device tree may add include some additional board-specific OTP declarations:

For ecosystem release ≥ v1.2.0

 &bsec {
 	board_id: board_id@ec {
 		reg = <0xec 0x4>;
 		st,non-secure-otp;
 	};
 };

With only 32 lower NVMEM 32-bit data words, the software needs to manage exceptions in order to allow some upper OTPs to be accessed by the non-secure world, through secure world services for very specific needs. User The user can add an OTP declaration in the device tree, using the "st,non-secure-otp" property, with a 32-bit length granularity (i.e. that is, 4 bytes).

For ecosystem release v1.1.0

 &bsec {
 	board_id: board_id@ec {
 		reg = <0xec 0x4>;
 		status = "okay";
 	};
 };

The upper OTPs are intended to contain sensitive data such as keys or passwords. However, with only 32 lower NVMEM 32-bit data words, the software may need more. It is therefore possible, for very specific needs, to manage exceptions in order to allow some upper OTPs to be accessed by the non-secure world through secure-world services.
The user can add upper OTP declarations in the device tree by using the status property to define accessibility conditions, as described in the following table:

status	Upper OTP available from
disabled	secure only (normal behavior)
okay	non-secure and secure (exception)

Information

When status property is not filled, this is implicitly set as an "okay" status by default.

Information

secure-status property can appear in some OTP declarations, please don't care.

For ecosystem release v1.0.0

 &bsec {
 	board_id: board_id@ec {
 		reg = <0xec 0x4>;
 	};
 };

As in the previous section, exceptions are managed, but they are only checked in the case of closed_device BSEC mode. In open_device mode, all upper-OTP non-secure accesses are allowed. See STM32MP15 reference manuals for more information about these modes.