1. Article purpose[edit source]
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[edit source]
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"[1]
- Linux® BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt[2]
- Linux® generic NVMEM devicetree bindings: Documentation/devicetree/bindings/nvmem/nvmem.txt[3]
3. DT configuration[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 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)[edit source]
The STM32MP1 BSEC node is located in stm32mp157c.dtsi[4] (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)[edit source]
3.2.1. STM32MP1 BSEC node append - ecosystem release ≥ v1.2.0[edit source]
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 - ecosystem release ≤ v1.1.0[edit source]
Board definition in Device tree may add some OTP declarations, specific to the board:
&bsec {
board_id: board_id@ec {
reg = <0xec 0x4>;
status = "okay";
secure-status = "okay";
};
};
Please refer to next section below for the "status" and "secure-status" definitions.
3.2.3. STM32MP1 BSEC node append (bootloader specific) - ecosystem release ≥ v1.2.0[edit source]
The bootloader specific STM32MP1 BSEC node append data is located in stm32mp157c-security.dtsi[5] (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 0x8>;
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, using "st,non-secure-otp" property, with a 32-bit length granularity (i.e. 4 bytes). No more spare field declaration here.
3.2.4. STM32MP1 BSEC node append (bootloader specific) - ecosystem release ≤ v1.1.0[edit source]
The bootloader specific STM32MP1 BSEC node append data is located in stm32mp157c-security.dtsi[5] (see Device tree for more explanations).
&bsec {
mac_addr: mac_addr@e4 {
reg = <0xe4 0x6>;
status = "okay";
secure-status = "okay";
};
/* Spare field to align on 32-bit OTP granularity */
spare_ns_ea: spare_ns_ea@ea {
reg = <0xea 0x2>;
status = "okay";
secure-status = "okay";
};
};
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 status = "okay" (OTP can be accessed in non secure, declared as an exception), and with secure-status = "okay" (OTP can be accessed in secure, normal behavior).
3.2.5. STM32MP1 driver node append[edit source]
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 stm32mp157c.dtsi[6] 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.6. STM32MP1 nvmem_layout node (bootloader specific) - ecosystem release ≥ v1.2.0[edit source]
The STM32MP1 nvmem_layout node gathers all NVMEM platform-dependent layout information, including OTP names and phandles, in order to allow easy accesses for data consumers, using pre-defined string in nvmem-cell-names property.
nvmem_layout: nvmem_layout@0 {
compatible = "st,stm32mp1-nvmem-layout";
nvmem-cells = <&part_number_otp>,
<&monotonic_otp>,
<&nand_otp>,
<&uid_otp>,
<&package_otp>,
<&hw2_otp>,
<&board_id>;
nvmem-cell-names = "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.
4. How to configure the DT using STM32CubeMX[edit source]
The STM32CubeMX tool can be used to configure the STM32MPU 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 and they are preserved from one generation to another. Refer to STM32CubeMX user manual for further information.
5. References[edit source]
Please refer to the following links for additional information:
- ↑ docs/devicetree/bindings/soc/st,stm32-romem.txt TF-A BSEC binding information file
- ↑ Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
- ↑ Documentation/devicetree/bindings/nvmem/nvmem.txt
- ↑ fdts/stm32mp157c.dtsi (for TF-A): STM32MP157C device tree files
- ↑ 5.0 5.1 fdts/stm32mp157c-security.dtsi (for TF-A): STM32MP157C device tree files
- ↑ arch/arm/boot/dts/stm32mp157c.dtsi