嵌入式Linux设备树与驱动开发实战指南

1. 嵌入式 Linux 设备树与驱动开发全景解析

作为一名在嵌入式领域摸爬滚打多年的开发者，我深知设备树和驱动开发是打通硬件与软件的关键桥梁。记得我第一次接触设备树时，面对那些陌生的节点和属性，完全摸不着头脑。经过多个项目的实战积累，现在终于能够游刃有余地处理各种设备树配置和驱动优化问题。本文将系统性地分享我的实战经验，带你从零开始掌握嵌入式Linux设备树与驱动开发的核心技能。

2. 设备树基础与工作原理

2.1 设备树的革命性意义

在设备树出现之前，嵌入式Linux的开发简直是一场噩梦。每个新的硬件平台都需要修改内核源码并重新编译，导致内核变得越来越臃肿。我曾经参与过一个项目，为了支持三款不同的硬件平台，内核中充斥着大量的#ifdef条件编译，维护起来苦不堪言。

设备树的引入彻底改变了这一局面。它将硬件描述从内核代码中分离出来，使得同一份内核可以适配不同的硬件平台。这种解耦带来的好处是显而易见的：

• 内核体积显著减小
• 硬件适配更加灵活
• 不同硬件平台的切换只需更换DTB文件
• 大大降低了内核维护的复杂度

2.2 设备树的组成要素

设备树的核心由三个部分组成，理解这些概念是后续开发的基础：

1. 节点(Node)：设备树的基本构建块，每个节点代表一个硬件设备或总线。节点的命名通常遵循@

   的格式，例如i2c@12340000表示基地址为0x12340000的I2C控制器。

2. 属性(Property)：描述节点特性的键值对。常见的标准属性包括：

   • compatible：设备兼容性标识，用于驱动匹配
   • reg：设备的寄存器地址和大小
   • interrupts：设备使用的中断信息
   • status：设备状态，如"okay"或"disabled"

3. 设备树源文件(DTS/DTSI)：人类可读的文本文件，开发者通过编辑这些文件来描述硬件。DTSI是包含文件，用于存放可重用的定义。

2.3 设备树的工作流程

设备树在整个系统启动过程中扮演着关键角色，其工作流程可以分为以下几个阶段：

1. 编译阶段：使用DTC(Device Tree Compiler)将DTS文件编译成DTB(Device Tree Blob)二进制文件。这个阶段会进行语法检查和部分语义验证。

2. 加载阶段：Bootloader(如U-Boot)将内核镜像和DTB文件加载到内存中，并将DTB的地址传递给内核。

3. 解析阶段：内核启动时，OF(Open Firmware)子系统会解析DTB文件，将其转换为内部的数据结构。

4. 匹配阶段：内核根据设备树中的信息初始化平台设备，并与相应的驱动进行匹配。

3. 设备树编写实战

3.1 基础语法与结构

一个完整的设备树文件通常包含以下结构：

dts复制/dts-v1/;  // 指定设备树版本
/ {
    #address-cells = <1>;  // 子节点reg属性中地址部分的长度
    #size-cells = <1>;     // 子节点reg属性中大小部分的长度
    
    compatible = "vendor,board-name";  // 板级兼容性标识
    
    // 子节点定义
    soc {
        // SOC内部外设定义
    };
};

3.2 典型外设配置示例

以常见的I2C接口温度传感器TMP102为例，下面是一个完整的设备树配置：

dts复制&i2c1 {  // 引用已有的I2C控制器节点
    status = "okay";  // 启用该控制器
    clock-frequency = <100000>;  // 设置I2C时钟频率为100kHz
    
    tmp102@48 {
        compatible = "ti,tmp102";  // 驱动匹配标识
        reg = <0x48>;             // I2C从设备地址
        vdd-supply = <&vdd_3v3>;  // 电源供应
        interrupt-parent = <&gpio1>;  // 中断控制器
        interrupts = <15 IRQ_TYPE_LEVEL_LOW>;  // GPIO1_15,低电平触发
        temperature-precision = <12>;  //