在传统Linux内核中，ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx，比如板上的platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data，这些板级细节代码对内核来讲只不过是垃圾代码。而采用Device Tree后，许多硬件的细节可以直接透过它传递给Linux，而不再需要在kernel中进行大量的冗余编码。导致ARM的merge工作量较大，其次ARM很多的代码都是垃圾，代码里面有若干愚蠢的table，而多个人在维护这个table，从而导致了冲突。
Linux内核从3.x开始引入设备树的概念，用于实现驱动代码与设备信息相分离。在设备树出现以前，所有关于设备的具体信息都要写在驱动里，一旦外围设备变化，驱动代码就要重写。引入了设备树之后，驱动代码只负责处理驱动的逻辑，而关于设备的具体信息存放到设备树文件中，这样，如果只是硬件接口信息的变化而没有驱动逻辑的变化，驱动开发者只需要修改设备树文件信息，不需要改写驱动代码。比如在ARM Linux内，一个.dts(device tree source)文件对应一个ARM的machine，一般放置在内核的"arch/arm/boot/dts/"目录内，比如exynos4412参考板的板级设备树文件就是"arch/arm/boot/dts/exynos4412-origen.dts"。这个文件可以通过$make dtbs命令编译成二进制的.dtb文件供内核驱动使用。
基于同样的软件分层设计的思想，由于一个SoC可能对应多个machine，如果每个machine的设备树都写成一个完全独立的.dts文件，那么势必相当一些.dts文件有重复的部分，为了解决这个问题，Linux设备树目录把一个SoC公用的部分或者多个machine共同的部分提炼为相应的.dtsi文件。这样每个.dts就只有自己差异的部分，公有的部分只需要"include"相应的.dtsi文件, 这样就是整个设备树的管理更加有序。
对ARM平台的相关code做出如下相关规范调整，这个也正是引入DTS的原因：
1、ARM的核心代码仍然保存在arch/arm目录下 2、ARM SoC core architecture code保存在arch/arm目录下 3、ARM SOC的周边外设模块的驱动保存在drivers目录下 4、ARM SOC的特定代码在arch/arm/mach-xxx目录下 5、ARM SOC board specific的代码被移除，由DeviceTree机制来负责传递硬件拓扑和硬件资源信息。
Device Tree改变了原来用hardcode方式将HW 配置信息嵌入到内核代码的方法，改用bootloader传递一个DB的形式。对于基于ARM CPU的嵌入式系统，我们习惯于针对每一个platform进行内核的编译。但是随着ARM在消费类电子上的广泛应用（甚至桌面系统、服务器系统），我们期望ARM能够象X86那样用一个kernel image来支持多个platform。在这种情况下，如果我们认为kernel是一个black box，那么其输入参数应该包括：
1、识别platform的信息 2、runtime的配置参数 3、设备的拓扑结构以及特性
对于嵌入式系统，在系统启动阶段，bootloader会加载内核并将控制权转交给内核，此外，还需要把上述的三个参数信息传递给kernel，以便kernel可以有较大的灵活性。在linux kernel中，Device Tree的设计目标就是如此。
在devie tree中，可描述的信息包括：
1、CPU的数量和类别 2、内存基地址和大小 3、总线和桥 4、外设连接 5、中断控制器和中断的使用情况 6、GPIO控制器和GPIO使用情况 7、clock控制器和clock使用情况
它基本就是一棵电路板上的CPU、总线、设备组成的树，Bootloader会将这棵树传递给内核，然后内核来识别这棵树，并根据它展开出Linux内核中的platform_device、i2c_client、spi_device等设备，而这些设备用到的内存、IRQ等资源，也被传递给内核，内核会将这些资源绑定给展开的相应设备。
参考博文：
http://www.wowotech.net/device_model/why-dt.html
https://www.cnblogs.com/xiaojiang1025/p/6131381.html
https://blog.csdn.net/u012489236/article/details/97137007
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
