设备树何时加入linux内核的
1个回答
展开全部
Linux and the Device Tree
Linux内核设备树数据使用模型。
Open Firmware Device Tree (DT) 是一个数据结构,也是一种描述硬件的语言。准确地说,它是一种能被操作系统解析的描述硬件的语言,这样操作系统就不需要把硬件平台的细节在代码中写死。
从结构上来说,DT是一个树形结构,或者有名结点组成的非循环图,结点可能包含任意数量的有名属性,有名属性又可以包含任意数量的数据。同样存在一种机制,可以创建从一个结点到正常树形结构之外的链接。
从概念上讲,一套通用的使用方法,即bindings。Bindings定义了数据如何呈现在设备树中,怎样描述典型的硬件特性,包括数据总线,中断线,GPIO连接以及外设等。
尽可能多的硬件被描述从而使得已经存在的bindings最大化地使用源代码,但是由于属性名和结点名是简单字符串, 可以通过定义新结点和属性的方式很方便地扩展已经存在的bindings或者创建一个新的binding。在没有认真了解过已经存在的bindings的情况下,创建一个新的binding要慎之又慎。对于I2C总线,通常有两种不同的,互不相容的bindings出现,就是因为新的binding创建时没有研究I2C设备是如何在当前系统中被枚举的。
1. 历史
略
2. 数据模型
请参考Device Tree Usage章节
2.1 High Level View
必须要认识到的是,DT是一个描述硬件的数据结构。它并没有什么神奇的地方,也不能把所有硬件配置的问题都解决掉。它只是提供了一种语言,将硬件配置从Linux Kernel支持的board and device driver中提取出来。DT使得board和device变成数据驱动的,它们必须基于传递给内核的数据进行初始化,而不是像以前一样采用hard coded的方式。
观念上说,数据驱动平台初始化可以带来较少的代码重复率,使得单个内核映像能够支持很多硬件平台。
Linux使用DT的三个主要原因:
1) 平台识别 (Platform Identification)
2) 实时配置 (Runtime Configuration)
3) 设备植入 (Device Population)
2.2 平台识别
第一且最重要的是,内核使用DT中的数据去识别特定机器。最完美的情况是,内核应该与特定硬件平台无关,因为所有硬件平台的细节都由设备树来描述。然而,硬件平台并不是完美的,所以内核必须在早期初始化阶段识别机器,这样内核才有机会运行特定机器相关的初始化序列。
大多数情况下,机器识别是与设备树无关的,内核通过机器的核心CPU或者SOC来选择初始化代码。以ARM平台为例,setup_arch()会调用setup_machine_fdt(),后者遍历machine_desc链表,选择最匹配设备树数据的machine_desc结构体。它是通过查找设备树根结点的compatible属性并与machine_desc->dt_compat进行比较来决定哪一个machine_desc结构体是最适合的。
Compatible属性包含一个有序的字符串列表,它以确切的机器名开始,紧跟着一个可选的board列表,从最匹配到其他匹配类型。以TI BeagleBoard的compatible属性为例,BeagleBoard xM Board可能描述如下:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
在这里,”ti, omap3-beagleboard-xm”是最匹配的模型,"ti,omap3450"次之,"ti,omap3"再次之。
机敏的读者可能指出,Beagle xM也可以声明匹配"ti,omap3-beagleboard",但是要注意的是,板级层次上,两个机器之间的变化比较大,很难确定是否兼容。从顶层上来看,宁可小心也不要去声明一个board兼容另外一个。值得注意的情况是,当一个board承载另外一个,例如一个CPU附加在一个board上。(两种CPU支持同一个board的情况)
Linux内核设备树数据使用模型。
Open Firmware Device Tree (DT) 是一个数据结构,也是一种描述硬件的语言。准确地说,它是一种能被操作系统解析的描述硬件的语言,这样操作系统就不需要把硬件平台的细节在代码中写死。
从结构上来说,DT是一个树形结构,或者有名结点组成的非循环图,结点可能包含任意数量的有名属性,有名属性又可以包含任意数量的数据。同样存在一种机制,可以创建从一个结点到正常树形结构之外的链接。
从概念上讲,一套通用的使用方法,即bindings。Bindings定义了数据如何呈现在设备树中,怎样描述典型的硬件特性,包括数据总线,中断线,GPIO连接以及外设等。
尽可能多的硬件被描述从而使得已经存在的bindings最大化地使用源代码,但是由于属性名和结点名是简单字符串, 可以通过定义新结点和属性的方式很方便地扩展已经存在的bindings或者创建一个新的binding。在没有认真了解过已经存在的bindings的情况下,创建一个新的binding要慎之又慎。对于I2C总线,通常有两种不同的,互不相容的bindings出现,就是因为新的binding创建时没有研究I2C设备是如何在当前系统中被枚举的。
1. 历史
略
2. 数据模型
请参考Device Tree Usage章节
2.1 High Level View
必须要认识到的是,DT是一个描述硬件的数据结构。它并没有什么神奇的地方,也不能把所有硬件配置的问题都解决掉。它只是提供了一种语言,将硬件配置从Linux Kernel支持的board and device driver中提取出来。DT使得board和device变成数据驱动的,它们必须基于传递给内核的数据进行初始化,而不是像以前一样采用hard coded的方式。
观念上说,数据驱动平台初始化可以带来较少的代码重复率,使得单个内核映像能够支持很多硬件平台。
Linux使用DT的三个主要原因:
1) 平台识别 (Platform Identification)
2) 实时配置 (Runtime Configuration)
3) 设备植入 (Device Population)
2.2 平台识别
第一且最重要的是,内核使用DT中的数据去识别特定机器。最完美的情况是,内核应该与特定硬件平台无关,因为所有硬件平台的细节都由设备树来描述。然而,硬件平台并不是完美的,所以内核必须在早期初始化阶段识别机器,这样内核才有机会运行特定机器相关的初始化序列。
大多数情况下,机器识别是与设备树无关的,内核通过机器的核心CPU或者SOC来选择初始化代码。以ARM平台为例,setup_arch()会调用setup_machine_fdt(),后者遍历machine_desc链表,选择最匹配设备树数据的machine_desc结构体。它是通过查找设备树根结点的compatible属性并与machine_desc->dt_compat进行比较来决定哪一个machine_desc结构体是最适合的。
Compatible属性包含一个有序的字符串列表,它以确切的机器名开始,紧跟着一个可选的board列表,从最匹配到其他匹配类型。以TI BeagleBoard的compatible属性为例,BeagleBoard xM Board可能描述如下:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
在这里,”ti, omap3-beagleboard-xm”是最匹配的模型,"ti,omap3450"次之,"ti,omap3"再次之。
机敏的读者可能指出,Beagle xM也可以声明匹配"ti,omap3-beagleboard",但是要注意的是,板级层次上,两个机器之间的变化比较大,很难确定是否兼容。从顶层上来看,宁可小心也不要去声明一个board兼容另外一个。值得注意的情况是,当一个board承载另外一个,例如一个CPU附加在一个board上。(两种CPU支持同一个board的情况)
力控科技
2024-08-19 广告
2024-08-19 广告
ForceSCADA是力控科技信创产品的重要组成部分,具备完全自主知识产权,支持部署在Linux桌面版、服务器版、嵌入式等系统架构下。使用ForceSCADA可以搭建创新性高、扩展性佳、融合度强的SCADA平台,进而构建高效、智能化的监控中...
点击进入详情页
本回答由力控科技提供
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询
广告 您可能关注的内容 |