)
文章目录一、概述二、形象比喻:一间工厂的人事体系三、DM 核心概念三要素四、DM 驱动声明完整模板U_BOOT_DRIVER 关键字段说明五、DM 驱动生命周期DM 标志(flags)六、UCLASS 类别完整一览UCLASS 的使用方式七、设备树中的 DM 绑定示例八、DM 的典型使用场景场景1:DM 初始化调试场景2:驱动 probe 失败排查📝 本章小结🏠 课后练习从这一章开始进入 U-Boot 驱动模型的学习。前面几节讲了 U-Boot 的架构、启动流程、配置系统,现在要回答一个核心问题:U-Boot 是怎么管理它那一堆硬件驱动的?为什么 RK3506 的 GPIO、I2C、MMC 驱动写出来都是同一个套路?这背后就是 DM 框架。这一章先解决四个问题:DM 框架的三要素是什么、U_BOOT_DRIVER 宏怎么声明一个驱动、设备和驱动怎么通过设备树自动匹配、如果 U-Boot 不支持某个硬件怎么给它写一个新的 DM 驱动。四个问题对应后面第三、四、六、八节。开讲前建议先在 U-Boot 控制台敲一遍dm tree,对照着那张设备表看本章会更直观,因为整章其实就是在讲这张表背后的机制。一、概述先给 DM 框架定个位。U-Boot 的 DM(Driver Model)框架是 2014 年引入的重大架构升级,灵感来自 Linux 的设备模型。它将"设备"与"驱动"分离,通过设备树自动匹配,彻底告别了传统 U-Boot 硬编码板级文件的方式。说点背景,帮大家建立感性认识。在 DM 引入之前,U-Boot 的板级代码是一片混乱–每块板子一个board/xxx/board.c,里面把 GPIO、I2C 的操作直接写死,硬件一换就得改一大片代码,复用性极差。DM 出来之后,驱动和设备通过设备树解耦,写一个驱动能套到所有同类的硬件上,这和 Linux 内核的 device driver 模型是一脉相承的。所以学完这章,再去看内核的platform_driver会觉得很亲切,套路是相通的,这是本章的一个隐藏价值–它也