Difference between revisions of "Device tree from scratch"

Latest revision as of 17:34, 18 August 2022

2022-08-15 Monday

How to Create Device Tree Files for New MCUs

Keywords: device tree Zephyr RTOS versus Linux use

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

dts excerpt

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

• https://android.googlesource.com/kernel/msm/+/android-wear-5.0.2_r0.1/Documentation/devicetree/bindings/dma/dma.txt

^ Reference

1. https://infocenter.nordicsemi.com/topic/ps_nrf9160/memory.html
2. https://infocenter.nordicsemi.com/topic/ps_nrf9160/dppi.html Nordic Semi documentation on Distributed Programmable Peripheral Interconnect
3. https://github.com/zephyrproject-rtos/hal_nordic/blob/master/nrfx/hal/nrf_dppi.h link to hal_nordic code repository
4. 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.
5. ./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.