Linux and the Device Tree
-------------------------
The Linux usage model for device tree data
本文阅读翻译自linux内核的说明文档usage-model.txt
本文讲述linux如何使用device tree，关于device tree数据类型的详细描述可以参考文档：
或者，无法FQ的话，
The "Open Firmware Device Tree", or simply Device Tree (DT)是一种描述硬件的数据结构或者说语言， 更具体地说，DT是一种操作系统可读的硬件描述语言，这样操作系统就不必把硬件详细信息硬编码到代码里。
从结构上来讲，DT是一种树形结构，或者说一种带有命名节点的非循环（acyclic）图。每一个节点，可能有任意个命名属性和任意数据的键值对。也有一种机制，可以让一个节点和树形结构之外的节点建立连接。
从概念上来讲，有一种名为绑定（bindings）的通用的约定来描述，DT的数据如何来描述物理硬件的信息，数据总线、中断线、GPIO连接和外围设备。
在实际操作中，硬件信息应该尽可能的用已经存在的“绑定”来描述，以便最大化的利用现有的代码，但是实际上“属性”和“节点”都是简单的文本字符串，它可以很容易的用来扩展现有的“绑定”或者创建一种新的“绑定”。不管如何，创建一种新的“绑定”需要非常小心，在这之前，一定要先做做功课，了解现有的“绑定”有哪些。现在就有两种关于i2c总线的描述方法，这是因为一种新的i2c设备描述方法创建之前，没有去调查i2c设备已经如何在系统中描述。
1 History
DT最初被OPEN Firmware创建，作为一种从OPEN Firmware传输数据到客户端程序（比如一个操作系统）的传输方法的一部分。操作系统利用DT来实时的获取硬件拓扑结构，从而可以支持多数的硬件设备，而不用将硬件信息硬编码到代码中。（假设驱动程序可用于所有设备）
由于Open Firmware被广泛应用有PowerPC和SPARC平台，linux早已长期使用设备树（Device Tree）来支持这些体系结构。
在2005年，当PowerPC linux开始一次重大的代码清理以合并对32-bit和64bit的支持。当时决定所有的PowerPC平台都需要支持DT，而不管它是否使用了Open Firmware。为了达到这一目标，一个被称为FDT（Flattened Device Tree）的DT版本被设计出来，它可以以二进制的形式传给kernel，而不需要一个真正的Open Firmware。uboot、kexec或者其他bootloaders也都通过修改，支持了传递二进制形式的DT文件（DTB）和在启动阶段修改dtb文件。DT也添加到了PowerPC的引导启动包装器（ arch/powerpc/boot/*）中，所以dtb文件也可以被打包到kernel image文件中来支持在启动阶段没有DT的固件
在一段时间以后，FDT已经应用到了所有的架构。在本文编写的时候，6个主线架构（ arm, microblaze, mips, powerpc, sparc, and x86）和一个非主线架构（nios）都在一定程度支持了DT。
2 Data Model
如果你还没有读过DT的使用说明（
https://elinux.org/Device_Tree_Usage），那么赶紧去读吧！
请读完之后，在继续阅读本文。
2.1 High Level View
理解DT，最重要的事情是，DT就是一种简单的，用来描述硬件信息用的数据数据结构。它没有什么魔力，更没有什么魔法来解决所有的硬件配置问题。它能做的，就是提供一种语言，让板级硬件配置和linux内核（或其他支持DT的操作系统）中支持的设备驱动去耦。使用DT，能让对板卡和设备的支持变成数据驱动；在启动过程中的一些决策将基于传入kernel的数据，而不是硬编码到内核本身。
理想情况下，数据驱动的平台启动方式能够减少kernel中的代码拷贝，能够用简简单单一个kernel image来支持很多的不同硬件设备。
linux使用DT数据有三个主要的目的：
1）平台识别
2）运行时配置
3）设备信息管理
2.2 平台识别
首先，kernel使用DT数据来识别具体的机器型号。在完美的世界里，由于所有的平台细节都能由DT以一种一致且可靠的方式完美描述，特定的平台类型对于kernel来说就不那么重要了。但是硬件不那么完美，所以kernel必须在启动的早期就能识别机器的型号，从而能够有机会运行特定机器对应的特定代码。
在大多数情况下，机器型号识别都是硬件无关的，kernel将根据机器的核心CPU或者Soc来选择setup代码。以ARM为例，函数setup_arch( arch/arm/kernel/setup.c)调用函数 setup_machine_fdt（ arch/arm/kernel/devicetree.c ）来搜索设备描述表（ machine_desc），选择出与DT数据最匹配的设备型号。它通过将DT数据的根节点的 'compatible' 属性与 machine_desc结构体的 dt_compat字段来进行比较，来找到最匹配的设备型号。
'compatible'属性包含一个有序的字符串列表，字符串以准确的机器名字为起始，然后跟着的是一个可选的板卡列表，按照匹配性的高低来排列。比如说，Ti BeagleBoard以及其后续版本 BeagleBoard xM board的根'compatible'属性可能可以这样来写：
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
这里的"ti,omap3-beagleboard-xm"指定了准确的设备型号，它也表明它与 OMAP 3450 SoC兼容，属于ti的omap3系列Soc。 您会注意到，这个compatible列表是从最特定的(确切的板)到最不特定的(SoC族)排序的。
精明的读者可能会指出，BeagleBoard xM board也可以声明与原始版本的BeagleBoard相匹配兼容的。然而，在板卡级别这样做必须非常小心谨慎，因为通常情况下，即使在同一产品线中，从一个板到另一个板之间也会有很大程度的变化，当一个板声称与另一个板兼容时，很难确切地确定这意味着什么。从更高层次看，宁可谨慎行事，也不要声称一个板卡与另一个板卡兼容。值得注意的例外是，一个板卡是另一个的载板时，比如一个附加在载板的CPU模块。
关于“ compatible”，还有一个值得注意事项， compatible属性中使用任何字符串都必须根据它所指示的内容进行记录，并将“ compatible”字符串归档。（Documentation/devicetree/bindings）
未完待续。。。。。。。。。。。。