4、Linux系统基础：嵌入式Linux常用命令、设备树（Device Tree）概念、内核模块加载与驱动框架

RK3568工业AI网关运行于嵌入式Linux环境，其底层硬件管理、外设驱动、资源隔离与通信协议栈均依赖Linux内核能力。本章聚焦三个核心维度：日常开发与排障所需的Shell命令体系、描述硬件拓扑与资源配置的设备树（Device Tree）、以及内核模块的动态加载机制与驱动框架。理解这三者之间的协作关系，是后续实现GPIO控制、串口通信、CAN总线接入以及AI推理加速器初始化的前提。本章将结合RK3568网关的实际硬件资源，梳理从命令行操作到内核驱动交互的完整链路。

上图展示了嵌入式Linux开发中用户空间、内核空间与硬件抽象层之间的协作关系。设备树作为硬件描述的中枢，向下对接RK3568 SoC的物理资源，向上为内核驱动提供标准化的设备注册信息。用户空间的Shell命令通过系统调用访问内核，而内核模块则通过设备树匹配硬件设备并完成驱动绑定。整个链路中，任何一环的配置错误都可能导致外设无法正常工作，因此掌握命令、设备树与驱动框架的联动机制至关重要。

4.1 嵌入式Linux常用命令：从系统信息到外设调试

4.1.1 核心原理：命令是内核与硬件的交互接口

嵌入式Linux的命令体系与桌面Linux基本一致，但更强调对硬件资源的直接观察与控制。在RK3568网关开发中，常用命令可分为四类：系统信息查询（uname、cat /proc/cpuinfo）、内核日志查看（dmesg）、设备节点管理（ls /dev、mknod）、以及外设调试工具（i2cdetect、cansend）。这些命令的本质是通过系统调用或虚拟文件系统（/proc、/sys）与内核交互，从而获取硬件状态或触发内核行为。

4.1.2 操作流程：标准排障命令组合

1. 确认系统版本与内核信息：执行 uname -a 查看内核版本，确认是否匹配当前驱动模块的编译环境。
2. 检查内核启动日志：执行 dmesg | grep -i error 过滤错误信息，定位硬件初始化失败的原因。
3. 查看设备节点是否生成：执行 ls -l /dev/ttyS* /dev/i2c-* 确认外设节点存在，若缺失则检查设备树配置。
4. 使用专用工具测试外设：例如 i2cdetect -y 2 扫描I2C总线上的设备地址，cansend can0 123#DEADBEEF 发送CAN报文。

4.1.3 实战场景：排查串口无法通信问题

假设网关的调试串口（ttyS0）无法输出数据。首先执行 dmesg | grep ttyS0 查看内核是否识别该串口，若输出显示 ttyS0 at MMIO 0xfe660000 则说明设备树配置正确。接着检查引脚复用，执行 cat /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinmux-pins | grep uart0，确认UART0的TX/RX引脚是否被复用为GPIO或其他功能。若发现引脚被占用，需要修改设备树中的 pinctrl-0 属性。最后使用 stty -F /dev/ttyS0 115200 配置波特率，并通过 echo "test" > /dev/ttyS0 发送测试数据。

4.1.4 常见误区与总结

• 误区一：认为 /dev 下的节点是手动创建的。实际上，现代内核通过 devtmpfs 自动创建设备节点，手动 mknod 仅用于特殊场景。
• 误区二：忽略 /sys 文件系统。通过 /sys/class/gpio 可以动态控制GPIO，但工业网关中更推荐使用内核驱动管理GPIO，避免用户空间直接操作带来的竞态问题。
• 总结：命令工具是手段，理解内核对象模型（设备、驱动、总线）才是根本。熟练使用 dmesg、ls /sys/bus/platform/devices 等命令，能快速定位硬件资源分配问题。

4.2 设备树（Device Tree）概念：硬件描述的标准化语言

4.2.1 核心原理：从硬编码到结构化描述

设备树是一种描述硬件资源的数据结构，它解决了ARM Linux早期版本中大量硬件信息硬编码在内核文件（如 arch/arm/mach-xxx）中的问题。在RK3568平台上，设备树源文件（.dts）通过DTC编译器生成二进制设备树（.dtb），由Bootloader加载后传递给内核。内核通过解析设备树，动态创建platform设备，并匹配对应的驱动。设备树的核心价值在于：硬件配置与内核代码解耦，同一份内核镜像可以支持不同硬件配置的网关板卡。

4.2.2 判断方法：设备树节点与驱动匹配规则

设备树中的每个节点包含 compatible 属性，这是驱动匹配的关键。例如，RK3568的I2C控制器节点定义如下：

i2c0: i2c@fe660000 {
    compatible = "rockchip,rk3568-i2c";
    reg = <0x0 0xfe660000 0x0 0x1000>;
    interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cru CLK_I2C0>;
    pinctrl-names = "default";
    pinctrl-0 = <&i2c0_xfer>;
    status = "okay";
};

驱动侧通过 of_match_table 声明支持的 compatible 字符串，内核在注册platform设备时自动匹配。判断设备树是否生效，可执行 ls /sys/bus/platform/devices/fe660000.i2c，若目录存在则说明设备已注册。

4.2.3 案例拆解：为网关添加CAN总线节点

RK3568内置CAN控制器，但默认设备树可能未启用。以下步骤演示如何添加CAN节点：

完成上述操作后，内核启动日志中应出现 CAN device driver interface 信息，且 ip link show can0 能看到CAN接口。

4.2.4 常见误区与总结

• 误区一：认为设备树是内核配置选项。实际上，设备树是独立于内核源码的二进制数据，编译内核和编译设备树是两套流程。
• 误区二：忽略 status 属性。很多外设默认 disabled，需要显式设置为 okay 才能启用。
• 总结：设备树是嵌入式Linux开发的“硬件说明书”，掌握其语法（节点、属性、标签）和编译流程（DTC），是驱动开发的基础能力。

4.3 内核模块加载与驱动框架

4.3.1 核心原理：动态加载与模块化设计

内核模块（.ko 文件）允许在运行时向内核添加功能，无需重新编译整个内核。在RK3568网关中，外设驱动（如GPIO按键、温度传感器、AI加速器）通常以模块形式发布。模块加载通过 insmod 或 modprobe 命令完成，其中 modprobe 会自动处理依赖关系。驱动框架基于Linux设备模型，核心概念包括：总线（bus）、设备（device）、驱动（driver）。RK3568平台主要使用platform总线，设备树注册的节点会挂载到platform总线上，驱动通过 platform_driver_register 注册自身，内核根据 compatible 属性完成匹配。

4.3.2 操作流程：模块编译与加载步骤

1. 准备内核源码：下载与目标系统版本一致的Linux内核，配置交叉编译环境（如 aarch64-linux-gnu-gcc）。
2. 编写驱动代码：实现 probe 和 remove 函数，定义 file_operations 结构体。
3. 编写Makefile：使用内核构建系统编译模块，目标文件为 .ko。
4. 拷贝模块到目标板：通过NFS、SCP或SD卡拷贝到网关文件系统。
5. 加载模块：执行 insmod gpio_led.ko，查看 dmesg 确认初始化成功。
6. 验证功能：通过 echo 1 > /sys/class/leds/led1/brightness 控制LED亮灭。

4.3.3 实战案例：编写并加载一个简单的GPIO驱动

假设网关需要控制一个状态指示灯，驱动代码核心部分如下：

static int led_probe(struct platform_device *pdev) {
    struct device *dev = &pdev->dev;
    int gpio = of_get_named_gpio(dev->of_node, "led-gpios", 0);
    if (gpio_is_valid(gpio)) {
        devm_gpio_request(dev, gpio, "led");
        gpio_direction_output(gpio, 0);
    }
    return 0;
}
static const struct of_device_id led_of_match[] = {
    { .compatible = "gateway,status-led" },
    { }
};
MODULE_DEVICE_TABLE(of, led_of_match);
static struct platform_driver led_driver = {
    .probe = led_probe,
    .driver = {
        .name = "status-led",
        .of_match_table = led_of_match,
    },
};
module_platform_driver(led_driver);

在设备树中添加对应节点：

status-led {
    compatible = "gateway,status-led";
    led-gpios = <&gpio3 RK_PB5 GPIO_ACTIVE_LOW>;
    status = "okay";
};

编译并加载模块后，dmesg 应显示 status-led probe success。若加载失败，检查 gpio_request 是否返回 -EBUSY，说明引脚被其他驱动占用。

4.3.4 常见误区与总结

• 误区一：使用 insmod 加载模块后，不检查 dmesg 输出。模块加载失败时，内核日志会给出具体原因（如 Unknown symbol、Invalid module format）。
• 误区二：忽略模块版本校验。内核编译时启用了 CONFIG_MODVERSIONS，模块必须与当前内核版本匹配，否则加载报 version magic 错误。
• 总结：驱动框架的核心是“匹配-绑定-初始化”流程。理解 platform_driver 与 of_match_table 的协作机制，可以快速适配RK3568上的各类外设。