Difference between revisions of "FDCAN device tree configuration"

[quality revision] [quality revision]
m
m
 
Applicable for STM32MP13x lines, STM32MP15x lines

1 Article purpose[edit]

This article explains how to configure the FDCAN when it is assigned to the Linux® OS. In that case, it is controlled by the CAN framework for Bosch M_CAN controller.

The configuration is performed using the device tree mechanism that provides a hardware description of the FDCAN peripheral, used by the M_CAN Linux driver and by the NET/CAN framework.

If the peripheral is assigned to another execution context, refer to How to assign an internal peripheral to a runtime context article for guidelines on peripheral assignment and configuration.

2 DT bindings documentation[edit]

M_CAN device tree bindings[1] describe all the required and optional properties.

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]

All M_CAN nodes are described in stm32mp153described :

  • for STM32MP13x lines Warning.png in stm32mp133.dtsi [2] file,
  • for STM32MP15x lines More info.png in stm32mp153.dtsi [3] file,

with disabled status and required properties such as:

  • Physical base address and size of the device register map
  • Message RAM address and size (CAN SRAM)
  • Host clock and CAN clock
  • Message RAM configuration

This For example this is a set of properties that may not vary for a given STM32 device. for STM32MP13x lines Warning.png

 m_can1: can@4400e000 {
 	compatible = "bosch,m_can";                       
 	reg = <0x4400e000 0x400>, <0x44011000 0x1400>;    /* FDCAN1 uses only the first half of the dedicated CAN_SRAM */
 	reg-names = "m_can", "message_ram";
 	interrupts = <GIC_SPI 1920 IRQ_TYPE_LEVEL_HIGH>,
 		     <GIC_SPI 2122 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "int0", "int1";
 	clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 	clock-names = "hclk", "cclk";
 	bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
 	status = "disabled";
 };
 
 m_can2: can@4400f000 {
 	compatible = "bosch,m_can";
 	reg = <0x4400f000 0x400>, <0x44011000 0x2800>;    /* The 10 Kbytes of the CAN_SRAM are mapped */
 	reg-names = "m_can", "message_ram";
 	interrupts = <GIC_SPI 2021 IRQ_TYPE_LEVEL_HIGH>,
 		     <GIC_SPI 2223 IRQ_TYPE_LEVEL_HIGH>;
 	interrupt-names = "int0", "int1";
 	clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 	clock-names = "hclk", "cclk";
 	bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;         /* Set mram-cfg offset to write FDCAN2 data on the second half of the dedicated CAN_SRAM */
 	status = "disabled";
 };

The required and optional properties are fully described in the bindings files.

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]

Part of the device tree is used to describe the FDCAN hardware used on a given board. The DT node ("m_can") must be filled in:

  • Enable the CAN block by setting status = "okay".
  • Configure the pins in use via pinctrl, through pinctrl-0 (default pins), pinctrl-1 (sleep pins) and pinctrl-names.

3.3 DT configuration examples[edit]

The example below shows how to configure and enable FDCAN1 instance at board level:

 &m_can1 {
 	pinctrl-names = "default", "sleep";         /* configure pinctrl modes for m_can1 */
 	pinctrl-0 = <&m_can1_pins_a>;               /* configure m_can1_pins_a as default pinctrl configuration for m_can1 */
 	pinctrl-1 = <&m_can1_sleep_pins_a>;         /* configure m_can1_sleep_pins_a as sleep pinctrl configuration for m_can1 */
 	status = "okay";                            /* enable m_can1 */ 
 };

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

  1. Documentation/devicetree/bindings/net/can/m_can.txt M_CAN device tree bindings
  2. arch/arm/boot/dts/
  3. stm32mp133.dtsi
  4. stm32mp153.dtsi
  5. , STM32MP153 device tree file


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

== Article purpose ==
This article explains how to configure the [[FDCAN internal peripheral|FDCAN]] when it is assigned to the Linux<sup>&reg;</sup> OS. In that case, it is controlled by the [[CAN overview|CAN framework]] for Bosch M_CAN controller.

The configuration is performed using the [[Device tree|device tree]] mechanism that provides a hardware description of the FDCAN peripheral, used by the M_CAN Linux driver and by the NET/CAN framework.

If the peripheral is assigned to another execution context, refer to [[How to assign an internal peripheral to a runtime context]] article for guidelines on peripheral assignment and configuration.

== DT bindings documentation ==
M_CAN device tree bindings<ref>{{CodeSource | Linux kernel | Documentation/devicetree/bindings/net/can/m_can.txt | Documentation/devicetree/bindings/net/can/m_can.txt}} M_CAN device tree bindings</ref> describe all the required and optional properties.

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

All M_CAN nodes are described in stm32mp153:
* for {{MicroprocessorDevice | device=13}}  in  stm32mp133.dtsi <ref name="stm32mp133.dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp153.dtsi | stm32mp133.dtsi | stm32mp133.dtsi}}</ref> file,
* for {{MicroprocessorDevice | device=15}}  in stm32mp153.dtsi <ref name="stm32mp153.dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp153.dtsi}}, STM32MP153 device tree file</ref> file  | stm32mp153.dtsi}}</ref> file,
with disabled status and required properties such as:
* Physical base address and size of the device register map
* Message RAM address and size (CAN SRAM)
* Host clock and CAN clock
* Message RAM configuration
This For example this is a set of properties that may not vary for a given STM32 device.for  {{MicroprocessorDevice | device=13}}

  m_can1: can@4400e000 {
  	compatible = "bosch,m_can";                       
  	reg = <0x4400e000 0x400>, <0x44011000 0x1400>;    {{highlight|/* FDCAN1 uses only the first half of the dedicated CAN_SRAM */}}
  	reg-names = "m_can", "message_ram";
  	interrupts = <GIC_SPI 1920 IRQ_TYPE_LEVEL_HIGH>,<GIC_SPI 2122 IRQ_TYPE_LEVEL_HIGH>;
  	interrupt-names = "int0", "int1";
  	clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
  	clock-names = "hclk", "cclk";
  	bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
  	status = "disabled";
  };

  m_can2: can@4400f000 {
  	compatible = "bosch,m_can";
  	reg = <0x4400f000 0x400>, <0x44011000 0x2800>;    {{highlight|/* The 10 Kbytes of the CAN_SRAM are mapped */}}
  	reg-names = "m_can", "message_ram";
  	interrupts = <GIC_SPI 2021 IRQ_TYPE_LEVEL_HIGH>,<GIC_SPI 2223 IRQ_TYPE_LEVEL_HIGH>;
  	interrupt-names = "int0", "int1";
  	clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
  	clock-names = "hclk", "cclk";
  	bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;         {{highlight|/* Set mram-cfg offset to write FDCAN2 data on the second half of the dedicated CAN_SRAM */}}
  	status = "disabled";
  };
The required and optional properties are fully described in the [[FDCAN_device_tree_configuration#DT_bindings_documentation|bindings files]].

{{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) ===
Part of the [[Device tree|device tree]] is used to describe the FDCAN hardware used on a given board. The DT node ('''"m_can"''') must be filled in:
* Enable the CAN block by setting '''status = "okay".'''
* Configure the pins in use via [[Pinctrl overview|pinctrl]], through '''pinctrl-0''' (default pins), '''pinctrl-1''' (sleep pins) and '''pinctrl-names'''.

=== DT configuration examples ===
The example below shows how to configure and enable FDCAN1 instance at board level:

  &m_can1 {
  	pinctrl-names = "default", "sleep";         {{highlight|/* configure pinctrl modes for m_can1 */}}
  	pinctrl-0 = <&m_can1_pins_a>;               {{highlight|/* configure m_can1_pins_a as default pinctrl configuration for m_can1 */}}
  	pinctrl-1 = <&m_can1_sleep_pins_a>;         {{highlight|/* configure m_can1_sleep_pins_a as sleep pinctrl configuration for m_can1 */}}
  	status = "okay";                            {{highlight|/* enable m_can1 */}} 
  };

==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 [[#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:CAN|2]]
{{ArticleBasedOnModel | Peripheral or framework device tree configuration model}}
{{PublicationRequestId | 9832 | 2018-12-07 | AlainF}}</noinclude>
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  +
<noinclude>{{ApplicableFor
  +
|MPUs list=STM32MP13x, STM32MP15x
  +
|MPUs checklist=STM32MP13x, STM32MP15x
  +
}}</noinclude>
 
== Article purpose ==
 
== Article purpose ==
 
This article explains how to configure the [[FDCAN internal peripheral|FDCAN]] when it is assigned to the Linux<sup>&reg;</sup> OS. In that case, it is controlled by the [[CAN overview|CAN framework]] for Bosch M_CAN controller.
 
This article explains how to configure the [[FDCAN internal peripheral|FDCAN]] when it is assigned to the Linux<sup>&reg;</sup> OS. In that case, it is controlled by the [[CAN overview|CAN framework]] for Bosch M_CAN controller.
Line 16: Line 20:
 
===DT configuration (STM32 level) ===
 
===DT configuration (STM32 level) ===
   
All M_CAN nodes are described in stm32mp153.dtsi <ref>{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp153.dtsi | arch/arm/boot/dts/stm32mp153.dtsi}}, STM32MP153 device tree file</ref> file with disabled status and required properties such as:
+
All M_CAN nodes are described :
  +
* for {{MicroprocessorDevice | device=13}}  in stm32mp133.dtsi <ref name="stm32mp133.dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp133.dtsi | stm32mp133.dtsi}}</ref> file,
  +
* for {{MicroprocessorDevice | device=15}}  in stm32mp153.dtsi <ref name="stm32mp153.dtsi">{{CodeSource | Linux kernel | arch/arm/boot/dts/stm32mp153.dtsi | stm32mp153.dtsi}}</ref> file,
  +
 
  +
with disabled status and required properties such as:
 
* Physical base address and size of the device register map
 
* Physical base address and size of the device register map
 
* Message RAM address and size (CAN SRAM)
 
* Message RAM address and size (CAN SRAM)
Line 22: Line 30:
 
* Message RAM configuration
 
* Message RAM configuration
   
This is a set of properties that may not vary for a given STM32 device.
+
For example this is a set of properties for {{MicroprocessorDevice | device=13}}
 
   m_can1: can@4400e000 {
 
   m_can1: can@4400e000 {
 
   compatible = "bosch,m_can";                       
 
   compatible = "bosch,m_can";                       
 
   reg = <0x4400e000 0x400>, <0x44011000 0x1400>;    {{highlight|/* FDCAN1 uses only the first half of the dedicated CAN_SRAM */}}
 
   reg = <0x4400e000 0x400>, <0x44011000 0x1400>;    {{highlight|/* FDCAN1 uses only the first half of the dedicated CAN_SRAM */}}
 
   reg-names = "m_can", "message_ram";
 
   reg-names = "m_can", "message_ram";
   interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+
   interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
       <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+
       <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 
   interrupt-names = "int0", "int1";
 
   interrupt-names = "int0", "int1";
 
   clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 
   clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
Line 40: Line 48:
 
   reg = <0x4400f000 0x400>, <0x44011000 0x2800>;    {{highlight|/* The 10 Kbytes of the CAN_SRAM are mapped */}}
 
   reg = <0x4400f000 0x400>, <0x44011000 0x2800>;    {{highlight|/* The 10 Kbytes of the CAN_SRAM are mapped */}}
 
   reg-names = "m_can", "message_ram";
 
   reg-names = "m_can", "message_ram";
   interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+
   interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
       <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+
       <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 
   interrupt-names = "int0", "int1";
 
   interrupt-names = "int0", "int1";
 
   clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
 
   clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;