Difference between revisions of "Device tree from scratch"
m (Add section "References" and link to Nordic Semi documentation on Distributed Programmable Peripheral Interconnect.) |
m (Adding key phrase "device tree Zephyr RTOS versus Linux use".) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | <center> | ||
| + | [[Device_tree_from_scratch]] :: [[Spi_device_tree_source_code]] :: [[Pico-sdk_studies]] | ||
| + | </center> | ||
| + | |||
| + | |||
| + | |||
2022-08-15 Monday | 2022-08-15 Monday | ||
How to Create Device Tree Files for New MCUs | How to Create Device Tree Files for New MCUs | ||
| + | |||
| + | Keywords: [[#device_tree_and_zephyr_versus_linux_use_of|device tree Zephyr RTOS versus Linux use]] | ||
| + | |||
== [[#top|^]] Overview == | == [[#top|^]] Overview == | ||
| − | Starting local article on how to craft a correct and complete device tree file set for an MCU not yet supported by Zephyr RTOS. First notes here will reference examples of device tree source files various supported MCUs, plus corresponding datasheet sections pertaining to given MCUs. | + | Starting local article on how to craft a correct and complete device tree file set for an MCU not yet supported by Zephyr RTOS. First notes here will reference examples of device tree source files various supported MCUs, plus corresponding datasheet sections pertaining to given MCUs. <span id="device_tree_and_zephyr_versus_linux_use_of"></span>A couple of points worth noting on device tree with Zephyr RTOS - (1) Zephyr does not use nor load device tree blobs at run time, rather device tree source and device tree compile tools aid in assuring and helping developer correct device coding errors at compile time. (2) To point one the act of calling out a particular device tree "compatible" value will cause the device tree compiler to look for a device bindings file specific to that "compatible" string. The bindings file in turn calls out, e.g. instructs us as to which device tree attributes are required, and often also which data types and bounds on data ranges are required to be assigned to both required and optional device attributes. Helpful! |
== [[#top|^]] Nordic Semi nRF9160 == | == [[#top|^]] Nordic Semi nRF9160 == | ||
| Line 12: | Line 21: | ||
Not sure for what DPPI stands, but this device in nRF9160 SoC device tree file `` has a simple node entry. Code excerpt from https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/nordic/nrf9160_common.dtsi#L31: | Not sure for what DPPI stands, but this device in nRF9160 SoC device tree file `` has a simple node entry. Code excerpt from https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/nordic/nrf9160_common.dtsi#L31: | ||
| + | [https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/nordic/nrf9160_common.dtsi#L31 dts excerpt for nRF9160 dppi device] | ||
<pre> | <pre> | ||
dppic: dppic@17000 { | dppic: dppic@17000 { | ||
| Line 23: | Line 33: | ||
| + | Device tree source excerpt for nRF9160 SPI peripheral. Looking over this much of the detail like all the specific configuration registers is left out of device tree. These hardware features need to be implemented in the given device' driver code: | ||
| + | <i> [https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/nordic/nrf9160_common.dtsi#L209 dts excerpt] </i> | ||
| + | <pre> | ||
| + | spi0: spi@8000 { | ||
| + | /* | ||
| + | * This spi node can be either SPIM or SPIS, for the user to pick: | ||
| + | * compatible = "nordic,nrf-spim" or | ||
| + | * "nordic,nrf-spis". | ||
| + | */ | ||
| + | compatible = "nordic,nrf-spim"; | ||
| + | #address-cells = <1>; | ||
| + | #size-cells = <0>; | ||
| + | reg = <0x8000 0x1000>; | ||
| + | interrupts = <8 NRF_DEFAULT_IRQ_PRIORITY>; | ||
| + | max-frequency = <DT_FREQ_M(8)>; | ||
| + | status = "disabled"; | ||
| + | }; | ||
| + | </pre> | ||
| + | <!-- comentario --> | ||
| + | == [[#top|^]] STMicro stm32f091 device tree source == | ||
| + | |||
| + | <pre> | ||
| + | spi2: spi@40003800 { | ||
| + | compatible = "st,stm32-spi-fifo", "st,stm32-spi"; | ||
| + | #address-cells = <1>; | ||
| + | #size-cells = <0>; | ||
| + | reg = <0x40003800 0x400>; | ||
| + | clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00004000>; | ||
| + | interrupts = <26 3>; | ||
| + | status = "disabled"; | ||
| + | }; | ||
| + | </pre> | ||
<!-- comentario --> | <!-- comentario --> | ||
| − | == Reference == | + | |
| + | == [[#top|^]] Synopsys SPI bindings required property == | ||
| + | |||
| + | The Synopsys SPI dts bindings file appears to make the rule that interrupt-parent property must be set. Appears this way in rpi_pico based Zephyr app's combined device tree source file: | ||
| + | |||
| + | interrupt-parent = < &nvic >; | ||
| + | |||
| + | Ah turns out RP2040 dts node '&nvic' appears in file [workspace]/zephyr/dts/arm/armv6-m.dtsi. | ||
| + | |||
| + | <!-- comentario --> | ||
| + | |||
| + | == [[#top|^]] DMA device tree node properties == | ||
| + | |||
| + | * https://android.googlesource.com/kernel/msm/+/android-wear-5.0.2_r0.1/Documentation/devicetree/bindings/dma/dma.txt | ||
| + | |||
| + | <!-- comentario --> | ||
| + | |||
| + | == [[#top|^]] Reference == | ||
<ol> | <ol> | ||
| − | <li> https://infocenter.nordicsemi.com/topic/ps_nrf9160/dppi.html Nordic Semi documentation on Distributed Programmable Peripheral Interconnect | + | |
| + | <li> https://infocenter.nordicsemi.com/topic/ps_nrf9160/memory.html | ||
| + | |||
| + | <li> https://infocenter.nordicsemi.com/topic/ps_nrf9160/dppi.html Nordic Semi documentation on Distributed Programmable Peripheral Interconnect | ||
| + | |||
| + | <li> https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/hal/nrf_dppi.h link to hal_nordic code repository | ||
| + | |||
| + | <li> https://github.com/nrfconnect/sdk-nrf/blob/v1.6.1/subsys/esb/esb.c#L563 . . . A reference to DPPI driver code in an nrf-sdk module. | ||
| + | |||
| + | <li> ./dts/bindings/dma/snps,designware-dma.yaml:6:compatible: "snps,designware-dma" . . . RP2040 dtsi file authored by Yonatan Shachter calls out "snps,designware-i2c" for I2C device compatibility. | ||
| + | |||
</ol> | </ol> | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | <!-- EOF --> | ||
Latest revision as of 17:34, 18 August 2022
Device_tree_from_scratch :: Spi_device_tree_source_code :: Pico-sdk_studies
2022-08-15 Monday
How to Create Device Tree Files for New MCUs
Keywords: device tree Zephyr RTOS versus Linux use
Contents
^ Overview
Starting local article on how to craft a correct and complete device tree file set for an MCU not yet supported by Zephyr RTOS. First notes here will reference examples of device tree source files various supported MCUs, plus corresponding datasheet sections pertaining to given MCUs. A couple of points worth noting on device tree with Zephyr RTOS - (1) Zephyr does not use nor load device tree blobs at run time, rather device tree source and device tree compile tools aid in assuring and helping developer correct device coding errors at compile time. (2) To point one the act of calling out a particular device tree "compatible" value will cause the device tree compiler to look for a device bindings file specific to that "compatible" string. The bindings file in turn calls out, e.g. instructs us as to which device tree attributes are required, and often also which data types and bounds on data ranges are required to be assigned to both required and optional device attributes. Helpful!
^ Nordic Semi nRF9160
Not sure for what DPPI stands, but this device in nRF9160 SoC device tree file `` has a simple node entry. Code excerpt from https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/arm/nordic/nrf9160_common.dtsi#L31:
dts excerpt for nRF9160 dppi device
dppic: dppic@17000 {
compatible = "nordic,nrf-dppic";
reg = <0x17000 0x1000>;
status = "okay";
};
Looking at the `reg` property we find 0x17000 value called out. From personal memory we know this is the memory mapped address or offset from some base address. We'll look for this offset in Nordic's datasheet on the nRF9160 application core . . .
Device tree source excerpt for nRF9160 SPI peripheral. Looking over this much of the detail like all the specific configuration registers is left out of device tree. These hardware features need to be implemented in the given device' driver code:
spi0: spi@8000 {
/*
* This spi node can be either SPIM or SPIS, for the user to pick:
* compatible = "nordic,nrf-spim" or
* "nordic,nrf-spis".
*/
compatible = "nordic,nrf-spim";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x8000 0x1000>;
interrupts = <8 NRF_DEFAULT_IRQ_PRIORITY>;
max-frequency = <DT_FREQ_M(8)>;
status = "disabled";
};
^ STMicro stm32f091 device tree source
spi2: spi@40003800 {
compatible = "st,stm32-spi-fifo", "st,stm32-spi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x40003800 0x400>;
clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00004000>;
interrupts = <26 3>;
status = "disabled";
};
^ Synopsys SPI bindings required property
The Synopsys SPI dts bindings file appears to make the rule that interrupt-parent property must be set. Appears this way in rpi_pico based Zephyr app's combined device tree source file:
interrupt-parent = < &nvic >;
Ah turns out RP2040 dts node '&nvic' appears in file [workspace]/zephyr/dts/arm/armv6-m.dtsi.
^ DMA device tree node properties
^ Reference
- https://infocenter.nordicsemi.com/topic/ps_nrf9160/memory.html
- https://infocenter.nordicsemi.com/topic/ps_nrf9160/dppi.html Nordic Semi documentation on Distributed Programmable Peripheral Interconnect
- https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/hal/nrf_dppi.h link to hal_nordic code repository
- https://github.com/nrfconnect/sdk-nrf/blob/v1.6.1/subsys/esb/esb.c#L563 . . . A reference to DPPI driver code in an nrf-sdk module.
- ./dts/bindings/dma/snps,designware-dma.yaml:6:compatible: "snps,designware-dma" . . . RP2040 dtsi file authored by Yonatan Shachter calls out "snps,designware-i2c" for I2C device compatibility.
