Difference between revisions of "BSEC device tree configuration"

[quality revision] [quality revision]
m (BSEC node append)
 
Applicable for STM32MP13x lines, STM32MP15x lines

1 Article purpose[edit]

Warning white.png 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, which is performed using the device tree mechanism that 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[edit]

Generic information about NVMEM is available in the NVMEM overview.

This binding document explains how to write The device tree files binding documents for BSEC are stored either in the given applicable components listed below, or in the Linux kernel repository:

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 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)[edit]

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

Please refer to 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 white.png 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)[edit]

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

for example to add a NVMEM data cell:

 &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 secure world software (OP-TEE or SP-MIN) 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 white.png Information
When status property is not filled, this is implicitly set as an "okay" status by default.
Info white.png 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 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.

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

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>;
 	};
 	/* 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[edit]

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.

the st,non-secure-otp property used in secure world device tree, with a 32-bit length granularity (that is, 4 bytes).

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 DT binding files listed 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]

Please refer to the following links for additional information:

Template:ArticleMainWriter



== Article purpose ==
{{Warning|This article explains how to configure [[BSEC_internal_peripheral|BSEC]] at boot time.}}

This article describes <noinclude>{{ApplicableFor
|MPUs list=STM32MP13x, STM32MP15x
|MPUs checklist=STM32MP13x,STM32MP15x
}}</noinclude>

== Article purpose ==
The purpose of this article is to explain how to configure 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, relying on the bindings documentation, that is the description of the required and optional device-tree properties.

== DT bindings documentation ==

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:
* [[TF-A overview|TF-A]]: ''tf-a/The device tree binding documents for [[BSEC internal peripheral|BSEC]] are stored either in the given applicable components listed below, or in the Linux kernel repository:
* TF-A BL2: 
**for example: {{CodeSource | 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>

* }}
* OP-TEE:
** for example: STM32 BSEC device tree bindings: {{CodeSource | OP-TEE_OS | documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml}}
* U-Boot, Linux<sup>&reg;</sup> BSEC devicetree bindings: Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt<ref name="Linux,st,stm32-romem">OS:
** for example: STM32 BSEC device tree bindings: {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt}}</ref>

* Linux<sup>&reg;</sup> yaml}}
** for example: generic NVMEM devicetree bindings: {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/nvmem.txt<ref name="nvmem.txt">yaml}}, {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/nvmem.txt}}</ref>-consumer.yaml}}


== 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|How to configure the DT using STM32CubeMX]] for more details.

=== DT configuration (STM32/SoC 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).

  / {
  ...
  	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 [[NVMEM_overview#Device_tree_configuration|NVMEM overview]] for the bindings common with Linux<sup>&reg;</sup> kernel.

=== DT configuration (board level) ===
==== STM32MP1 BSEC node append ====<div class="mw-collapsible-content">

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

'''For {{EcosystemRelease | revision=1.1.0 | range=and after}}'''and [[NVMEM_overview#Device_tree_configuration|NVMEM]] node are located in the [[STM32 MPU device_tree#Device tree structure|device tree file]] for the software components, supporting the peripheral and listed in the above [[#DT bindings documentation|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.}}

=== DT configuration (board level) ===

The objective of this chapter is to explain how to enable and configure the  [[BSEC_internal_peripheral|BSEC]]  DT nodes for a board.

Peripheral configuration should be done in specific board device tree files (board dts file).

==== BSEC node append ====
The board definition in the device tree may include some additional board-specific OTP declarations, for example to add a NVMEM data cell:
&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 {{highlightParam|st,non-secure-otp}};
  	};
  };

With only 32 lower NVMEM 32-bit data words, software may need more, so it is possiblethe secure world software (OP-TEE or SP-MIN) 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>;
  	};
  };

==== STM32MP1 driver node append ====
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/>

The device node is located in ''stm32mp157c.dtsi''<ref>{{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";
  };

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


==the {{highlightParam|st,non-secure-otp}} property used in secure world device tree, with a 32-bit length granularity (that is, 4 bytes).<br/>


==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 DT binding files listed 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.

==References==
Please refer to the following links for additional information:
<references />
<noinclude>

[[Category:Device tree configuration]]
[[Category:Trusted Firmware-A (TF-A)]]
{{ArticleBasedOnModel | Contributors:OP-TEE Persistent storage]] 
{{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>
(71 intermediate revisions by 9 users not shown)
Line 1: Line 1:
  +
<noinclude>{{ApplicableFor
  +
|MPUs list=STM32MP13x, STM32MP15x
  +
|MPUs checklist=STM32MP13x,STM32MP15x
  +
}}</noinclude>
 
== Article purpose ==
 
== Article purpose ==
{{Warning|This article explains how to configure [[BSEC_internal_peripheral|BSEC]] at boot time.}}
+
The purpose of this article is to explain how to configure the [[BSEC internal peripheral|BSEC]] using the [[Device tree|device tree]] mechanism, relying on the bindings documentation, that is the description of the required and optional device-tree properties.
 
 
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.
 
   
 
== 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 device tree binding documents for [[BSEC internal peripheral|BSEC]] are stored either in the given applicable components listed below, or in the Linux kernel repository:
* [[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 BL2:
* 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>
+
**for example: {{CodeSource | TF-A | docs/devicetree/bindings/soc/st,stm32-romem.txt}}
* 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>
+
* OP-TEE:
  +
** for example: STM32 BSEC device tree bindings: {{CodeSource | OP-TEE_OS | documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml}}
  +
* U-Boot, Linux<sup>&reg;</sup> OS:
  +
** for example: STM32 BSEC device tree bindings: {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml}}
  +
** for example: generic NVMEM devicetree bindings: {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/nvmem.yaml}}, {{CodeSource | Linux kernel | Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml}}
   
 
== 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 organization.
   
 
'''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/SoC 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 [[BSEC_internal_peripheral|BSEC]] node and [[NVMEM_overview#Device_tree_configuration|NVMEM]] node are located in the [[STM32 MPU device_tree#Device tree structure|device tree file]] for the software components, supporting the peripheral and listed in the above [[#DT bindings documentation|DT bindings documentation]] paragraph.
 
 
  / {
 
  ...
 
  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 [[NVMEM_overview#Device_tree_configuration|NVMEM overview]] for the bindings common with Linux<sup>&reg;</sup> kernel.
+
{{Warning|This device tree part is related to STM32 microprocessors. It must be kept as is, without being modified by the end-user.}}
   
 
=== DT configuration (board level) ===
 
=== DT configuration (board level) ===
==== STM32MP1 BSEC node append ====
 
<div class="mw-collapsible-content">
 
Board definition in Device tree may add some OTP declarations, specific to the board:
 
   
'''For {{EcosystemRelease | revision=1.1.0 | range=and after}}'''
+
The objective of this chapter is to explain how to enable and configure the  [[BSEC_internal_peripheral|BSEC]]  DT nodes for a board.
  &bsec {
+
 
  board_id: board_id@ec {
+
Peripheral configuration should be done in specific board device tree files (board dts file).
  reg = <0xec 0x4>;
 
  status = "okay";
 
  };
 
  };
 
   
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/>
+
==== BSEC node append ====
User can add upper OTP declaration in device tree, using status property, to define accessibility conditions, as described in the following table:<br/>
+
The board definition in the device tree may include some additional board-specific OTP declarations, for example to add a NVMEM data cell:
{| 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 {
 
   &bsec {
 
   board_id: board_id@ec {
 
   board_id: board_id@ec {
 
   reg = <0xec 0x4>;
 
   reg = <0xec 0x4>;
  +
  {{highlightParam|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/>
+
With only 32 lower NVMEM 32-bit data words, the secure world software (OP-TEE or SP-MIN) 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 {{highlightParam|st,non-secure-otp}} property used in secure world device tree, 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 ''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>;
 
  };
 
  };
 
 
 
==== STM32MP1 driver node append ====
 
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/>
 
The device node is located in ''stm32mp157c.dtsi''<ref>{{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";
 
  };
 
 
 
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/>
 
   
 
==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 DT binding files listed 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.
   
 
==References==
 
==References==
Line 121: Line 57:
 
<noinclude>
 
<noinclude>
 
[[Category:Device tree configuration]]
 
[[Category:Device tree configuration]]
[[Category:Trusted Firmware-A (TF-A)]]
+
[[Category:OP-TEE Persistent storage]]  
{{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>