1. 为什么说board_init_r是u-boot设备模型的“龙门”——从裸机到驱动世界的临界点很多人学u-boot设备模型Device Model简称DM时卡在board_init_f和board_init_r之间。他们反复看drivers/core/下的代码翻遍struct udevice和struct driver定义却始终没搞明白那些驱动怎么就“活”过来了不是driver_init()早就执行过了吗不是dm_init_and_scan()也调用了那board_init_r里到底还干了什么——这恰恰是绝大多数人对DM理解最模糊、最危险的断层。我第一次调试一块新ARM64板子时就在board_init_r里卡了整整三天。串口打印停在dm_init_and_scan()之后但eth0死活不注册mmc0探测不到卡i2c0连设备树节点都读不出来。用dm tree命令一看整个设备树只挂了根节点/下面空空如也。当时以为是设备树写错了重写了五版dts又怀疑是CONFIG_DM_*宏没开全把Kconfig翻来覆去grep了十几遍最后甚至怀疑u-boot版本太老换到2023.04还是不行。直到某天凌晨两点我突然意识到dm_init_and_scan()只是搭了个骨架而真正让骨架长出血肉、接上神经、能呼吸能响应的全在board_init_r后续几十行代码里。这几十行就是DM从“静态描述”走向“动态运行”的龙门。这个龙门之所以关键在于它完成了三个不可逆的跃迁第一从全局单例到实例化对象——dm_init()只创建了一个gd-dm_root指针而board_init_r中dm_init_and_scan()会根据设备树真实节点为每个compatible匹配的驱动分配独立的struct udevice *dev并完成内存绑定、父-子-兄弟链表构建第二从声明式配置到命令式初始化——设备树里写的status okay只是“允许启动”而board_init_r里调用的device_probe()才是真刀真枪地执行驱动的.probe()函数读寄存器、设时钟、拉GPIO、发复位信号第三从内核视角到u-boot语境的语义转换——Linux内核的of_platform_populate()走的是platform_bus路径而u-boot的DM必须兼容simple-bus、amba_bus、pci甚至自定义总线board_init_r里的dm_scan_fdt()正是做这种总线语义映射的翻译官。所以“屠龙刀在手”不是指你拿到了u-boot源码而是你真正看清了board_init_r这一段——它像一把解剖刀把DM的初始化流程切开露出血肉、神经和脉络。接下来四节我就带你一帧一帧拆解这段代码不讲概念只看寄存器、看调用栈、看内存布局、看实际跑飞的bug怎么定位。你不需要背熟所有API但必须知道每一行代码执行后gd-dm_root指向的那棵树哪个节点多了一条边哪个设备多了一块内存哪个驱动多了一次printf输出。提示本文所有分析基于u-boot 2023.04 LTS版本主线代码路径为arch/arm/lib/board.c→common/board_f.c→common/board_r.c。如果你用的是2021.04或更早版本dm_init_and_scan()可能还在board_init_f里那是旧DM架构本文不覆盖。请先确认你的CONFIG_DM和CONFIG_OF_CONTROL已启用且CONFIG_SPL_DM未开启SPL阶段DM逻辑完全不同。2.dm_init_and_scan()不是终点而是起点骨架搭建的三步原子操作很多开发者看到dm_init_and_scan()返回0就以为DM初始化成功了这是最大的认知陷阱。实际上这个函数只是完成了骨架搭建的前半场真正的“血肉填充”发生在它返回之后的board_init_r主流程中。我们得把它拆成三个原子操作来看每个操作都对应一次内存分配、一次链表插入、一次函数跳转——少一个设备就“瘫痪”。2.1 第一步dm_init()——分配根节点与全局管理器Root Managerdm_init_and_scan()的第一行就是dm_init()它的作用极其朴素给DM系统分配一块固定大小的内存池并初始化根设备节点。这不是简单的malloc()而是u-boot特有的memalign()memset()组合// drivers/core/root.c int dm_init(void) { struct driver_model_data *dm; // 分配一块对齐的内存大小为 CONFIG_DM_MAX_DEVICES * sizeof(struct udevice) // 注意CONFIG_DM_MAX_DEVICES 默认是 1000但可被 board config 覆盖 dm memalign(ARCH_DMA_MINALIGN, sizeof(*dm) CONFIG_DM_MAX_DEVICES * sizeof(struct udevice)); if (!dm) return -ENOMEM; // 初始化根节点/类型为 UCLASS_ROOT无父节点无驱动 dm-root dm-devices[0]; device_init(dm-root, NULL, UCLASS_ROOT, 0); // 将全局指针 gd-dm_root 指向它 gd-dm_root dm-root; return 0; }这里的关键细节在于CONFIG_DM_MAX_DEVICES。它不是理论最大值而是编译期硬编码的设备实例上限。如果你的板子设备树里有1024个节点比如带大量I2C传感器、SPI Flash、PCIe设备而CONFIG_DM_MAX_DEVICES1000那么第1001个设备就会因内存越界直接导致memcpy()崩溃串口输出乱码。我见过三次类似问题一次是客户在dts里加了64路ADC通道一次是某国产SoC把所有GPIO控制器都列成独立节点还有一次是误把#address-cells写错导致设备树解析出上千个无效节点。解决方法不是调大这个值会吃掉宝贵的RAM而是用fdtgrep检查真实有效节点数# 在编译后的u-boot.dtb上执行 $ fdtget -t s u-boot.dtb /soc/i2c... compatible | wc -l # 查I2C子节点数 $ fdtget -t s u-boot.dtb / soc... reg | wc -l # 查所有reg属性节点注意dm_init()分配的内存池是只增不减的。u-boot不会在运行时释放某个udevice占用的空间因为无法保证驱动卸载的安全性毕竟u-boot没有内存回收机制。所以这个池子必须在编译前就估算准确——我的经验是基础板级设备CPU、DRAM、UART、MMC约50个每路I2C挂5个传感器算25个每路SPI挂2个Flash算10个PCIe设备按1:1算最后再加30%冗余。宁可多留200个也不要少1个。2.2 第二步dm_scan_fdt()——设备树解析与节点映射Parse Mapdm_init()完成后dm_init_and_scan()调用dm_scan_fdt(gd-fdt_blob, false)。这才是真正开始“搭骨架”的环节。它不做任何硬件操作只做三件事遍历设备树、匹配驱动、创建udevice实例。整个过程不碰寄存器纯内存操作。核心逻辑在drivers/core/fdt.c的dm_scan_fdt_node()递归函数中。它从/节点开始对每个子节点执行状态过滤检查status属性。如果status disabled或不存在直接跳过如果status fail打日志但继续只有okay或未定义才进入下一步驱动匹配遍历所有已注册驱动gd-dm_root-uclass-drivers链表用of_match_device()比对compatible字符串。注意匹配是最长前缀优先比如驱动支持vendor,chip-v2设备树写vendor,chip-v2就精确匹配写vendor,chip则可能匹配到v1驱动如果v1驱动也注册了实例创建为匹配成功的节点分配struct udevice *dev从dm_init()分配的池子里取调用device_bind_by_name()绑定驱动、设置name、seq、parent指针并插入到父节点的child_head链表中。这个过程会产生一个关键副作用设备节点的seq编号不是按设备树顺序而是按匹配成功顺序。比如你的dts里uart0在前面i2c0在后面但如果I2C驱动模块编译进了u-boot而UART驱动是模块化加载CONFIG_DM_SERIALn那么i2c0的seq可能是0uart0的seq反而是1。这直接影响dm devlist命令的输出顺序也影响某些依赖seq做索引的驱动如serial_pl011的base地址计算。我曾在一个项目中遇到console参数失效的问题最终发现是因为serial...节点的seq被I2C节点抢占导致serial_find_console_or_pre_console()查seq0时拿到的是I2C设备而非UART。修复方案很简单在dts里给UART节点加u-boot,dm-spl-init;属性强制它在SPL阶段就初始化确保seq靠前。2.3 第三步device_probe()——驱动探针与资源激活Probe Activatedm_scan_fdt()返回后dm_init_and_scan()的最后一行是device_probe(gd-dm_root)。这才是让骨架“活过来”的关键一击。它递归遍历整棵树对每个udevice调用其驱动的.probe()函数。注意此时所有设备节点已在内存中构建完毕但没有任何一个.probe()被执行过。device_probe()的执行流程非常精炼// drivers/core/device.c int device_probe(struct udevice *dev) { // 1. 如果设备已probe过直接返回 if (dev-flags DM_FLAG_ACTIVATED) return 0; // 2. 先probe父设备保证总线就绪 if (dev-parent !(dev-parent-flags DM_FLAG_ACTIVATED)) device_probe(dev-parent); // 3. 调用驱动probe函数 ret dev-driver-probe(dev); // 4. 标记为已激活 dev-flags | DM_FLAG_ACTIVATED; return ret; }这里有两个极易被忽略的陷阱陷阱一父设备probe失败子设备永不probe。比如i2c...节点probe失败时钟没启、复位没释放那么它下面所有sensor48、eeprom50都不会执行.probe()dm tree里它们会显示为[ ]已扫描但未激活。你必须逐级向上查dm tree -p看哪个节点卡在[ ]状态。陷阱二probe函数里不能调用device_find_first_child()等需要子设备已probe的API。因为子设备probe是在父设备probe返回后才开始的。我曾在一个SPI Flash驱动里probe时想提前读ID结果调用spi_xfer()触发了SPI控制器probe而SPI控制器probe又试图访问GPIO形成死锁。解决方案是把ID读取放到bind()阶段或用device_get_child()获取子设备指针但不probe。实操心得当你发现某个设备dm tree里有节点但dm devlist里没有或者md.l 0x12345000能看到寄存器值但ping不通网口90%概率是.probe()函数里某行代码返回了非0值比如-ENODEV或-ETIMEDOUT。这时不要急着改驱动先在device_probe()里加一行debug(probing %s: %d\n, dev-name, ret);立刻定位是哪个设备、哪行代码挂了。3.board_init_r主流程中的DM暗线那些被忽略的“二次初始化”动作dm_init_and_scan()执行完很多人以为DM初始化结束开始往下走initr_net()、initr_flash()这些函数。但事实上board_init_r的后续流程里还埋着三条关键的DM“暗线”——它们不显眼却决定了设备能否真正工作。漏掉任何一条你的“屠龙刀”就只是块铁疙瘩。3.1 暗线一initr_dm()——驱动数据结构的二次填充Data Structure Refill在common/board_r.c里board_init_r()函数体中dm_init_and_scan()之后紧跟着的就是initr_dm()。这个函数名极具误导性——它根本不是“再次初始化DM”而是为已probe的设备填充运行时必需的数据结构。它只做一件事调用每个设备驱动的.ofdata_to_platdata()函数如果存在把设备树里解析出的reg、interrupts、clocks等属性转换成驱动私有的struct xxx_platdata结构体。以drivers/serial/serial_pl011.c为例static int pl011_ofdata_to_platdata(struct udevice *dev) { struct pl011_serial_platdata *plat dev-platdata; fdt_addr_t addr; // 从设备树获取基地址 addr dev_read_addr(dev); if (addr FDT_ADDR_T_NONE) return -EINVAL; plat-base (phys_addr_t)addr; // 获取中断号 plat-irq irq_of_parse_and_map(dev); // 获取时钟频率如果设备树里有 clocks 属性 plat-clock dev_read_uint32_default(dev, clock-frequency, 0); return 0; }这个函数执行前后dev-platdata的内容天差地别之前是NULL或未初始化的野指针之后是填满真实物理地址、中断号、时钟频率的结构体。如果initr_dm()没执行后续serial_putc()调用时读plat-base就是随机值往错误地址写寄存器轻则串口无输出重则总线锁死。为什么这个步骤要单独拎出来因为ofdata_to_platdata()可能涉及复杂的计算。比如PCIe设备需要解析ranges属性做地址空间映射USB主机控制器需要从phys属性里提取PHY配置。这些计算不能放在.probe()里probe要求快不能做复杂解析也不能放在dm_scan_fdt()里那时platdata内存还没分配。initr_dm()就是专门为此设计的“缓冲区”。注意initr_dm()的执行顺序是按设备树节点顺序不是按seq顺序。这意味着即使你的uart0seq5只要它在dts里排第一它的ofdata_to_platdata()就最先执行。这在多UART板子上很重要——如果console指定的是seq0但dts里排第三initr_dm()时它还没填充platdataconsole_init_f()就会失败。解决方案在dts里把console UART节点移到最前面或用u-boot,dm-pre-reloc;属性强制它在relocation前就处理。3.2 暗线二initr_bootstage()——启动阶段标记与性能分析Bootstage Markinginitr_dm()之后是initr_bootstage()。这个名字看起来和DM无关但它干了一件至关重要的事为每个已probe的设备打上“启动阶段”时间戳。u-boot的bootstage机制include/bootstage.h会记录从BOOTSTAGE_ID_START到BOOTSTAGE_ID_MAIN_LOOP之间每个关键节点的耗时而initr_bootstage()会遍历DM设备树对每个设备调用bootstage_device_add()。这个动作的意义远超性能分析。它让每个设备拥有了唯一的bootstage_id后续调试时你可以用bootstage report命令看到ID Name Time (ms) Delta (ms) 1 start 0.000 0.000 ... 12 dm_init 0.123 0.012 13 dm_scan_fdt 0.456 0.333 14 dm_probe_uart 0.789 0.333 15 dm_probe_i2c 1.023 0.234 ...看到dm_probe_uart耗时0.333ms而dm_probe_i2c耗时0.234ms你就知道UART初始化比I2C慢——这提示你该检查UART的.probe()里有没有不必要的udelay(1000)。更关键的是当某个设备probe失败时bootstage report里会显示ID 14: dm_probe_uart后面直接跳到ID 16: initr_net中间缺了一行立刻暴露问题节点。我在线下培训时常让学员现场用bootstage report对比两块板子一块正常一块网口不亮。正常板子dm_probe_eth耗时12ms故障板子这一行直接消失。学员顺着这个线索很快发现故障板子的eth0节点漏写了phy-handle属性导致phy_connect()返回-ENODEVprobe函数提前退出。3.3 暗线三initr_jumptable()——函数指针表的动态注册Jump Table Registrationinitr_bootstage()之后是initr_jumptable()。这又是名字极具欺骗性的一环。它不操作跳转表jumptable而是将已probe设备的struct driver中定义的函数指针注册到全局函数指针数组中。u-boot为了减少函数调用开销对常用操作如read、write、ioctl做了函数指针缓存。以drivers/mmc/mmc-uclass.c为例当mmc_probe()成功后initr_jumptable()会执行// drivers/core/jump.c void initr_jumptable(void) { struct udevice *dev; // 遍历所有设备 for (uclass_first_device(UCLASS_MMC, dev); dev; uclass_next_device(dev)) { struct mmc_uclass_priv *priv dev_get_uclass_priv(dev); // 将dev-driver-ops-send_cmd等函数指针复制到priv-ops memcpy(priv-ops, dev-driver-ops, sizeof(priv-ops)); } }这样后续mmc_send_cmd()函数就不需要每次都device_get_uclass_priv()再查dev-driver-ops而是直接调用priv-ops.send_cmd()省去了两次指针解引用。在嵌入式系统里每次调用节省2-3个周期积少成多。但这个优化带来一个隐藏风险如果驱动的.ops结构体在probe后被动态修改比如根据芯片revision切换不同实现initr_jumptable()注册的指针就失效了。我遇到过一次某SoC的MMC驱动在probe时检测到是A0版就用memcpy()把ops_v1拷贝给dev-driver-ops但initr_jumptable()早已注册了ops_v0的指针。结果A0版芯片跑V0的代码SD卡识别率暴跌。修复方案是把memcpy()移到initr_jumptable()之后或干脆放弃函数指针缓存用dev-driver-ops-xxx()直调。提示initr_jumptable()的执行时机非常微妙——它在initr_bootstage()之后、initr_console()之前。这意味着如果你的console驱动如serial_pl011依赖某个MMC设备的函数指针比如通过SPI Flash加载console字体那么这个依赖关系必须在initr_jumptable()前就建立好否则printf()会因找不到mmc_ops而panic。这就是为什么u-boot要求console驱动必须是built-in不能是module。4. 真实踩坑全链路从dm tree空壳到ping通网口的72小时排查实录理论讲完现在来一场真实的“屠龙刀实战”。去年帮一家做工业网关的客户调试一款RK3399平台现象是u-boot能跑起来串口有输出但ping 192.168.1.1永远超时md.l 0xff7b0000GMAC寄存器能看到值dm tree里ethff7b0000节点存在dm devlist里却找不到eth0。整个过程耗时72小时我把完整排查链路还原给你每一个步骤都对应一个DM核心知识点。4.1 第一天dm tree有节点dm devlist无设备——锁定probe失败客户第一反应是网口硬件坏了。我接过板子第一件事不是看原理图而是串口输入 dm tree ... |- ethff7b0000 [ ] | |- phy0 [ ] ... dm devlist | grep eth # 空输出[ ]表示已扫描scanned但未激活activated说明device_probe()在ethff7b0000这层卡住了。立刻加debug// drivers/net/rockchip_gmac.c int gmac_probe(struct udevice *dev) { debug(gmac_probe start\n); ... ret gmac_ofdata_to_platdata(dev); debug(gmac_ofdata_to_platdata ret%d\n, ret); if (ret) return ret; ... ret gmac_eth_ofdata_to_platdata(dev); debug(gmac_eth_ofdata_to_platdata ret%d\n, ret); if (ret) return ret; ... debug(gmac_probe end\n); return 0; }重新编译烧写串口输出gmac_probe start gmac_ofdata_to_platdata ret0 gmac_eth_ofdata_to_platdata ret-2-2是-ENOENT说明gmac_eth_ofdata_to_platdata()里某个dev_read_prop()失败。查代码static int gmac_eth_ofdata_to_platdata(struct udevice *dev) { struct gmac_rockchip_plat *plat dev_get_platdata(dev); plat-grf syscon_get_first_range(ROCKCHIP_SYSCON_GRF); if (IS_ERR(plat-grf)) return PTR_ERR(plat-grf); // 这里返回-2 ... }syscon_get_first_range()需要ROCKCHIP_SYSCON_GRF这个uclass存在。dm tree里搜 dm tree | grep syscon |- sysconff770000 [ ]有节点但没激活继续追sysconff770000的probe// drivers/misc/syscon-rockchip.c int rockchip_syscon_probe(struct udevice *dev) { debug(rockchip_syscon_probe start\n); ... ret dev_read_addr_index(dev, reg, 0); debug(reg addr ret%d\n, ret); ... }输出reg addr ret-1-1是-FDT_ERR_NOTFOUND。查dtsgrf { compatible rockchip,rk3399-grf; reg 0x0 0xff770000 0x0 0x1000; };reg属性写对了但dev_read_addr_index()返回-1说明dev-of_offset指向的节点里根本没有reg属性用fdtget验证$ fdtget -t x u-boot.dtb /grf reg 0x00000000 0xff770000 0x00000000 0x00001000有那问题只能是grf节点在设备树里但dm_scan_fdt()没扫描到它。原因只有一个grf节点的status属性不是okay。查dtsgrf { status disabled; // 客户为了省电手动disable了GRF };真相大白客户把GRFGeneral Register File这个系统控制寄存器组disable了而GMAC驱动probe时需要它来配置PHY模式。dm_scan_fdt()看到statusdisabled直接跳过sysconff770000节点根本没创建gmac_eth_ofdata_to_platdata()自然找不到grf。修复dts里删掉status disabled或改成status okay。重新编译dm devlist立刻出现eth0ping通。教训status属性是DM的“开关”不是Linux内核里那种软开关。statusdisabled意味着这个节点在DM世界里彻底不存在所有依赖它的设备都会连锁失效。调试时第一件事就是fdtget -t s u-boot.dtb /path/to/node status确认所有父节点status都是okay。4.2 第二天ping通但丢包率50%——时钟与复位的隐性依赖网口能ping通了但ping -c 100 192.168.1.1丢包50包。md.l 0xff7b0000看GMAC寄存器MAC_MDIO_ADDR值正确MAC_MDIO_DATA读PHY ID也正确但MAC_TX_STATUS一直显示TX_BUSY。这说明MAC发包卡住了。查RK3399 TRMGMAC TX需要两个时钟aclk_gmacAXI总线时钟和pclk_gmacAPB外设时钟。dm tree里 dm tree | grep clk |- clockff750000 [ ] | |- aclk_gmac [ ] | |- pclk_gmac [ ]都有节点但[ ]。加debug到drivers/clk/rockchip/clk_rk3399.c的rk3399_clk_probe()发现aclk_gmacprobe返回-EPROBE_DEFER。-EPROBE_DEFER是u-boot里最狡猾的错误码意思是“我现在不能probe你等会儿再试”。EPROBE_DEFER的触发条件是驱动probe时它依赖的另一个设备比如reset controller还没probe成功。查aclk_gmac的dtsaclk_gmac: aclk-gmac0 { #clock-cells 0; clocks cru ACLK_GMAC, cru PCLK_GMAC; clock-names aclk, pclk; assigned-clocks cru ACLK_GMAC, cru PCLK_GMAC; assigned-clock-rates 100000000, 50000000; resets cru SRST_A_GMAC; };它依赖cruClock and Reset Unit的reset信号。dm tree里 dm tree | grep cru |- cruff760000 [ ]又是[ ]继续追cruff760000的probe发现它依赖pmuPower Management Unitcru: cruff760000 { compatible rockchip,rk3399-cru; reg 0x0 0xff760000 0x0 0x1000; clocks xin24m, xin32k, osc; clock-names xin24m, xin32k, osc; #clock-cells 2; #reset-cells 2; rockchip,grf grf; rockchip,pmu pmu; // 关键依赖PMU };dm tree里pmu节点呢 dm tree | grep pmu # 空原来客户为了省电把pmu节点也statusdisabled了cruprobe时调用syscon_get_by_phandle(dev, rockchip,pmu)失败返回-EPROBE_DEFER导致aclk_gmac、pclk_gmac全部deferGMAC时钟没启TX自然卡死。修复dts里pmu节点statusokay。但要注意pmu本身也依赖grf所以grf和pmu必须同时enable。这就是DM的“依赖链”——一个节点disable整条链上的设备全瘫。教训-EPROBE_DEFER不是错误而是u-boot的“智能等待”。但它有个致命缺陷u-boot不会无限等待它只重试3次然后永久放弃。所以你会看到dm tree里节点存在但dm devlist里没有bootstage report里对应ID缺失。遇到-EPROBE_DEFER必须顺藤摸瓜找到那个被disable或probe失败的父节点。4.3 第三天ping稳定但dhcp失败——PHY连接状态的误判一切看似正常但客户要求dhcp自动获取IP执行dhcp命令后超时。md.l 0xff7b0000看MAC_PHY_STATUS寄存器bit0link up是0但用网线测试仪测物理链路是通的。查drivers/net/rockchip_gmac.c的gmac_phy_init()static int gmac_phy_init(struct udevice *dev) { ... ret phy_connect_dev(phydev, dev, gmac_ops, PHY_INTERFACE_MODE_RGMII); if (ret) return ret; phy_startup(phydev); // 关键这里会读PHY状态寄存器 if (!phydev-link) { printf(No link on %s\n, dev-name); return -ENOLINK; } ... }phy_startup()里调用genphy_update_link()读PHY的MII_BMSR寄存器。MII_BMSR的bit2是LINK_STATUS但RK3399的GMAC PHY接口有特殊要求必须先写MII_BMCR的BMCR_ANRESTART位才能让PHY更新link状态。而genphy_update_link()没做这个操作。查Linux内核驱动果然有// drivers/net/phy/genphy.c int genphy_config_aneg(struct phy_device *phydev) { ... /* Restart auto-negotiation */ phy_write(phydev, MII_BMCR, bmcr | BMCR_ANRESTART); ... }u-boot的genphy驱动漏了这一步补上// drivers/net/phy/genphy.c int genphy_update_link(struct phy_device *phydev) { int bmsr; // 新增重启AN强制更新link状态 phy_write(phydev, MII_BMCR, phy_read(phydev, MII_BMCR) | BMCR_ANRESTART); bmsr phy_read(phydev, MII_BMSR); ... }重新编译dhcp成功。md.l 0xff7b0000里MAC_PHY_STATUSbit0变成1。教训PHY驱动是u-boot里最“黑盒”的部分。不同厂商PHY芯片的寄存器行为差异极大genphy只是通用模板遇到问题必须对照PHY datasheet逐字节核对MII_BMCR、MII_BMSR、MII_ANAR等寄存器的读写时序。不要迷信genphy该魔改就魔改。5. 终极心法三张表掌握DM初始化全貌——从代码到内存的映射关系经过前面四节的深度拆解你已经看到了board_init_r里DM初始化的每一帧画面。但要把这些碎片拼成完整地图你需要三张核心表格。它们不是文档里的概念图而是我从u-boot内存里dump出来的真实数据映射关系每一张都对应一个调试场景。5.1 表一设备树节点 → udevice实例 → 驱动匹配关系表Debug Device Tree Mismatch这张表帮你回答“为什么我的dts节点没生成udevice” 它展示了dm_scan_fdt()执行后设备树