嵌入式Linux嵌入式Linux驱动开发板级DTS实操与完整实战演练——从修改设备树到点亮LED的完整闭环仓库已经开源所有教程主线内核移植跑新版本imx-linux/uboot都在这里或者一起来尝试跑7.0的Linux欢迎各位大佬观摩喜欢的话点个⭐仓库地址https://github.com/Awesome-Embedded-Learning-Studio/imx-forge静态网页https://awesome-embedded-learning-studio.github.io/imx-forge/前言从理论到实践的跨越跟着教程一路走过来你现在应该对设备树有了相当全面的了解知道它是什么、语法怎么写、OF API 怎么用。上一章我们也完成了从硬编码驱动到设备树驱动的改造。但说实话这些知识如果不动手永远只是纸上谈兵。很多朋友在这个阶段会遇到一个尴尬的问题教程里的示例都看懂了但面对自己手里的开发板却不知道从哪里下手。厂商给的设备树文件一大堆动辄几千行看着就头皮发麻。这一章我们要把之前学的所有知识串起来从空白开始走完整个流程确认板级 DTS 位置、编写 DTS 文件、编译 DTB、编写驱动代码、编译驱动模块、部署到板子、加载驱动测试。这六步走完你就真正掌握了设备树驱动开发的完整闭环。我们的实验目标是点亮 LED。这个实验足够简单不会让你在硬件调试上浪费太多时间同时又涵盖了设备树驱动的所有核心要素——描述硬件而不是编码硬件这就是现代驱动开发的分水岭。环境准备先搞清楚我们在改什么在动手之前最重要的一步是搞清楚我们要改什么。确认开发板型号首先确认你手里的开发板型号。最可靠的方法是看串口启动信息你会看到类似这样的输出Model: Freescale i.MX6 UltraLite 14x14 EVK Board或者Machine: ALIENTEK ATK-IMX6ULL找到板级 DTS 文件确认板子型号之后找到对应的 DTS 文件。在我们的 imx-forge 项目中设备树文件存放在driver/device_tree/alpha-board/目录下。如果使用 NXP 官方 BSP通常在内核源码的arch/arm/boot/dts/目录下。典型的设备树目录结构arch/arm/boot/dts/ ├── imx6ull.dtsi # SOC 级通用定义类似 C 语言头文件 ├── imx6ull-14x14-evk.dts # 官方 EVK 板级文件 ├── imx6ull-14x14-evk.dtb # 编译后的二进制文件 └── ...三种文件的区别.dtsiSOC 级或模块级的通用定义可被多个.dts引用.dts具体的板级定义包含这块板子特有的硬件配置.dtb编译后的二进制设备树内核真正读取的文件重要原则永远不要直接修改.dtsi文件这些文件是公用的修改会影响所有引用它的板子。正确做法是在你的.dts文件里通过引用标签来修改或追加内容。备份原有文件修改之前养成备份的习惯# 备份原始文件cpimx6ull-aes-led.dts imx6ull-aes-led.dts.bak# 或者用 gitgitstash save修改前的备份gitcheckout-bexperiment/device-tree-modification步骤1编写 DTS 设备树文件确定寄存器地址根据 IMX6ULL 芯片手册控制 LED 需要操作以下寄存器寄存器地址用途CCM_CCGR10x020C406C时钟使能SW_MUX_GPIO1_IO030x020E0068GPIO 复用SW_PAD_GPIO1_IO030x020E02F4GPIO 电气属性GPIO1_DR0x0209C000GPIO 数据GPIO1_GDIR0x0209C004GPIO 方向编写设备节点打开设备树文件在我们的项目中位于driver/device_tree/alpha-board/device_tree_try_03/imx6ull-aes-led.dts在根节点/下添加 LED 节点/dts-v1/; #include imx6ull.dtsi #include imx6ull-aes.dtsi / { model Awesome Embedded Studio IMX6ULL Example Driver; compatible fsl,imx6ull-14x14-evk, fsl,imx6ull; imx_aes_led { #address-cells 1; #size-cells 1; compatible atkalpha-led; status okay; reg 0X020C406C 0X04 /* CCM_CCGR1_BASE */ 0X020E0068 0X04 /* SW_MUX_GPIO1_IO03_BASE */ 0X020E02F4 0X04 /* SW_PAD_GPIO1_IO03_BASE */ 0X0209C000 0X04 /* GPIO1_DR_BASE */ 0X0209C004 0X04 ; /* GPIO1_GDIR_BASE */ }; };逐行解析关键部分节点名imx_aes_led直接挂在根节点下完整路径是/imx_aes_led驱动代码通过这个路径查找节点#address-cells 1子节点 reg 属性中地址占 1 个单元格32 位#size-cells 1子节点 reg 属性中长度占 1 个单元格32 位compatible atkalpha-led驱动匹配标识平台设备驱动中会用它来自动匹配status okay设备启用如果设为disabled内核会跳过这个设备reg属性寄存器地址列表格式为地址1 长度1 地址2 长度2…5 个寄存器共 10 个 u32 值新手易踩的坑reg 里的数字必须严格遵循#address-cells和#size-cells定义的格式。我们定义了都是 1所以格式就是地址、长度、地址、长度……以此类推。节点位置选择你可能会问为什么把这个节点直接放在根节点下面答案取决于设备连接方式设备挂在 SOC 内部总线上比如直接操作 GPIO 寄存器→ 放在根节点下设备挂在外部总线上I2C、SPI→ 放在对应的总线节点下如果需要修改现有节点而不是添加新节点可以通过label引用i2c1 { clock-frequency 100000; status okay; /* 覆盖原来的 disabled */ mag31100e { compatible fsl,mag3110; reg 0x0e; }; };语法检查编译之前先检查语法dtc-Idts-Odtb-o/dev/null imx6ull-aes-led.dts没有报错就说明语法基本正确。步骤2编译 DTB内核只能读取二进制的 DTB 文件不能直接读取 DTS 文本文件。使用构建脚本在 imx-forge 项目中最简单的方式cd/home/charliechen/imx-forge ./scripts/driver_helper/build_driver.sh device_tree_try_03 alpha-board脚本会自动完成查找源码和设备树文件 → 编译驱动生成.ko→ 编译设备树生成.dtb→ 产物放到out/driver_artifacts/device_tree_try_03/alpha-board/。手动编译# 基本编译dtc-Idts-Odtb-oimx6ull-aes-led.dtb imx6ull-aes-led.dts# 带 include 路径DTS 引用了其他文件时dtc-Idts-Odtb-idriver/device_tree/alpha-board/\-oimx6ull-aes-led.dtb\driver/device_tree/alpha-board/device_tree_try_03/imx6ull-aes-led.dts反编译验证把编译出来的 DTB 反编译回 DTS 格式对比确认正确性dtc-Idtb-Odts-otest_from_dtb.dts imx6ull-aes-led.dtbgrep-A10imx_aes_ledtest_from_dtb.dts反编译的 DTS 在格式上可能和原始 DTS 有差异但节点结构和属性值应该一致。步骤3编写设备树驱动代码设备树准备好了现在编写驱动。核心逻辑去设备树里把刚才填的值抠出来然后操作寄存器控制 LED。我们的驱动代码分为两个文件led_hw.c负责硬件操作device_tree_try_03_driver_main.c负责字符设备框架。这种分离让代码结构更清晰也便于以后复用。头文件与结构体#includelinux/of.h#includelinux/of_address.hstructled_handle{void__iomem*ccm_ccgr1;void__iomem*sw_mux_gpio;void__iomem*sw_pad_gpio;void__iomem*gpio_dr;void__iomem*gpio_gdir;structdevice_node*device_tree_node;};staticstructled_handleled;linux/of.h提供设备树基础 APIof_find_node_by_path、of_property_read_string等linux/of_address.h提供地址映射 APIof_iomap。结构体最后一个成员device_tree_node保存设备树节点指针后续所有操作都靠它。硬件初始化从设备树获取信息真正的重头戏在led_hw_init里——数据从 DTS 流向内核内存再流向驱动变量intled_hw_init(void){u32 regdata[10];intret;constchar*str;structproperty*proper;u32 val;/* 1. 获取设备节点 */led.device_tree_nodeof_find_node_by_path(/imx_aes_led);if(led.device_tree_nodeNULL){pr_err(dtsled node can not found!\n);return-EINVAL;}pr_info(dtsled node has been found!\n);第一步找人。of_find_node_by_path就像在电话簿里按名字找人。路径必须和 DTS 里写的一样包括根节点/。如果返回 NULL说明设备树里没这个节点或者路径写错了。注意of_find_node_by_path成功时会增加节点引用计数用完后必须调用of_node_put释放否则会内存泄漏。/* 2. 获取 compatible 属性验证性读取 */properof_find_property(led.device_tree_node,compatible,NULL);if(properNULL){pr_err(compatible property find failed\n);}else{pr_info(compatible %s\n,(char*)proper-value);}第二步查户口。of_find_property找具体的属性proper-value指向属性值的原始数据。对于字符串属性可以直接转成char*打印。这里主要是验证性读取——我们通过路径查找节点而非通过 compatible 匹配所以失败也不中断。/* 3. 获取 status 属性 */retof_property_read_string(led.device_tree_node,status,str);if(ret0){pr_err(status read failed!\n);}else{pr_info(status %s\n,str);}第三步看状态。of_property_read_string专读字符串属性。标准值是okay可用和disabled禁用。第三个参数是const char**函数会把字符串地址存到这个指针指向的位置不需要调用者手动释放内存。/* 4. 获取 reg 属性关键 */retof_property_read_u32_array(led.device_tree_node,reg,regdata,10);if(ret0){pr_err(reg property read failed!\n);of_node_put(led.device_tree_node);return-EINVAL;}pr_info(reg data:\n);for(inti0;i10;i){pr_cont(%#X ,regdata[i]);}pr_cont(\n);第四步拿地址。DTS 里 5 组寄存器每组地址长度两个值共 10 个 u32。执行完这一句regdata数组里就存满了我们在 DTS 里写的那串十六进制数字。注意这里读取失败时我们手动调用了of_node_put释放节点引用因为直接 return 了不会走到后面的统一清理逻辑。这个细节很容易遗忘但忘记释放会导致内存泄漏。内存映射使用 of_iomap拿到了物理地址下一步是映射。of_iomap可以直接从 reg 属性中取第 N 组地址进行映射/* 5. 使用 of_iomap 进行寄存器地址映射 */led.ccm_ccgr1of_iomap(led.device_tree_node,0);led.sw_mux_gpioof_iomap(led.device_tree_node,1);led.sw_pad_gpioof_iomap(led.device_tree_node,2);led.gpio_drof_iomap(led.device_tree_node,3);led.gpio_gdirof_iomap(led.device_tree_node,4);if(!led.ccm_ccgr1||!led.sw_mux_gpio||!led.sw_pad_gpio||!led.gpio_dr||!led.gpio_gdir){pr_err(ioremap failed!\n);of_node_put(led.device_tree_node);return-ENOMEM;}of_iomap(node, index)的设计非常巧妙驱动代码不需要知道具体的地址值只需要知道我需要第几个寄存器。索引 0 对应 reg 属性第一组0X020C406C 0X04索引 1 对应第二组以此类推。具体的地址是什么那是设备树的事情。换一块板子只需要改设备树文件驱动代码完全不用动。of_iomap内部会调用ioremap失败时返回NULL。它还会自动处理 reg 属性中的地址转换某些架构上设备树地址可能不是直接的物理地址。配置寄存器映射完成后操作寄存器和硬编码版本完全一样/* 6. 使能 GPIO1 时钟 */valreadl(led.ccm_ccgr1);val~(326);val|(326);writel(val,led.ccm_ccgr1);/* 7. 设置 GPIO1_IO03 复用为 GPIO */writel(5,led.sw_mux_gpio);/* 8. 设置 GPIO1_IO03 电气属性 */writel(0x10B0,led.sw_pad_gpio);/* 9. 设置 GPIO1_IO03 为输出 */valreadl(led.gpio_gdir);val|(13);writel(val,led.gpio_gdir);/* 10. 默认关闭 LED高电平 */valreadl(led.gpio_dr);val|(13);writel(val,led.gpio_dr);pr_info(LED Init OK!\n);return0;}无论地址来自硬编码还是设备树硬件寄存器的操作方式不变。这正是配置与代码分离的好处。LED 控制与资源清理voidled_set_status(bool status){u32 valreadl(led.gpio_dr);if(status){val~(13);/* 低电平点亮 */}else{val|(13);/* 高电平熄灭 */}writel(val,led.gpio_dr);}boolled_get_status(void){u32 valreadl(led.gpio_dr);return(val(13))0;}voidled_hw_deinit(void){if(led.ccm_ccgr1){iounmap(led.ccm_ccgr1);led.ccm_ccgr1NULL;}if(led.sw_mux_gpio){iounmap(led.sw_mux_gpio);led.sw_mux_gpioNULL;}if(led.sw_pad_gpio){iounmap(led.sw_pad_gpio);led.sw_pad_gpioNULL;}if(led.gpio_dr){iounmap(led.gpio_dr);led.gpio_drNULL;}if(led.gpio_gdir){iounmap(led.gpio_gdir);led.gpio_gdirNULL;}if(led.device_tree_node){of_node_put(led.device_tree_node);led.device_tree_nodeNULL;}}资源清理的几个要点检查 NULL 再释放— 防止led_hw_deinit被调用两次时的双重释放释放后置 NULL— 防止悬空指针错误使用时至少触发空指针异常而非内存破坏最后调用of_node_put— 释放设备树节点引用这是设备树 API 的要求字符设备框架代码file_operations、cdev、class、device 等和传统驱动完全一样此处不再赘述完整代码请参考项目中的device_tree_try_03_driver_main.c。步骤4编译驱动模块驱动代码写好了编译生成.ko文件。使用构建脚本cd/home/charliechen/imx-forge ./scripts/driver_helper/build_driver.sh device_tree_try_03 alpha-board脚本会自动处理设置交叉编译工具链 → 指定内核源码路径 → 调用 make 编译 → 产物放到输出目录。手动编译cddriver/device_tree_try_03/alpha-boardmakeMakefile 大致如下obj-m : device_tree_try_03_driver.o device_tree_try_03_driver-y : device_tree_try_03_driver_main.o led_hw.o ARCH : arm CROSS_COMPILE : arm-none-linux-gnueabihf- KDIR : $(PROJECT_ROOT)/third_party/linux-${KERNEL_TYPE} modules: $(MAKE) -C $(KDIR) M$(CURDIR) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) modules注意驱动由两个.o文件组成链接成一个.ko模块。检查编译结果ls-lhout/driver_artifacts/device_tree_try_03/alpha-board/# 预期产物# device_tree_try_03_driver.ko (约14K)# imx6ull-aes-led.dtb (约35K)modinfo device_tree_try_03_driver.ko# 查看 vermagic 确认内核版本匹配如果vermagic显示的内核版本和板子运行的内核不一致模块加载会因版本不匹配而失败。步骤5部署到板子编译好了.ko和.dtb部署到开发板上。部署 DTB 文件TFTP# 使用部署脚本./scripts/driver_helper/deploy_driver.sh device_tree_try_03 alpha-board--targettftp# 或手动拷贝sudocpout/driver_artifacts/device_tree_try_03/alpha-board/imx6ull-aes-led.dtb\/srv/tftp/imx6ull-aes.dtb注意目标文件名是imx6ull-aes.dtb不是imx6ull-aes-led.dtb。U-Boot 启动时加载的 DTB 文件名由环境变量fdt_file决定 printenv fdt_file fdt_fileimx6ull-aes.dtb如果不确定自己的板子用哪个文件名在 U-Boot 命令行输入printenv查看。部署 KO 文件# 通过 NFS./scripts/driver_helper/deploy_driver.sh device_tree_try_03 alpha-board--targetnfs# 或通过 scpscpdevice_tree_try_03_driver.ko root192.168.1.100:/lib/modules/重启并验证设备树部署 DTB 后重启板子验证设备树是否正确加载# 查看节点是否存在ls/proc/device-tree/imx_aes_led/# 查看属性cat/proc/device-tree/imx_aes_led/compatible# 输出atkalpha-ledcat/proc/device-tree/imx_aes_led/status# 输出okayhexdump-C/proc/device-tree/imx_aes_led/reg# 输出寄存器地址列表如果节点不存在说明 DTB 没有正确加载或者节点路径写错了。如果属性值不对说明 DTS 里的属性定义有问题。步骤6加载驱动测试终于到了见证结果的时刻。加载驱动insmod device_tree_try_03_driver.ko# 查看内核日志dmesg|tail-30预期日志[ 12.345678] dtsled node has been found! [ 12.345679] compatible atkalpha-led [ 12.345680] status okay [ 12.345681] reg data: [ 12.345682] 0X20C406C 0X4 0X20E0068 0X4 0X20E02F4 0X4 0X209C000 0X4 0X209C004 0X4 [ 12.345683] LED Init OK! [ 12.345684] LED handle get the device number: major: 245, minor: 0这串日志意味着内核找到了imx_aes_led节点、成功读取了属性、reg data和 DTS 文件中写的完全一致、寄存器映射成功、字符设备创建成功。测试 LED 控制# 检查设备文件ls-l/dev/AES_LED# 点亮 LED低电平有效echo1/dev/AES_LED# 熄灭 LEDecho0/dev/AES_LED# 读取 LED 状态cat/dev/AES_LED看板子上的 LED亮了吗如果亮了恭喜——你完成了完整的设备树驱动开发卸载驱动rmmod device_tree_try_03_driverdmesg|tail# [ 234.567890] Deinit LED Hardware调试技巧与常见问题即使严格按教程操作也可能会遇到各种问题。这里总结最常见的坑点。dmesg 日志分析dmesg是你最好的调试朋友dmesg|tail-20# 最近的消息dmesg|grep-iled# 过滤关键词dmesg-w# 实时监控常见错误排查dtsled node can not found!— 节点找不到检查节点路径注意大小写和前导/检查 DTB 是否正确部署在/proc/device-tree中查看节点是否存在reg property read failed!— reg 属性读取失败检查 DTS 中 reg 属性是否存在确认格式正确地址和长度成对出现用hexdump -C /proc/device-tree/imx_aes_led/reg查看实际值ioremap failed!— 内存映射失败reg 属性中的地址可能无效of_iomap 的索引可能超出 reg 属性中定义的组数检查是否已有其他驱动占用了这些地址编译通过但内核报 “Duplicate node”— 节点重复你在.dts里定义了一个.dtsi里已存在的节点改用label引用现有节点或用/delete-node/删除DTB 部署后不生效— 加载的不是你的 DTBU-Boot 中执行printenv fdt_file确认加载的文件名检查 TFTP 目录下是否有旧文件手动在 U-Boot 里加载tftp 0x83000000 imx6ull-aes.dtb; bootm 0x80800000 - 0x83000000DTC 编译报错 “FDT_ERR_BADSTRUCTURE”— 编译失败但信息模糊检查所有#include指令确保文件存在用-i选项指定 include 路径单独编译被 include 的.dtsi文件排查系统排查清单按以下顺序逐一排查设备树是否加载—/proc/device-tree中有无对应节点驱动是否加载—lsmod中有无模块dmesg有无报错设备文件是否创建—/dev目录下有无设备文件权限是否正确硬件是否正常— LED 连接的 GPIO 是否正确用万用表测量电平驱动逻辑是否正确— 添加更多调试打印或用strace跟踪用户态调用总结这一章我们把所有知识串起来走完了从修改设备树到点亮 LED 的完整闭环。回顾一下环境准备确认板子型号、找到 DTS 文件、备份编写 DTS在设备树中描述硬件而不是在代码中编码硬件编译 DTB用构建脚本或手动 DTC 编译编写驱动通过 OF API 从设备树获取硬件信息用of_iomap映射寄存器编译部署交叉编译.ko模块通过 TFTP/NFS 部署到板子测试验证加载驱动、测试功能、分析日志核心思想只有一个把硬件描述和驱动逻辑彻底解耦。驱动只负责怎么操作一个 GPIO设备树负责这个 GPIO 在哪里。以前移植驱动需要改代码重新编译.ko现在只需改.dts重新编译 DTB几秒钟的事驱动代码连动都不用动。这就是 Linux 内核引入设备树模型的初衷也是构建可移植嵌入式系统的基石。当然我们展示的还是最基础的使用方式。在实际工程中你还会遇到中断、DMA、时钟、电源管理……这些都可以通过设备树描述但万变不离其宗。在未来的学习中你会接触到 Platform 设备驱动框架届时你会发现今天折腾的device_node和 OF 函数在 Platform 驱动里以更标准、更优雅的方式被封装起来。现在找一块开发板把这一章的流程完整走一遍。只有在实践中理论才能变成你自己的技能。相关阅读04. OF API 基础与验证——从 DTS 到代码的桥梁 - 相似度 100%通用GUI编程技术——图形渲染实战四十三——D3D12设计哲学显式控制与性能解锁 - 相似度 82%