BSEC device tree configuration

Applicable for

STM32MP13x lines, STM32MP15x lines

---

1 Article purpose

Warning This article explains

The purpose of this article is to explain how to configure

BSEC at boot time.

This article describes the BSEC configuration performed using the device tree mechanism, which provides a hardware relying on the bindings documentation, that is the description of the BSEC peripheralrequired and optional device-tree properties.

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 binding documents for BSEC are stored either in the given applicable components listed below, or in the Linux kernel repository:

• TF-A : tf-a/BL2:
  • for example: docs/devicetree/bindings/soc/st,stm32-romem.txt
  "Linux^® BSEC devicetree
• OP-TEE:
  • for example: STM32 BSEC device tree bindings: documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
• U-Boot, Linux^® OS:
  • for example: STM32 BSEC device tree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.
  txtLinux^®
  • yaml
  • for example: generic NVMEM devicetree bindings: Documentation/devicetree/bindings/nvmem/nvmem.
  txt
  • yaml , 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 splitorganization.

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)

The STM32MP1 BSEC node is located in stm32mp157c.dtsi (see Device tree for further explanation).

 / {
 ...
 	soc {
 ...
 		bsec: nvmem@5c005000 {
 			compatible = "st,stm32mp15-bsec";
 			reg = <0x5c005000 0x400>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			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 Linux^® kernel.

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.

Warning

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

3.2 DT configuration (board level)

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

, 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;
 	};
 };

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

For ecosystem release v1.1.0

&bsec { board_id: board_id@ec

	oem_enc_key@170 {
 		reg = 

<0xec

<0x170 

0x4>

0x10>;
 		

status = "okay"

st,non-secure-otp-provisioning;
 	};
 };

The upper OTPs are intended to contain sensitive data such as keys or passwords. However, with only

Only the 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

are accessible by the non-secure world by default; the secure world software (OP-TEE or SP-MIN) needs to manage exceptions 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.

3.2.2 STM32MP1 BSEC node append (bootloader specific)

The bootloader-specific STM32MP1 BSEC node append data is located in stm32mp157c-security.dtsi (see Device tree for further explanation).
This completes NVMEM data providers, only for bootloader specific purpose, either for a driver, or the platform itself.

For ecosystem release ≥ v1.2.0

 &bsec {
 	cfg0_otp: cfg0_otp@0 {
 		reg = <0x0 0x1>;
 	};
 	part_number_otp: part_number_otp@4 {
 		reg = <0x4 0x1>;
 	};
 	monotonic_otp: monotonic_otp@10 {
 		reg = <0x10 0x4>;
 	};
 	nand_otp: nand_otp@24 {
 		reg = <0x24 0x4>;
 	};
 	uid_otp: uid_otp@34 {
 		reg = <0x34 0xc>;
 	};
 	package_otp: package_otp@40 {
 		reg = <0x40 0x4>;
 	};
 	hw2_otp: hw2_otp@48 {
 		reg = <0x48 0x4>;
 	};
 	mac_addr: mac_addr@e4 {
 		reg = <0xe4 0x8>;
 		st,non-secure-otp;
 	};
 };

Please find the "st,non-secure-otp" definition in the previous section above. No more spare field declaration here.

For ecosystem release ≤ v1.1.0

 &bsec {
 	mac_addr: mac_addr@e4 {
 		reg = <0xe4 0x6>;
 	};
 	/* Spare field to align on 32-bit OTP granularity  */
 	spare_ns_ea: spare_ns_ea@ea {
 		reg = <0xea 0x2>;
 	};
 };

3.2.3 STM32MP1 driver node append

The driver can directly consume NVMEM data cells, as described in NVMEM overview.
The ADC_TEMP device is a good example, with a dedicated OTP containing calibration information.
The device node is located in the stm32mp157c.dtsi file.

 adc_temp: temp {
 	compatible = "st,stm32mp1-adc-temp";
 	io-channels = <&adc2 12>;
 	nvmem-cells = <&ts_cal1>, <&ts_cal2>;
 	nvmem-cell-names = "ts_cal1", "ts_cal2";
 	#io-channel-cells = <0>;
 	#thermal-sensor-cells = <0>;
 	status = "disabled";
 };

With these nvmem-cells / nvmem-cell-names properties, the ADC_TEMP device can easily find the OTP number, in order to access calibration information.

3.2.4 STM32MP1 nvmem_layout node (bootloader specific) for ecosystem release ≥ v1.2.0

The STM32MP1 nvmem_layout node gathers all NVMEM platform-dependent layout information, including OTP names and phandles, in order to allow easy access for data consumers, using pre-defined string in nvmem-cell-names property.

 nvmem_layout: nvmem_layout@0 {
 	compatible = "st,stm32mp1-nvmem-layout";
 	nvmem-cells = <&cfg0_otp>,
 		      <&part_number_otp>,
 		      <&monotonic_otp>,
 		      <&nand_otp>,
 		      <&uid_otp>,
 		      <&package_otp>,
 		      <&hw2_otp>,
 		      <&board_id>;
 	nvmem-cell-names = "cfg0_otp",
 			   "part_number_otp",
 			   "monotonic_otp",
 			   "uid_otp",
 			   "nand_otp",
 			   "package_otp",
 			   "hw2_otp",
 			   "board_id";
 };

With this new node, the platform can easily find the OTP numbers, in order to access all necessary information.

world services for very specific needs as described in documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml .

Warning

These upper OTP 32-bit length words are ECC-protected. To avoid an invalid ECC, computed after a second write operation, these 64 upper OTPs should be be permanent write locked when they are programmed.

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

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 the documents DT binding files listed in the above DT bindings documentation above paragraph. If so, the tool inserts user sections in the generated device tree. These sections can then be edited to add some properties that , and they are preserved from one generation to another. Refer to the STM32CubeMX user manual for further information.

5 References

Please refer to the following links for additional information: