BSEC device tree configuration

This page is a candidate for renaming (move). The requested new name is: BSEC device tree configuration . The supplied reason is: FGA W1929: - NVMEM refers to Linux non-volatile memory framework FGA W1929: - This device tree article is specific to BSEC (NVMEM can apply for variety of EEPROM, OTPs...) FGA W1929: - This device tree article isn't specific to the bootloader. It's also based on & contains information used by the Linux/NVMEM BSEC driver. . -- Registered User (-) 15:05, 18 July 2019 (CEST). Wiki maintainers: remember to update the pages that link this page before renaming (moving) it.

1. Article purpose

Warning

This article explains how to configure BSEC at boot time.

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

2. DT bindings documentation

Generic information about NVMEM is available in NVMEM overview.

This binding document 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.txt

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 stm32mp157c.dtsi (see Device tree for more explanations).

 / {
 ...
 	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>;
 			};
 			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>;
 			};
 		};
 ...
 	};
 ...
 };

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

3.2. DT configuration (board level)

3.2.1. STM32MP1 BSEC node append

Board definition in Device tree may add some OTP declarations, specific to the board:

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

Please refer to next section below for the "st,non-secure-otp" definition.

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 more explanations).

This completes NVMEM data providers, only for bootloader specific purpose, either for a driver, or the platform istself:

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

As observed just above, 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, with "st,non-secure-otp" property.

3.2.3. STM32MP1 driver node append (bootloader specific)

Driver can directly consume NVMEM data cells, as described in NVMEM overview.
The NAND driver is a good example, with a dedicated OTP containing memory device information.
The driver node append data is located in stm32mp157c-ev1.dts, simply because NAND is not present in all hardware configurations. So it's easier to add it manually here.

 &fmc {
 ...
 	nand: nand@0 {
 		...
 		nvmem-cells = <&nand_otp>;
 		nvmem-cell-names = "nand_otp";
 	};
 };

With this new properties, the NAND driver can easily find the OTP number, in order to access all memory information.
Please refer to FMC_device_tree_configuration for more explanations.

3.2.4. STM32MP1 platform_config node (bootloader specific)

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

 platform_config: platform_config@0 {
 	compatible = "st,stm32mp1-platform-config";
 	nvmem-cells = <&part_number_otp>,
 		      <&monotonic_otp>,
 		      <&uid_otp>,
 		      <&package_otp>,
 		      <&hw2_otp>,
 		      <&board_id>;
 	nvmem-cell-names = "part_number_otp",
 			   "monotonic_otp",
 			   "uid_otp",
 			   "package_otp",
 			   "hw2_otp",
 			   "board_id";
 };

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

4. References

Please refer to the following links for additional information:

Template:ArticleMainWriter

Boot and Security and OTP control

Linux^® is a registered trademark of Linus Torvalds.

Electrically-erasable programmable read-only memory

Device tree

One time programmed