小白带你探索Linux设备树1_框架篇V1

小白带你探索Linux设备树1_框架篇V1

  • 0. 说在前面的话
  • 1. 什么是设备树
    • 1.1 设备树的定义
    • 1.2 设备树的使用
  • 2. ARM Linux设备树的起源
    • 2.1 忍无可忍
    • 2.2 事件背景
  • 3. DT的文件组织结构
    • 3.1 dts目录简介
    • 3.2 dts分析文件下载
    • 3.3 完整dts文件的组成
  • 4. DT的语法组织框架
    • 4.1 DT的基本语法
    • 4.2 DT的简化框架
    • 4.3 根节点的model与compatible
    • 4.4 节点名字
    • 4.5 reg属性
    • 4.6 interrupts属性
    • 4.7 其他属性
    • 4.8 特殊节点
  • 5. 总结
  • 参考文献

0. 说在前面的话

学习过程中的总结记录,感悟比较浅显,经不起推敲,欢迎批评指正!!!

文章主体是以imx8qm-mek评估板为实例进行介绍设备树。

1. 什么是设备树

1.1 设备树的定义

官方定义:

The primary purpose of Device Tree in Linux is to provide a way to
describe non-discoverable hardware. This information was previously
hard coded in source code.

ARM设备树出现之前的电路板硬件的细节被硬编码到内核中了,导致内核代码臃肿难以维护,因此将内核与那些臃肿的硬件代码解耦,方便维护。

1.2 设备树的使用

首先看下设备树如何被被加载到内核当中的过程
小白带你探索Linux设备树1_框架篇V1_第1张图片
首先将上图涉及到的dts、dtb、dtc简单说明下。

  • dts:device tree source 设备树源文件,也就是我们进行编辑的文件,用于增删相关的硬件细节,可以看做C之类的代码,并且支持部分C语法,后面会详谈;
  • dtb:device tree blob 可以视为二进制版本的dts,内核可以解析;
  • dtc:device tree compiler 设备树编译器,dtb文件就是通过dtc将dts文件编译而成的。个人感觉可以类比C语言的编译。

上图可以总结为:利用dtc将dts文件编译为可被内核解析的dtb文件,通过bootloader的引导,kernel会将dtb文件加载到内存,并进行解析。
在没引进设备树之前,当每次更改设备,都需要重新编译内核,而现在仅仅需要编译设备树即可,省时省力。

2. ARM Linux设备树的起源

2.1 忍无可忍

设备树出现的原因,还得从2011年3月17日Linus Torvalds的那封信说起,下面是信件的截图:
小白带你探索Linux设备树1_框架篇V1_第2张图片
因ARM带来大量的板级细节代码,导致内核中充斥着大量的垃圾代码,最后Linus忍无可忍了,于是乎这就成了ARM Linux设备树诞生的契机。

2.2 事件背景

每次正式的linux kernel release之后都会有两周的merge
window,在这个窗口期间,kernel各个部分的维护者都会提交各自的patch,将自己测试稳定的代码请求并入kernel main
line。每到这个时候,Linus就会比较繁忙,他需要从各个内核维护者的分支上取得最新代码并merge到自己的kernel source
tree中。Tony Lindgren,内核OMAP development
tree的维护者,发送了一个邮件给Linus,请求提交OMAP平台代码修改,并给出了一些细节描述:

  • 1、简单介绍本次改动
  • 2、关于如何解决merge conficts。有些git mergetool就可以处理,不能处理的,给出了详细介绍和解决方案

一切都很平常,也给出了足够的信息,然而,正是这个pull request引发了一场针对ARM
linux的内核代码的争论。我相信Linus一定是对ARM相关的代码早就不爽了,ARM的merge工作量较大倒在其次,主要是他认为ARM很多的代码都是垃圾,代码里面有若干愚蠢的table,而多个人在维护这个table,从而导致了冲突。因此,在处理完OMAP的pull
request之后(Linus并非针对OMAP平台,只是Tony Lindgren撞在枪口上了),他发出了怒吼:

对事件背景感兴趣的详见wowo写的Device Tree(一):背景介绍,我就不在这里班门弄斧了。

3. DT的文件组织结构

3.1 dts目录简介

dts文件一般位于./arch/xxx/boot/dts目录中,首先映入眼帘的是各大SOC厂商的目录
在这里插入图片描述
我们这里选择freescale也就是现在的NXP作为分析对象

3.2 dts分析文件下载

如果大家没有内核源代码的话,可以使用如下命令将我们的作案工具单独下载下来,不用clone整个内核源代码,耗时又费力!!!

git clone https://github.com/sazczmh/imx8qm_linux_dts.git

如果clone不了的话,也可以从我的百度云盘下载
链接: https://pan.baidu.com/s/15lg0u54RMNjaMkge5e3E4g 密码: nsnv

clone后的代码如下
小白带你探索Linux设备树1_框架篇V1_第3张图片

3.3 完整dts文件的组成

从上图可以看到给大家的仓库中,不仅有.dts后缀的文件还有.dtsi后缀的文件,还记得我们之前提到过的dts支持部分C语法吗?这里的.dtsi类似C语言的头文件。

为了模块化dts文件,驱动工程师将电路板公用的部分提炼为各个.dtsi文件,减少代码的重复,并且易于移植。下图就是头文件包含示例:
小白带你探索Linux设备树1_框架篇V1_第4张图片
从图中也可以明显的注意到,该文件还包含了.h文件,是不是有点C的赶脚。

下面我们简单分析下仓库里那么多dts、dtsi的组织,在分析之前需要明白以下几个点:

  1. 仓库里设备树文件不是一块评估板的设备树,是同一芯片imx8qm的多个评估板的设备树;
  2. 同一块评估板因为用途不同,有多种设备树进行个性化配置;
  3. dtsi文件是提炼出来的公用的模块文件,为的是减少代码重复,易于移植。

明白了以上几个点之后,让我们着手分析吧

首先抛弃dtsi文件仅仅分析dts文件
小白带你探索Linux设备树1_框架篇V1_第5张图片
从图中可以明显的看到imx8qm的评估板种类有三种(我猜的…,大概是的),咱们的重点放在mek-Multisensory Enablement Kit系列,关于这几个文件的解释可以查看官网的release note,相关截图如下。
小白带你探索Linux设备树1_框架篇V1_第6张图片
从上图可以明显的看出来,mek那么多设备树分别有不同的特性。下面我们就仅用fsl-imx8qm-mek.dts来进行示例分析。

如下是fsl-imx8qm-mek.dts的层次结构
小白带你探索Linux设备树1_框架篇V1_第7张图片
从上图也可以看出一个完整的设备树文件是由1个dts文件+n个dtsi文件组成的。

4. DT的语法组织框架

4.1 DT的基本语法

/dts-v1/;

/ {
    node1 {
        a-string-property = "A string";
        a-string-list-property = "first string", "second string";
        // hex is implied in byte arrays. no '0x' prefix is required
        a-byte-data-property = [01 23 34 56];
        child-node1 {
            first-child-property;
            second-child-property = <1>;
            a-string-property = "Hello, world";
        };
        child-node2 {
        };
    };
    node2 {
        an-empty-property;
        a-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
        child-node1 {
        };
    };
};

小白带你探索Linux设备树1_框架篇V1_第8张图片

该抽象框架引自https://elinux.org/Device_Tree_Usage

说实话,小白我第一次遇到这个语法图的时候,真的是一脸懵逼,这个语法图太抽象了,和真实的设备树文件匹配不上,真实的设备树文件如下:

如果这时候大家还没有厌烦我的唠叨的话,就且听我慢慢道来dts语法组织框架吧。

  • 唯一的根节点: “/” ,多个根节点会合并;
  • 根节点会包含一系列子节点,抽象框架里面有两个子节点,它们分别是"node1" 和 “node2”;
  • 子节点"node1“又包含一系列子节点,这个抽象框架里有两个子节点,它们分别是: “child-node1” and “child-node2”;
  • 各个节点又包含一系列属性。

属性是简单的关键词和其对应的值所组成,与关键词所对应的值可以为空或者任意的数据属性,下面简单说说设备树源文件几个常见的属性例子:

  • 文本字符串数据属性以双引号的形式展示出来:
    • a-string-property = "A string";
  • ‘Cells’ 属性是32 bit 无符号整数,并且由尖括号来定位:
    • cell-property = <0xbeef 123 0xabcd1234>;
  • 二进制数据属性由方括号来定位:
    • binary-property = [0x01 0x23 0x45 0x67];
  • 可以使用逗号将不同表示形式的数据连接在一起:
    • mixed-property = "a string", [0x01 0x23 0x45 0x67], <0x12345678>;
  • 逗号还可用于创建字符串列表:
    • string-list = "red fish", "blue fish";

说过基本的语法,接下来让我们开始实战。

4.2 DT的简化框架

当了解基本的DT语法之后,首先展示一副简化的DT框架,让大家对DT有个简单的认识
小白带你探索Linux设备树1_框架篇V1_第9张图片

https://www.nxp.com/docs/en/application-note/AN5125.pdf

4.3 根节点的model与compatible

小白带你探索Linux设备树1_框架篇V1_第10张图片

  • model属性指明了该评估板的设备生产商(感觉主要指的芯片生产商)、该评估板(也可指芯片系列)的名字,一般而言,该属性的数值为“manufacturer,model”,本示例当中

    model = "Freescale i.MX8QM MEK";
    指明了该评估板的生产商为Freescale,评估板的名字为i.MX8QM MEK。

  • compatible属性是上文所提到的字符串列表属性,这些属性用于匹配machine type的,可以据此判断启动的设备。
    string-list = "red fish", "blue fish";
    根节点的compatible属性一般包括两个以上的兼容性字符串,本例中为
    compatible = "fsl,imx8qm-mek", "fsl,imx8qm";

    • fsl,imx8qm-mek为板子级别的名字,代表imx8qm的MEK评估板;
    • fsl,imx8qm为芯片级别的名字,代表imx8qm这款SOC。

这里面要提一点根节点仅有一个,但是观察dtsi文件发现,存在多个根节点,dtc会将多个根节点进行合并,类似下图。
小白带你探索Linux设备树1_框架篇V1_第11张图片

https://bootlin.com/pub/conferences/2014/elc/petazzoni-device-tree-dummies/

4.4 节点名字

下面集中列举几个节点名字,先有个感性的认识。

  • sata: sata@5f020000
  • memory@80000000
  • reserved-memory

节点名字具有如下格式

[label: ]<name>[@<unit-address>]
  • name是由简单的ascii字符串,最长31字符。通常情况下name的命名是说明这个设备节点的种类,例如sata、memory。
  • unit-address指的是该设备节点的地址,会在reg属性中具体指定,节点名字中可以不包含,但通常情况下都加上个unit-address。
  • label: 相当于该设备节点的指针,方便其他设备节点引用,或者形成层次性的结构。
    • 方便其他设备引用
      对于gic: interrupt-controller@51a00000来说, 设备节点通过&gic来引用该设备节点
      小白带你探索Linux设备树1_框架篇V1_第12张图片
    • 形成层次性的结构
      对于sata: sata@5f020000,该设备节点在fsl-imx8qm-device.dtsi中进行定义了
      小白带你探索Linux设备树1_框架篇V1_第13张图片
      然后又在fsl-imx8qm-mek.dtsi中进行进一步配置
      小白带你探索Linux设备树1_框架篇V1_第14张图片

4.5 reg属性

先来看个reg属性实例
小白带你探索Linux设备树1_框架篇V1_第15张图片
首先reg的第一个地址,对应着unit-address,reg格式的定义由父节点的如下属性所控制。

  • #address-cells
  • #size-cells

reg属性的语法如下

  • reg =

sata父节点的reg属性的限制如下
小白带你探索Linux设备树1_框架篇V1_第16张图片
另外再提一下,reg是根据该soc的RM中描述,下面举个例子
小白带你探索Linux设备树1_框架篇V1_第17张图片
最后为了驱动中方便查询,通常给利用reg-name属性给reg起个别名,sata的reg-name如下

  • reg-names = "ctl", "phy";

4.6 interrupts属性

sata的中断属性如下

  • interrupts = ;

该属性由interrupt-parent属性所限定,如果该节点没有指定interrupt-parent,那么将有父节点的interrupt-parent所限定,sata的父节点的相应属性为。

  • interrupt-parent = <&gic>;

gic节点的定义为

gic: interrupt-controller@51a00000 {
		compatible = "arm,gic-v3";
		reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */
		      <0x0 0x51b00000 0 0xC0000>, /* GICR */
		      <0x0 0x52000000 0 0x2000>,  /* GICC */
		      <0x0 0x52010000 0 0x1000>,  /* GICH */
		      <0x0 0x52020000 0 0x20000>; /* GICV */
		#interrupt-cells = <3>;
		interrupt-controller;
		interrupts = <GIC_PPI 9
			(GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
		interrupt-parent = <&gic>;
	};

注意如下几个宏定义均在相应.h文件中进行声明。

  • GIC_SPI
  • IRQ_TYPE_LEVEL_HIGH

4.7 其他属性

clocks、power-domain、status…等属性都是如法炮制,我就不在这里多解释了。

4.8 特殊节点

  • aliases节点:某些节点的快捷访问方式?官方是这样解释的,但我是没看出来…。
aliases {
		csi0 = &mipi_csi_0;
		csi1 = &mipi_csi_1;
		dpu0 = &dpu1;
		dpu1 = &dpu2;
		ethernet0 = &fec1;
		ethernet1 = &fec2;
		dsi_phy0 = &mipi_dsi_phy1;
		dsi_phy1 = &mipi_dsi_phy2;
		mipi_dsi0 = &mipi_dsi1;
		mipi_dsi1 = &mipi_dsi2;
		ldb0 = &ldb1;
		ldb1 = &ldb2;
		isi0 = &isi_0;
		isi1 = &isi_1;
		isi2 = &isi_2;
		isi3 = &isi_3;
		isi4 = &isi_4;
		isi5 = &isi_5;
		isi6 = &isi_6;
		isi7 = &isi_7;
		serial0 = &lpuart0;
		serial1 = &lpuart1;
		serial2 = &lpuart2;
		serial3 = &lpuart3;
		serial4 = &lpuart4;
		mmc0 = &usdhc1;
		mmc1 = &usdhc2;
		mmc2 = &usdhc3;
		usbphy0 = &usbphy1;
		can0 = &flexcan1;
		can1 = &flexcan2;
		can2 = &flexcan3;
		i2c0 = &i2c_rpbus_0;
		i2c1 = &i2c_rpbus_1;
	};
  • chosen 节点:该节点不代表一个真实设备,通常用于固件和操作系统传递参数的桥梁,就像boot参数。而且其parent node必须是名字是“/”的根节点。
chosen {
		bootargs = "console=ttyLP0,115200 earlycon=lpuart32,0x5a060000,115200";
		stdout-path = &lpuart0;
	};

5. 总结

本文以imx8qm-mek评估板为实例进行介绍DT,让大家对DT的定义、ARM Linux DT的起源、具体评估板DT的文件组织结构、DT的语法组织框架有个简单的认识。本篇博客并没有事无巨细的介绍DT,仅仅是点到为止,而且小编也是刚刚接触设备树,没有太多的经验,如发现错误,还望指出来,大家一起交流共同进步。

过段时间会推出本篇博客的续作小白带你探索Linux设备树2_API篇V1,进行总结一个driver如何使用设备树。

参考文献

主要是国外官方的权威资料

  1. https://elinux.org/Device_Tree_Reference
  2. https://elinux.org/Device_Tree_Usage
  3. https://bootlin.com/pub/conferences/2014/elc/petazzoni-device-tree-dummies/
  4. https://www.nxp.com/docs/en/application-note/AN5125.pdf
  5. http://www.wowotech.net/device_model/dt_basic_concept.html


原创不易,切勿剽窃!

在这里插入图片描述

欢迎大家关注我创建的微信公众号——小白仓库
原创经验资料分享:包含但不仅限于FPGA、ARM、RISC-V、Linux、LabVIEW等软硬件开发,另外分享生活中的趣事以及感悟。目的是建立一个平台记录学习过的知识,并分享出来自认为有用的与感兴趣的道友相互交流进步。

你可能感兴趣的:(linux,驱动程序,arm,kernel)