驱动进化之路：设备树的引入及简明的教程（imx6ull）

最新推荐文章于 2023-09-14 12:03:53 发布

你笑一笑嘛

最新推荐文章于 2023-09-14 12:03:53 发布

阅读量999

点赞数 2

分类专栏： imx6ull

本文链接：https://blog.csdn.net/H_A666/article/details/117405318

版权

imx6ull 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

设备树

设备树只是用来给内核里的驱动程序，指定硬件的信息。比如 LED 驱动，在内核的驱动程序里去操作寄
存器，但是操作哪一个引脚？这由设备树指定。

设备树的格式：

/{         //根节点用什么表示呢？和内核一样 用"/"表示，根节点的表示就是“ /{}; ”
    cpu{    //根节点中的CPU节点表示方法
        //节点里面有属性
        name = val;//name可以随便取，但是val不行
        /*   val有三种取值方法
         *   1."string"  //双引号里面表示字符串，可以随便写
         *   2. <u32 u32 u32> //尖括号里面表示32的数字（可以用十进制表示也可以用十六进制表示），放多少个数值都可以
         *   3. [12 34 45] //中括号表示十六进制
         *   4.还可以组合 <0x123>, "zhaohiap", [34]
         */
    };
    
    memory{
        
    };
    
    iic{
         at24c02{
         };   
    };
}

设备树中的基本单元，被称为节点“node”。节点的格式为

[label:] node-name[@unit-address] {// 标号：节点名（必须有）@节点地址
    [properties definitions] //各种属性
    [child nodes] //子节点
};

label 是标号，可以省略。 label 的作用是为了方便地引用 node，比如

/ {
uart0: uart@fe001000 {
    compatible="ns16550";
    reg=<0xfe001000 0x100>;
    };
};

可以使用下面 2 种方法来修改 uart@fe001000 这个 node：

// 在根节点之外使用 label 引用 node：
&uart0 {
    status = “disabled”;
};
或在根节点之外使用全路径：
&{/uart@fe001000} {
    status = “disabled”;
};

设备树常用的节点

1、根节点：

dts文件中必须有一个根节点：
/ {
    model = "SMDK24440";
    compatible = "samsung,smdk2440";
    #address-cells = <1>;
    #size-cells = <1>;
};

根节点中必须有这些属性：

#address-cells // 在它的子节点的 reg 属性中, 使用多少个 u32 整数来描述地址(address)
#size-cells // 在它的子节点的 reg 属性中, 使用多少个 u32 整数来描述大小(size)
compatible // 定义一系列的字符串, 用来指定内核中哪个 machine_desc 可以支持本设备
// 即这个板子兼容哪些平台
// uImage : smdk2410 smdk2440 mini2440 ==> machine_desc
model // 咱这个板子是什么
// 比如有 2 款板子配置基本一致, 它们的 compatible 是一样的

2、CPU节点
一般不需要我们设置，在 dtsi 文件中都定义好了：

cpus {
    #address-cells = <1>;
    #size-cells = <0>;
    cpu0: cpu@0 {
        .......
    }
};

3、memory 节点
芯片厂家不可能事先确定你的板子使用多大的内存，所以 memory 节点需要板厂设置，比如：

memory {
    reg = <0x80000000 0x20000000>;
};

4、chosen 节点（虚拟节点来的）
我们可以通过设备树文件给内核传入一些参数，这要在 chosen 节点中设置 bootargs 属性：

chosen {
    bootargs = "noinitrd root=/dev/mtdblock4 rw init=/linuxrc console=ttySAC0,115200";
};

常用的属性

1. #address-cells、 #size-cells
cell 指一个 32 位的数值，

address-cells： address 要用多少个 32 位数来表示；
size-cells： size 要用多少个 32 位数来表示。

例子：

/ {
    #address-cells = <1>;//表示用一个32位的数据表示地址
    #size-cells = <1>;//表示用一个32位的数据表示大小
    memory {
        reg = <0x80000000 0x20000000>;//0x80000000 来表示地址,0x20000000 表示大小
    };
};

2. compatible
“compatible” 表示“兼容”，对于某个 LED，内核中可能有 A、 B、 C 三个驱动都支持它，那可以这样写：

led {
    compatible = “A”, “B”, “C”;//它的值是一个字符串链表
};

内核启动时，就会为这个 LED 按这样的优先顺序为它找到驱动程序： A、 B、
C。一般引用“compatible”都是为了寻找驱动使用的。
根节点下也有 compatible 属性，用来选择哪一个“ machine desc” ：一个内核可以支持 machine A，也支持
machine B，内核启动后会根据根节点的 compatible 属性找到对应的 machine desc
结构体，执行其中的初始化函数。
compatible 的值，建议取这样的形式： “manufacturer,model”，即“厂家名,模块名”。
注意： machine desc 的意思就是“机器描述”，学到内核启动流程时才涉及。

3. model
model 属性与 compatible 属性有些类似，但是有差别。
compatible 属性是一个字符串列表，表示可以你的硬件兼容 A、 B、 C 等驱动；
model 用来准确地定义这个硬件是什么。
比如根节点中可以这样写：

/ {
compatible = "samsung,smdk2440", "samsung,mini2440";
model = "jz2440_v3";
};

它表示这个单板，可以兼容内核中的“ smdk2440”，也兼容“ mini2440”。
从 compatible 属性中可以知道它兼容哪些板，但是它到底是什么板？用 model 属性来明确。

4. status
dtsi 文件中定义了很多设备，但是在你的板子上某些设备是没有的。这时你可以给这个设备节点添加一个 status 属性，设置为“ disabled”：

&uart1 {
    status = "disabled";
};

5. reg
reg 的本意是 register，用来表示寄存器地址。
但是在设备树里，它可以用来描述一段空间。反正对于 ARM 系统，寄存器和内存是统一编址的，即访寄存器时用某块地址，访问内存时用某块地址，在访问方法上没有区别。
reg 属性的值，是一系列的“ address size”，用多少个 32 位的数来表示 address 和 size，由其父节点的#address-cells、 #size-cells 决定。
示例：

/dts-v1/;
/ {
    #address-cells = <1>;
    #size-cells = <1>;
    memory {
        reg = <0x80000000 0x20000000>;//一段一段的表示空间，也可以用来表示CPU
    };
};

内核对设备树的处理

从源代码文件 dts 文件开始，设备树的处理过程为：DTS----->DTB---->device_node---->platform_device
① dts 在 PC 机上被编译为 dtb 文件；
② u-boot 把 dtb 文件传给内核；
③ 内核解析 dtb 文件，把每一个节点都转换为 device_node 结构体；
④ 对于某些 device_node 结构体，会被转换为 platform_device 结构体。

dtb 中每一个节点都被转换为 device_node 结构体

struct device_node {
	const char *name;
	const char *type;
	phandle phandle;
	const char *full_name;
	struct fwnode_handle fwnode;

	struct	property *properties;//properties是节点的属性，节点的属性里面有哪些内容呢？有名字，有值等等内容。
	struct	property *deadprops;	/* removed properties */
	struct	device_node *parent;
	struct	device_node *child;
	struct	device_node *sibling;
	struct	kobject kobj;
	unsigned long _flags;
	void	*data;
#if defined(CONFIG_SPARC)
	const char *path_component_name;
	unsigned int unique_id;
	struct of_irq_controller *irq_trans;
#endif
}

struct property {
	char	*name;
	int	length;
	void	*value;
	struct property *next;
	unsigned long _flags;
	unsigned int unique_id;
	struct bin_attribute attr;
};

注意：并不是所以的device_node都会转换成platform_device
那么哪些设备树的节点会被转换成platform_device呢？

1、根节点下含有 compatile 属性的子节点

i2c {
	compatile = "samsung,i2c";
	at24c02 {
		compatile = "at24c02";
	};
};

/i2c 节点一般表示 i2c 控制器, 它会被转换为 platform_device, 在内核中有对应的 platform_driver;
/i2c/at24c02 节点不会被转换为 platform_device, 它被如何处理完全由父节点的 platform_driver决定, 一般是被创建为一个 i2c_client

2、含有特定 compatile 属性的节点的子节点
如果一个节点的 compatile 属性，它的值是这 4 者之一： “simple-bus”,“simplemfd”,“isa”,“arm,amba-bus”,那么它的子结点(需含 compatile 属性)也可以转换为 platform_device。

mytest {
	compatile = "mytest", "simple-bus";
	mytest@0 {
		compatile = "mytest_0";
	};
};

/mytest 会被转换为 platform_device, 因为它兼容"simple-bus";它的子节点/mytest/mytest@0 也会被转换为 platform_device。

3、总线 I2C、 SPI 节点下的子节点：不转换为 platform_device
某个总线下到子节点，应该交给对应的总线驱动程序来处理, 它们不应该被转换为 platform_device。

spi {
	compatile = "samsung,spi";
	flash@0 {
		compatible = "winbond,w25q32dw";
		spi-max-frequency = <25000000>;
		reg = <0>;
	};
};

/spi 节点, 它一般也是用来表示 SPI 控制器, 它会被转换为 platform_device, 在内核中有对应的 platform_driver;
/spi/flash@0 节点不会被转换为 platform_device, 它被如何处理完全由父节点的 platform_driver决定, 一般是被创建为一个 spi_device。

platform_device 与 platform_driver 配对

从设备树转换得来的 platform_device 会被注册进内核里，以后当我们每注册一个 platform_driver
时，它们就会两两确定能否配对，如果能配对成功就调用 platform_driver 的 probe 函数。

static int platform_match(struct device *dev, struct device_driver *drv)
{
	struct platform_device *pdev = to_platform_device(dev);
	struct platform_driver *pdrv = to_platform_driver(drv);
 
	/* When driver_override is set, only bind to the matching driver */
	if (pdev->driver_override)
		return !strcmp(pdev->driver_override, drv->name);
 
	/* Attempt an OF style match first */
	if (of_driver_match_device(dev, drv))
		return 1;
 
	/* Then try ACPI style match */
	if (acpi_driver_match_device(dev, drv))
		return 1;
 
	/* Then try to match against the id table */
	if (pdrv->id_table)
		return platform_match_id(pdrv->id_table, pdev) != NULL;
 
	/* fall-back to driver name match */
	return (strcmp(pdev->name, drv->name) == 0);
}

struct platform_device {
	const char	*name;
	int		id;
	bool		id_auto;
	struct device	dev;
	u32		num_resources;
	struct resource	*resource;

	const struct platform_device_id	*id_entry;
	char *driver_override; /* Driver name to force a match */

	/* MFD cell pointer */
	struct mfd_cell *mfd_cell;

	/* arch specific additions */
	struct pdev_archdata	archdata;
};

struct platform_driver {
	int (*probe)(struct platform_device *);
	int (*remove)(struct platform_device *);
	void (*shutdown)(struct platform_device *);
	int (*suspend)(struct platform_device *, pm_message_t state);
	int (*resume)(struct platform_device *);
	struct device_driver driver;
	const struct platform_device_id *id_table;
	bool prevent_deferred_probe;
};

1、最先比较：是否强制选择某个 driver
比较结构体platform_device里的. driver_override成员和结构体platform_driver里的成员.driver结构体里的.name成员
可以设置 platform_device 的 driver_override，强制选择某个 platform_driver。

struct device_driver {
	const char		*name;
	struct bus_type		*bus;

	struct module		*owner;
	const char		*mod_name;	/* used for built-in modules */

	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
	enum probe_type probe_type;

	const struct of_device_id	*of_match_table;
	const struct acpi_device_id	*acpi_match_table;

	int (*probe) (struct device *dev);
	int (*remove) (struct device *dev);
	void (*shutdown) (struct device *dev);
	int (*suspend) (struct device *dev, pm_message_t state);
	int (*resume) (struct device *dev);
	const struct attribute_group **groups;

	const struct dev_pm_ops *pm;

	struct driver_private *p;
};

2、然后比较：设备树信息
比较： platform_device. dev.of_node 和 platform_driver.driver.of_match_table。
由设备树节点转换得来的 platform_device 中，含有一个结构体： of_node。
它的类型如下：

struct device_node {
	const char *name;//来自节点的name属性
	const char *type;//来自节点的device_type属性
	phandle phandle;
	const char *full_name;
	struct fwnode_handle fwnode;

	struct	property *properties;//含有compatible属性
}

如果一个 platform_driver 支持设备树，它的 platform_driver.driver.of_match_table 是一个数组，
类型如下：

/*
 * Struct used for matching a device
 */
struct of_device_id {
	char	name[32];
	char	type[32];
	char	compatible[128];
	const void *data;
};

使用设备树信息来判断 dev 和 drv 是否配对

首先，如果 of_match_table 中含有 compatible 值，就跟 dev 的 compatile 属性比较，若一致则成功，否则返回失败；
也就是compatible和含有compatible属性的properties比较
在这里插入图片描述
其次，如果 of_match_table 中含有 type 值，就跟 dev 的 device_type 属性比较，若一致则成功，否则返回失败；

最后，如果 of_match_table 中含有 name 值，就跟 dev 的 name 属性比较，若一致则成功，否则返回失败。

而设备树中建议不再使用 devcie_type 和 name 属性，所以基本上只使用设备节点的 compatible 属性来寻找匹配的 platform_driver。

假设节点转换成的platform_device与platform_driver匹配成功了，那platform_driver怎么获得platform_device里面的资源呢？

拿个例子
在这个例子当中/mytest /mytest@0会转换成platform_device

mytest {
    compatile = "mytest", "simple-bus";
    mytest@0 {
        compatile = "mytest_0";
        如果这个节点中有reg属性，这个reg属性就会转换成MEM资源
        如果有interrupt属性，就会转换成IRQ（中断）资源
        就可以使用platform_get_resource获得这里的资源
        对于其他属性呢？
        例如：
        pin = xxx这一个属性并不是标准属性，我们要用什么来获取呢？
        可以使用内核提供的函数。
        在根节点中，有一个device_node结构体，这个结构体保存在全局变量of_root里面。
        我们就可以去访问这个全局变量根节点，就能访问各个节点了
        具体怎么找到节点，怎么获取属性，怎么获取值查看开发手册      
    };
};

对于设备树节点中的 reg 属性，它对应 IORESOURCE_MEM 类型的资源；
对于设备树节点中的 interrupts 属性，它对应IORESOURCE_IRQ 类型的资源。

（imx6ull）LED模板驱动程序的改造：设备树

小提示：内核源码我使用的是百问网的

1 设备树节点要与 platform_driver 能匹配

在我们的工作中，驱动要求设备树节点提供什么，我们就得按这要求去编写设备树。但是，匹配过程所要求的东西是固定的：
① 设备树要有 compatible 属性，它的值是一个字符串
② platform_driver 中要有 of_match_table，其中一项的.compatible 成员设置为一个字符串
③ 上述 2 个字符串要一致
在这里插入图片描述

2、设备树节点指定资源， platform_driver 获得资源
如果在设备树节点里使用 reg 属性，那么内核生成对应的 platform_device 时会用 reg 属性来设置IORESOURCE_MEM 类型的资源。

如果在设备树节点里使用 interrupts 属性，那么内核生成对应的platform_device 时会用 reg 属性来设置 IORESOURCE_IRQ 类型的资源。对于 interrupts 属性，内核会检查它的有效性，所以不建议在设备树里使用该属性来表示其他资源

在我们的工作中，驱动要求设备树节点提供什么，我们就得按这要求去编写设备树。驱动程序中根据pin 属性来确定引脚，那么我们就在设备树节点中添加 pin 属性。设备树节点中：

#define GROUP_PIN(g,p) ((g<<16) | (p))

 /{
 	100ask_led@0 {
        compatible = "imx6ull,leddrv";
        pin = <GROUP_PIN(3, 1)>;
    };
    100ask_led@1 {
        compatible = "imx6ull,leddrv";
        pin = <GROUP_PIN(5, 3)>;
    };
  };

驱动程序中，在platform_device 中添加了属性，就能在platform_driver获得属性，可以从 platform_device 中得到 device_node，再用 of_property_read_u32 得到属性的值：

struct device_node* np = pdev->dev. of_node;
int led_pin;
int err = of_property_read_u32(np, “pin”, &led_pin);

想让内核支持设备树的话得让platform_driver结构体中加一个成员变量of_match_table
需要从platform_device结构体里面找到设备节点取出里面的pin属性

demo

/* 创建设备 */
static int chip_demo_gpio_probe(struct platform_device *pdev)
{
	struct device_node *np;
	int err = 0;
	int led_pin;

	np = pdev->dev.of_node;
	if(!np)
		return -1;

	err = of_property_read_u32(np, "pin", &led_pin);
	//当我们装载驱动程序时，对于 led 设备节点都会调用probe函数。会调用两次probe函数。   

	/* 记录设备资源中的引脚信息 */
	g_ledpins[g_ledcnt] = led_pin;

	/* device_create 
	 * 由于device_create函数中led_class变量在上层文件中，不能够直接调用device_create
	 * 可以将device_create封装进函数中
	 */
	led_class_create_device(g_ledcnt);
	g_ledcnt++;
	
	return 0;
}

/* 销毁设备 */
static int chip_demo_gpio_remove(struct platform_device *pdev)
{
	struct device_node *np;
	int err = 0;
	int led_pin;
	int i;

	np = pdev->dev.of_node;
	if(!np)
		return -1;
	
	err = of_property_read_u32(np, "pin", &led_pin);

	for(i=0; i<g_ledcnt; i++){
		if(g_ledpins[i] == led_pin){
			led_class_destroy_device(i);
			g_ledpins[i] = -1;
		}
	}

	for(i=0; i<g_ledcnt; i++){
		if(g_ledpins[i] != -1)
			break;
	}

	if(i == g_ledcnt)
		g_ledcnt = 0;
	
	return 0;
}

static struct led_operations board_demo_led_opr = {
	.init = board_demo_led_init,
	.ctl = board_demo_led_ctl
};

struct led_operations *get_board_led_opr(void)
{
	return &board_demo_led_opr;
}

static const struct of_device_id imx6ull_leds[] = {
    { .compatible = "imx6ull,leddrv" },
    { },
};

static struct platform_driver chip_demo_gpio_driver = {
	/* 当设备平台与驱动平台匹配成功之后，会调用probe函数 */
	.probe = chip_demo_gpio_probe,
	/* 当移除设备的时候会调用remove函数，与probe函数对应 */
	.remove = chip_demo_gpio_remove,
	.driver = {
		.name = "imx6ull_led",/* 需要与platform_device .name一致，这样才能够匹配 */
		.of_match_table = imx6ull_leds,
	},
};

编译设备树

对百问网 imx6ull 全功能板
设备树文件是：内核源码目录中 arch/arm/boot/dts/100ask_imx6ull-14x14.dts
修改、编译后得到 arch/arm/boot/dts/100ask_imx6ull-14x14.dtb 文件。

vi 100ask_imx6ull-14x14.dts

在这里插入图片描述
修改后保存退出，进入到/home/book/100ask_imx6ull-sdk/Linux-4.9.88目录下编译

make dtbs

就会得到一个新的设备树文件
在这里插入图片描述
将这个设备树文件拷贝到板子里去

cp arch/arm/boot/dts/100ask_imx6ull-14x14.dtb ~/nfs_rootfs/

登录板子，进入到包子的/boot目录，就能查看到设备树文件，先我们要备份一份板子自身的设备树文件。

cp 100ask_imx6ull-14x14.dtb 100ask_imx6ull-14x14_bak.dtb

在这里插入图片描述
随后将自己写的设备树文件拷贝进来

cp /mnt/100ask_imx6ull-14x14.dtb .

然后重启（reboot），查看自己写的设备树文件是否写进来了。

进入目录

cd /sys/firmware/devicetree/base

可以看到我们写的设备树节点
在这里插入图片描述

你笑一笑嘛

关注

2
点赞
踩
19

收藏

觉得还不错? 一键收藏
1
评论
驱动进化之路：设备树的引入及简明的教程（imx6ull）

设备树设备树只是用来给内核里的驱动程序，指定硬件的信息。比如 LED 驱动，在内核的驱动程序里去操作寄存器，但是操作哪一个引脚？这由设备树指定。设备树的格式：/{ //根节点用什么表示呢？和内核一样用"/"表示，根节点的表示就是“ /{}; ” cpu{ //根节点中的CPU节点表示方法 //节点里面有属性 name = val;//name可以随便取，但是val不行 /* val有三种取值方法
复制链接

扫一扫