起因:简单重复的板级硬件信息内容都写在linux内核中十分冗余臃肿,将他们抽离出来单独用一种文件描述,这种文件就是dtb
设备树组成:1个dts文件+多个dtsi文件,编译成dtb文件就是真正的设备树
兼容C语言特性,可以使用include包含其他dtsi和.h文件
树形结构
/{
根节点里面 可以 包含 子节点和 属性
...
...
}
格式:
node-name@unit-address
{
子节点可以包含其他后辈节点 以及 属性
...
...
}
node-name是节点名字:“uart1”表示这个节点是UART1外设
unit-address:一般表示设备的地址或者寄存器的首地址。因为不是每个设备都有地址,如CPU和Intrrupt-Controller,没有地址就不写
标签主要方便引用:
格式:
label: node-name@unit-address
就是用label:标记一下上面子节点的格式
实例:
cpu0: cpu@0
这里的label就是cpu0,实际引用时通过 &cpu0
来引用,不需要输入完整的节点名字
属性都是键值对
值有四种情况:
属性有自己定义的属性,自由书写,有点像写python变量的意思,标准属性是已经定义了的属性。
不同的设备需要的属性不同,用户可以自定义属性。除了用户自定义属性,有很多属性是标准属性,Linux 下的很多外设驱动都会使用这些标准属性,几个常用的标准属性:
aliase:
用于给一个节点起别名,功能上和label重复了,&label的方式去引用一个节点也是不错的
chosen:
主要为了向uboot和linux内核传递数据,如bootargs参数的值
可以从该网站阅读Linux内核代码
获取节点信息:
of_find_node_by_name // - Find a node by its "name" property
of_find_node_by_type // - Find a node by its "device_type" property
of_find_compatible_node //- Find a node based on type and one of the tokens in its "compatible" property
of_find_matching_node_and_match // - Find a node based on an of_device_id match table.
of_find_node_by_path //
查找节点的父/子节点:
of_get_parent
of_get_next_child
或者节点属性值的接口:
of_find_property 函数
of_property_count_elems_of_size 函数
of_property_read_u32_index 函数
of_property_read_u8_array 函数
of_property_read_u16_array 函数
of_property_read_u32_array 函数
of_property_read_u64_array 函数
of_property_read_u8 函数
of_property_read_u16 函数
of_property_read_u32 函数
of_property_read_u64 函数
of_property_read_string 函数
of_n_addr_cells 函数
of_n_size_cells 函数
https://blog.csdn.net/qq_28992301/article/details/53321610