Difference between revisions of "BSEC device tree configuration"

[quality revision] [quality revision]
m (update kernel link)
 

1 Article purpose[edit]

Warning.png 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 , which provides a hardware description of the BSEC peripheral.

2 DT bindings documentation[edit]

Generic information about NVMEM is available in the NVMEM overview.

This binding document 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"[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]

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]

The STM32MP1 BSEC node is located in stm32mp157cthe file stm32mp151.dtsi[4] (see Device tree for more explanationsfurther 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)[edit]

3.2.1 STM32MP1 BSEC node append[edit]

Board

The board definition in

Device

the device tree may

add

include some additional board-specific OTP declarations

, specific to the board

:

For ecosystem release v1.1.0 Warning.png

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

Upper OTPs are supposed to contain sensitive data such as keys or passwords. But with

With only 32 lower NVMEM 32-bit data words,

software may need more, so it is possible

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

upper

an OTP declaration in the device tree, using

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)
Info.png When status property is not filled, this is implicitly set as an "okay" status by default.
Info.png secure-status property can appear in some OTP declarations, please don't care.

For ecosystem release v1.0.0 Warning.png

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

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

the "st,non-secure-otp" property, with a 32-bit length granularity (that is, 4 bytes).

3.2.2 STM32MP1 BSEC node append (bootloader specific)[edit]

The bootloader-specific STM32MP1 BSEC node append data is located in

stm32mp157c-security

the file stm32mp151.dtsi [5] for TF-A (see Device tree for

more explanations

further explanation).

&bsec { mac_addr: mac_addr@e4 {

This completes NVMEM data providers, for bootloader-specific purposes only, either for a driver, or the platform itself.

 bsec: nvmem@5c005000 {                                           
 	compatible = "st,stm32mp15-bsec";                        
 	reg = <0x5c005000 0x400>;                                
 	#address-cells = <1>;                                    
 	#size-cells = <1>;                                       
 
 	cfg0_otp: cfg0_otp@0 {                                   
 		reg = 
<0xe4
<0x0 
0x6>
0x1>;                                 
 	};  
/* Spare field to align on 32-bit OTP granularity */ spare_ns_ea: spare_ns_ea@ea { reg = <0xea 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>;                                
 	};                                                       
 	ts_cal1: calib@5c {                                      
 		reg = <0x5c 0x2>;                                
 	};                                                       
 	ts_cal2: calib@5e {                                      
 		reg = <0x5e 0x2>;                                
 	};                                                       
 	pkh_otp: pkh_otp@60 {                                    
 		reg = <0x60 0x20>;                               
 	};                                                       
 	mac_addr: mac_addr@e4 {                                  
 		reg = <0xe4 0x8>;                                
 		st,non-secure-otp;                               
 	};                                                       
 };                           

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

3.2.3 STM32MP1 driver node append[edit]

Driver

The driver can directly consume NVMEM data cells, as described in NVMEM overview.
The

ADC_TEMP

CPU0 device is a good example, with a dedicated OTP containing

calibration

part number information.
The device node is located in

stm32mp157c

the stm32mp151.dtsi[

6

4] file.

 
adc_temp
cpu0: 
temp
cpu@0 {
 	compatible = "
st
arm,
stm32mp1
cortex-
adc-temp
a7";
 	
io-channels
device_type = 
<&adc2 12>
"cpu";
 	reg = <0>;
 	
nvmem-cells
clocks = <&
ts
scmi0_
cal1>, <&ts_cal2>
clk CK_SCMI0_MPU>;
 	
nvmem
clock-
cell-
names = "
ts_cal1", "ts_cal2"
cpu";
 	
#io
operating-
channel
points-
cells
v2 = 
<0>
<&cpu0_opp_table>;
 	
#thermal
nvmem-
sensor-
cells = 
<0>
<&part_number_otp>;
 	
status
nvmem-cell-names = "
disabled
part_number";
 	#cooling-cells = <2>;
 };

With these nvmem-cells / nvmem-cell-names properties, the

ADC_TEMP

CPU0 device can easily find the OTP number, in order to access

calibration

part number information.

3.2.4 STM32MP1 nvmem_layout node (bootloader specific)[edit]

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 the 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>;
  
 	nvmem-cell-names = "cfg0_otp",
 			   "part_number_otp",
 			   "monotonic_otp",
 			   "uid_otp",
 			   "nand_otp",
 			   "package_otp",
 			   "hw2_otp";
 };

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

4 How to configure the DT using STM32CubeMX[edit]

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

documents listed in DT bindings documentation

paragraph

above. If so, the tool inserts user sections in the generated device tree. These sections can then be edited to add some properties

and they

that are preserved from one generation to another. Refer to the STM32CubeMX user manual for further information.

5 References[edit]

Please refer to the following links for additional information:

fdts/stm32mp157c.dtsi (for TF-A): STM32MP157C
  1. 4.0 4.1 arch/arm/boot/dts/stm32mp151.dtsi  : STM32MP151 Linux kernel device tree files
  2. fdts/
stm32mp157c-security (for
  1. STM32MP151 TF-A
): STM32MP157C
  1. device tree files
  • arch/arm/boot/dts/stm32mp157c.dtsi
  • Template:ArticleMainWriter


    == Article purpose ==
    {{Warning|This article explains how to configure [[BSEC_internal_peripheral|BSEC]] at boot time.}}
    
    This article describes the [[BSEC internal peripheral|BSEC]] configuration, which is  performed using the [[Device tree|device tree]] mechanism that, which provides a hardware description of the [[BSEC_internal_peripheral|BSEC]] peripheral.
    
    == DT bindings documentation ==
    
    Generic information about NVMEM is available in the [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].
    This The following binding document-related documentation explains how to write device tree files for BSEC:
    * [[TF-A overview|TF-A]]: ''tf-a/docs/devicetree/bindings/soc/st,stm32-romem.txt"<ref name="st,stm32-romem.txt"> {{CodeSource | TF-A | docs/devicetree/bindings/soc/st,stm32-romem.txt}} [[TF-A overview|TF-A]] BSEC binding information file</ref>
    
    * Linux<sup>&reg;</sup> BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt<ref name="Linux,st,stm32-romem">{{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt}}</ref>
    
    * Linux<sup>&reg;</sup> generic NVMEM devicetree bindings: Documentation/devicetree/bindings/nvmem/nvmem.txt<ref name="nvmem.txt">{{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/nvmem.txt}}</ref>
    
    
    == 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|How to configure the DT using STM32CubeMX]] for more details.
    
    === DT configuration (STM32 level) ===
    The STM32MP1 [[BSEC_internal_peripheral|BSEC]] node is located in ''stm32mp157cthe file ''stm32mp151.dtsi''<ref name="stm32mp157_pinstm32mp151_kernel_dtsi">{{CodeSource | TF-A | fdts/stm32mp157c.dtsi}} (for [[TF-A overview|TF-A]]): STM32MP157CLinux kernel | arch/arm/boot/dts/stm32mp151.dtsi}} : STM32MP151 Linux kernel device tree files</ref> (see [[Device tree]] for more explanationsfurther 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#Device_tree_configuration|NVMEM overview]] for the bindings common with the  Linux<sup>&reg;</sup> kernel.
    
    === DT configuration (board level) ===
    ==== STM32MP1 BSEC node append ====<div class="mw-collapsible-content">
    
    BoardThe board definition in Device the device tree may addinclude some OTP declarations, additional board-specific to the board:
    
    '''For {{EcosystemRelease | revision=1.1.0 | range=and after}}'''OTP declarations:
    &bsec {
      	board_id: board_id@ec {
      		reg = <0xec 0x4>;status = "okay";
      	};
      };
    
    Upper OTPs are supposed to contain sensitive data such as keys or passwords. But with st,non-secure-otp;
      	};
      };
    
    With only 32 lower NVMEM 32-bit data words, the software may need more, so it is possible 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.<br/>
    
    User  The user can add upperan OTP declaration in the device tree, using status property, to define accessibility conditions, as described in the following table:<br/>
    
    {| class="st-table"
    ! status !! Upper OTP available from
    |-
    | disabled || secure only (normal behavior)
    |-
    | okay || non-secure and secure (exception)
    |}
    
    {{Info|When status property is not filled, this is implicitly set as an "okay" status by default.}}
    {{Info|secure-status property can appear in some OTP declarations, please don't care.}}<div class="mw-collapsible mw-collapsed">
    
    '''For {{EcosystemRelease | revision=1.0.0}}'''<div class="mw-collapsible-content">
    
      &bsec {
      	board_id: board_id@ec {
      		reg = <0xec 0x4>;
      	};
      };
    
    As in previous section, exceptions are managed, but they are only checked in case of closed_device [[BSEC internal peripheral|BSEC]] mode. In open_device mode, all upper OTPs non-secure accesses are allowed. See [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for more information about these modes. <br/>
    </div></div>
    
    
    ==== STM32MP1 BSEC node append (bootloader specific) ====
    The bootloader specific STM32MP1 [[BSEC_internal_peripheral|BSEC]] node append data is located in ''stm32mp157c-security.dtsi''<ref name="stm32mp157_security_dtsi">{{CodeSource | TF-A | fdts/stm32mp157c-security.dtsi}} (for [[TF-A overview|TF-A]]): STM32MP157C device tree files</ref> (see [[Device tree]] for more explanations).
    
      &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>;
      	};
      };
    the "st,non-secure-otp" property, with a 32-bit length granularity (that is, 4 bytes).<br/>
    </div></div>
    
    
    ==== STM32MP1 BSEC node append (bootloader specific) ====
    The bootloader-specific STM32MP1 [[BSEC_internal_peripheral|BSEC]] node append data is located in the file ''stm32mp151.dtsi'' <ref name="stm32mp151_tfa_dtsi">{{CodeSource | TF-A | fdts/stm32mp151.dtsi}} STM32MP151 TF-A device tree files</ref> for [[TF-A overview|TF-A]] (see [[Device tree]] for further explanation).<br />
    
    This completes NVMEM data providers, for bootloader-specific purposes only, either for a driver, or the platform itself.
    
      bsec: nvmem@5c005000 {                                           
      	compatible = "st,stm32mp15-bsec";                        
      	reg = <0x5c005000 0x400>;                                
      	#address-cells = <1>;                                    
      	#size-cells = <1>;                                       
    
      	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>;                                
      	};                                                       
      	ts_cal1: calib@5c {                                      
      		reg = <0x5c 0x2>;                                
      	};                                                       
      	ts_cal2: calib@5e {                                      
      		reg = <0x5e 0x2>;                                
      	};                                                       
      	pkh_otp: pkh_otp@60 {                                    
      		reg = <0x60 0x20>;                               
      	};                                                       
      	mac_addr: mac_addr@e4 {                                  
      		reg = <0xe4 0x8>;                                
      		st,non-secure-otp;                               
      	};                                                       
      };                           
    
    Please see the "st,non-secure-otp" definition in the previous section above. No more spare field declaration here.
    ==== STM32MP1 driver node append ====Driver The driver can directly consume NVMEM data cells, as described in [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].<br/>
    
    The ADC_TEMPCPU0 device is a good example, with a dedicated OTP containing calibration part number information.<br/>
    
    The device node is located in ''stm32mp157cthe ''stm32mp151.dtsi''<ref name="stm32mp151_kernel_dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp157c.dtsi}}</ref> 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";</ref> file.
    
      cpu0: cpu@0 {
      	compatible = "arm,cortex-a7";
      	device_type = "cpu";
      	reg = <0>;
      	clocks = <&scmi0_clk CK_SCMI0_MPU>;
      	clock-names = "cpu";
      	operating-points-v2 = <&cpu0_opp_table>;
      	nvmem-cells = <&part_number_otp>;
      	nvmem-cell-names = "part_number";
      	#cooling-cells = <2>;};
    
    With these nvmem-cells / nvmem-cell-names properties, the ADC_TEMPCPU0 device can easily find the OTP number, in order to access calibration part number information.<br/>
    
    
    ==== STM32MP1 nvmem_layout node (bootloader specific) ====
    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 the 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>;
    
      	nvmem-cell-names = "cfg0_otp",
      			   "part_number_otp",
      			   "monotonic_otp",
      			   "uid_otp",
      			   "nand_otp",
      			   "package_otp",
      			   "hw2_otp";
      };
    
    With this new node, the platform can easily find the OTP numbers, in order to access all the necessary information.
    
    ==How to configure the DT using STM32CubeMX==
    The [[STM32CubeMX]] tool can be used to configure the STM32MPU device and get the corresponding [[Device_tree#STM32|platform configuration device tree]] files.<br />
    The STM32CubeMX may not support all the properties described in the above documents listed in [[#DT bindings documentation|DT bindings documentation]] paragraphabove. If so, the tool inserts '''user sections''' in the generated device tree. These sections can then be edited to add some properties and they that are preserved from one generation to another. Refer to the [[STM32CubeMX]] user manual for further information.
    
    ==References==
    Please refer to the following links for additional information:
    <references />
    <noinclude>
    
    [[Category:Device tree configuration]]
    [[Category:Trusted Firmware-A (TF-A)]]
    {{ArticleBasedOnModel | Contributors:Platform security]]
    {{ArticleBasedOnModel | Peripheral or framework device tree configuration model}}
    {{ArticleMainWriter | NicolasLB}}
    {{PublicationRequestId | 13613 |2019-10-09 | }}
    PublicationRequestId | 15044 | 2020-02-21 | 13613 (PhilipS - 2019-10-09))}}</noinclude>
    (28 intermediate revisions by 6 users not shown)
    Line 2: Line 2:
     
    {{Warning|This article explains how to configure [[BSEC_internal_peripheral|BSEC]] at boot time.}}
     
    {{Warning|This article explains how to configure [[BSEC_internal_peripheral|BSEC]] at boot time.}}
       
    This article describes the [[BSEC internal peripheral|BSEC]] configuration, which is performed using the [[Device tree|device tree]] mechanism that provides a hardware description of the [[BSEC_internal_peripheral|BSEC]] peripheral.
    +
    This article describes the [[BSEC internal peripheral|BSEC]] configuration performed using the [[Device tree|device tree]] mechanism, which provides a hardware description of the [[BSEC_internal_peripheral|BSEC]] peripheral.
       
     
    == DT bindings documentation ==
     
    == DT bindings documentation ==
       
    Generic information about NVMEM is available in [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].
    +
    Generic information about NVMEM is available in the [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].
       
    This binding document explains how to write device tree files for BSEC:
    +
    The following binding-related documentation explains how to write device tree files for BSEC:
     
    * [[TF-A overview|TF-A]]: ''tf-a/docs/devicetree/bindings/soc/st,stm32-romem.txt"<ref name="st,stm32-romem.txt"> {{CodeSource | TF-A | docs/devicetree/bindings/soc/st,stm32-romem.txt}} [[TF-A overview|TF-A]] BSEC binding information file</ref>
     
    * [[TF-A overview|TF-A]]: ''tf-a/docs/devicetree/bindings/soc/st,stm32-romem.txt"<ref name="st,stm32-romem.txt"> {{CodeSource | TF-A | docs/devicetree/bindings/soc/st,stm32-romem.txt}} [[TF-A overview|TF-A]] BSEC binding information file</ref>
     
    * Linux<sup>&reg;</sup> BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt<ref name="Linux,st,stm32-romem">{{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt}}</ref>
     
    * Linux<sup>&reg;</sup> BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt<ref name="Linux,st,stm32-romem">{{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt}}</ref>
    Line 14: Line 14:
       
     
    == DT configuration ==
     
    == 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.
    +
    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|How to configure the DT using STM32CubeMX]] for more details.
     
    '''STM32CubeMX''' can be used to generate the board device tree. Refer to [[#How_to_configure_the_DT_using_STM32CubeMX|How to configure the DT using STM32CubeMX]] for more details.
       
     
    === DT configuration (STM32 level) ===
     
    === DT configuration (STM32 level) ===
    The STM32MP1 [[BSEC_internal_peripheral|BSEC]] node is located in ''stm32mp157c.dtsi''<ref name="stm32mp157_pin_dtsi">{{CodeSource | TF-A | fdts/stm32mp157c.dtsi}} (for [[TF-A overview|TF-A]]): STM32MP157C device tree files</ref> (see [[Device tree]] for more explanations).
    +
    The STM32MP1 [[BSEC_internal_peripheral|BSEC]] node is located in the file ''stm32mp151.dtsi''<ref name="stm32mp151_kernel_dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp151.dtsi}} : STM32MP151 Linux kernel device tree files</ref> (see [[Device tree]] for further explanation).
       
     
       / {
     
       / {
    Line 30: Line 30:
     
       #address-cells = <1>;
     
       #address-cells = <1>;
     
       #size-cells = <1>;
     
       #size-cells = <1>;
      +
     
      +
      part_number_otp: part_number_otp@4 {
      +
      reg = <0x4 0x1>;
      +
      };
     
       ts_cal1: calib@5c {
     
       ts_cal1: calib@5c {
     
       reg = <0x5c 0x2>;
     
       reg = <0x5c 0x2>;
    Line 42: Line 46:
     
       };
     
       };
       
    Please refer to [[NVMEM_overview#Device_tree_configuration|NVMEM overview]] for the bindings common with Linux<sup>&reg;</sup> kernel.
    +
    Please refer to the [[NVMEM_overview#Device_tree_configuration|NVMEM overview]] for the bindings common with the  Linux<sup>&reg;</sup> kernel.
       
     
    === DT configuration (board level) ===
     
    === DT configuration (board level) ===
     
    ==== STM32MP1 BSEC node append ====
     
    ==== STM32MP1 BSEC node append ====
    <div class="mw-collapsible-content">
    +
    The board definition in the device tree may include some additional board-specific OTP declarations:
    Board definition in Device tree may add some OTP declarations, specific to the board:
     
       
    '''For {{EcosystemRelease | revision=1.1.0 | range=and after}}'''
     
     
       &bsec {
     
       &bsec {
     
       board_id: board_id@ec {
     
       board_id: board_id@ec {
     
       reg = <0xec 0x4>;
     
       reg = <0xec 0x4>;
       status = "okay";
    +
       st,non-secure-otp;
     
       };
     
       };
     
       };
     
       };
       
    Upper OTPs are supposed to contain sensitive data such as keys or passwords. But with only 32 lower NVMEM 32-bit data words, software may need more, so it is possible 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.<br/>
    +
    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. The user can add an OTP declaration in the device tree, using the "st,non-secure-otp" property, with a 32-bit length granularity (that is, 4 bytes).<br/>
    User can add upper OTP declaration in device tree, using status property, to define accessibility conditions, as described in the following table:<br/>
    +
    </div></div>
    {| class="st-table"
     
    ! status !! Upper OTP available from
     
    |-
     
    | disabled || secure only (normal behavior)
     
    |-
     
    | okay || non-secure and secure (exception)
     
    |}
     
       
    {{Info|When status property is not filled, this is implicitly set as an "okay" status by default.}}
    +
    ==== STM32MP1 BSEC node append (bootloader specific) ====
    {{Info|secure-status property can appear in some OTP declarations, please don't care.}}
    +
    The bootloader-specific STM32MP1 [[BSEC_internal_peripheral|BSEC]] node append data is located in the file ''stm32mp151.dtsi'' <ref name="stm32mp151_tfa_dtsi">{{CodeSource | TF-A | fdts/stm32mp151.dtsi}} STM32MP151 TF-A device tree files</ref> for [[TF-A overview|TF-A]] (see [[Device tree]] for further explanation).<br />
    <div class="mw-collapsible mw-collapsed">
    +
    This completes NVMEM data providers, for bootloader-specific purposes only, either for a driver, or the platform itself.
    '''For {{EcosystemRelease | revision=1.0.0}}'''
    +
     
    <div class="mw-collapsible-content">
    +
      bsec: nvmem@5c005000 {                                         
      &bsec {
    +
      compatible = "st,stm32mp15-bsec";                       
       board_id: board_id@ec {
    +
      reg = <0x5c005000 0x400>;                               
       reg = <0xec 0x4>;
    +
      #address-cells = <1>;                                   
       };
    +
      #size-cells = <1>;                                     
       };
    +
     
      +
      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>;                              
      +
      };                                                     
      +
      ts_cal1: calib@5c {                                     
      +
      reg = <0x5c 0x2>;                               
      +
      };                                                     
      +
      ts_cal2: calib@5e {                                     
      +
      reg = <0x5e 0x2>;                               
      +
      };                                                     
      +
      pkh_otp: pkh_otp@60 {                                   
      +
      reg = <0x60 0x20>;                             
      +
      };                                                     
      +
      mac_addr: mac_addr@e4 {                                 
      +
      reg = <0xe4 0x8>;                               
      +
      st,non-secure-otp;                             
      +
       };                                                      
      +
       };                          
       
    As in previous section, exceptions are managed, but they are only checked in case of closed_device [[BSEC internal peripheral|BSEC]] mode. In open_device mode, all upper OTPs non-secure accesses are allowed. See [[STM32MP15 resources#Reference manuals|STM32MP15 reference manuals]] for more information about these modes. <br/>
    +
    Please see the "st,non-secure-otp" definition in the previous section above. No more spare field declaration here.
    </div></div>
     
       
    ==== STM32MP1 BSEC node append (bootloader specific) ====
    +
    ==== STM32MP1 driver node append ====
    The bootloader specific STM32MP1 [[BSEC_internal_peripheral|BSEC]] node append data is located in ''stm32mp157c-security.dtsi''<ref name="stm32mp157_security_dtsi">{{CodeSource | TF-A | fdts/stm32mp157c-security.dtsi}} (for [[TF-A overview|TF-A]]): STM32MP157C device tree files</ref> (see [[Device tree]] for more explanations).
    +
    The driver can directly consume NVMEM data cells, as described in [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].<br/>
      +
    The CPU0 device is a good example, with a dedicated OTP containing part number information.<br/>
      +
    The device node is located in the ''stm32mp151.dtsi''<ref name="stm32mp151_kernel_dtsi"></ref> file.
       
       &bsec {
    +
       cpu0: cpu@0 {
       mac_addr: mac_addr@e4 {
    +
       compatible = "arm,cortex-a7";
      reg = <0xe4 0x6>;
    +
      device_type = "cpu";
       };
    +
      reg = <0>;
       /* Spare field to align on 32-bit OTP granularity  */
    +
       clocks = <&scmi0_clk CK_SCMI0_MPU>;
       spare_ns_ea: spare_ns_ea@ea {
    +
       clock-names = "cpu";
      reg = <0xea 0x2>;
    +
       operating-points-v2 = <&cpu0_opp_table>;
       };
    +
      nvmem-cells = <&part_number_otp>;
      +
       nvmem-cell-names = "part_number";
      +
      #cooling-cells = <2>;
     
       };
     
       };
       
    ==== STM32MP1 driver node append ====
    +
    With these nvmem-cells / nvmem-cell-names properties, the CPU0 device can easily find the OTP number, in order to access part number information.<br/>
    Driver can directly consume NVMEM data cells, as described in [[NVMEM_overview#Device_tree_configuration|NVMEM overview]].<br/>
    +
     
    The ADC_TEMP device is a good example, with a dedicated OTP containing calibration information.<br/>
    +
    ==== STM32MP1 nvmem_layout node (bootloader specific) ====
    The device node is located in ''stm32mp157c.dtsi''<ref>{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp157c.dtsi}}</ref> file.
    +
    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 the nvmem-cell-names property.
       
       adc_temp: temp {
    +
       nvmem_layout: nvmem_layout@0 {
       compatible = "st,stm32mp1-adc-temp";
    +
       compatible = "st,stm32mp1-nvmem-layout";
       io-channels = <&adc2 12>;
    +
       nvmem-cells = <&cfg0_otp>,
      nvmem-cells = <&ts_cal1>, <&ts_cal2>;
    +
            <&part_number_otp>,
       nvmem-cell-names = "ts_cal1", "ts_cal2";
    +
            <&monotonic_otp>,
      #io-channel-cells = <0>;
    +
            <&nand_otp>,
      #thermal-sensor-cells = <0>;
    +
            <&uid_otp>,
      status = "disabled";
    +
            <&package_otp>,
      +
            <&hw2_otp>;
      +
     
      +
       nvmem-cell-names = "cfg0_otp",
      +
        "part_number_otp",
      +
        "monotonic_otp",
      +
        "uid_otp",
      +
        "nand_otp",
      +
        "package_otp",
      +
        "hw2_otp";
     
       };
     
       };
       
    With these nvmem-cells / nvmem-cell-names properties, the ADC_TEMP device can easily find the OTP number, in order to access calibration information.<br/>
    +
    With this new node, the platform can easily find the OTP numbers, in order to access all the necessary information.
       
     
    ==How to configure the DT using STM32CubeMX==
     
    ==How to configure the DT using STM32CubeMX==
     
    The [[STM32CubeMX]] tool can be used to configure the STM32MPU device and get the corresponding [[Device_tree#STM32|platform configuration device tree]] files.<br />
     
    The [[STM32CubeMX]] tool can be used to configure the STM32MPU device and get the corresponding [[Device_tree#STM32|platform configuration device tree]] files.<br />
    The STM32CubeMX may not support all the properties described in the above [[#DT bindings documentation|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.
    +
    STM32CubeMX may not support all the properties described in the documents listed in [[#DT bindings documentation|DT bindings documentation]] above. If so, the tool inserts '''user sections''' in the generated device tree. These sections can then be edited to add some properties that are preserved from one generation to another. Refer to the [[STM32CubeMX]] user manual for further information.
       
     
    ==References==
     
    ==References==
    Line 121: Line 163:
     
    <noinclude>
     
    <noinclude>
     
    [[Category:Device tree configuration]]
     
    [[Category:Device tree configuration]]
    [[Category:Trusted Firmware-A (TF-A)]]
    +
    [[Category:Platform security]]
    {{ArticleBasedOnModel | Contributors:Peripheral or framework device tree configuration model}}
    +
    {{ArticleBasedOnModel | Peripheral or framework device tree configuration model}}
    {{ArticleMainWriter | NicolasLB}}
    +
    {{PublicationRequestId | 15044 | 2020-02-21 | 13613 (PhilipS - 2019-10-09))}}
    {{PublicationRequestId | 13613 |2019-10-09 | }}
     
     
     
     
    </noinclude>
     
    </noinclude>