4、网卡驱动加载：驱动模块初始化顺序与rootfs设备发现的耦合关系
网卡驱动什么时候加载，看起来是个小问题。但在我做嵌入式系统的这些年里，因为这个顺序问题导致的rootfs挂载失败，至少占了网络根文件系统问题的三成以上。说白了，驱动加载的时机，直接决定了你的rootfs能不能被找到。
4.1 驱动初始化顺序的底层逻辑
Linux内核在启动时，驱动的初始化顺序并不是随机的。它遵循一套固定的优先级规则。我习惯把这套规则理解为“三段式”加载：
- 编译时链接顺序：内核Makefile中obj-y列表的顺序，决定了built-in驱动的初始化顺序。
- 模块依赖顺序：如果网卡驱动依赖其他子系统（如PHY层、MDIO总线），这些依赖必须先加载。
- 设备树解析顺序：设备树中节点的先后顺序，会影响platform_device的注册顺序。
你想想看，如果网卡驱动在rootfs需要的网络设备初始化之前就完成了probe，但对应的PHY芯片还没准备好，那这个网卡实际上是不可用的。我曾经在一个项目中遇到过，驱动加载顺序完全正确，但PHY的复位GPIO需要延时100ms才能稳定——就差了这100ms，rootfs死活挂不上。
4.2 耦合关系的三种典型场景
驱动加载和rootfs设备发现之间的耦合，我归纳为三种模式。每种我都踩过坑。
| 耦合模式 | 触发条件 | 典型表现 | 我的处理方式 |
|---|---|---|---|
| 时序耦合 | 网卡驱动probe晚于NFS挂载尝试 | 内核报"Network is unreachable" | 调整驱动加载优先级或使用late_initcall |
| 资源耦合 | 网卡依赖的时钟/电源域未就绪 | probe成功但无法收发数据 | 检查设备树中power-domains和clocks属性 |
| 固件耦合 | 网卡需要从rootfs加载固件 | 死锁：rootfs需要网卡，网卡需要rootfs | 将固件编译进内核或使用initramfs |
嗯，这里要注意第三种情况。固件耦合是最隐蔽的。我记得有一次调试一块RTL8169网卡，驱动加载时去请求固件文件，但此时rootfs还没挂载，固件请求直接返回-ENOENT。驱动认为固件缺失，直接放弃初始化。这就成了典型的“先有鸡还是先有蛋”问题。
4.3 驱动加载时序的调试方法
怎么确认你的驱动加载顺序有问题？我一般用三板斧：
- 加initcall_debug内核参数：启动时能看到每个驱动的initcall执行时间戳。
- 看/sys/kernel/debug/devices_deferred：如果驱动被deferred probe，这里会列出原因。
- 手动插拔网卡：如果热插拔后能正常工作，基本就是时序问题。
举个例子，我曾经调试过一个i.MX6平台的项目，网卡驱动在initcall级别是fs_initcall，而NFS挂载发生在rootfs_initcall之后。理论上顺序是对的，但实际启动时网卡probe花了800ms（因为PHY自协商超时），导致NFS挂载时网卡还没准备好。
// 查看驱动initcall级别的典型方法
// 内核启动参数中添加：
initcall_debug loglevel=8
// 启动后dmesg中会看到类似输出：
[ 0.456] initcall fec_driver_init+0x0/0x20 returned 0 after 876 usecs
[ 1.234] initcall nfs_root_init+0x0/0x40 returned 0 after 12 usecs
关键判断标准：如果网卡驱动的initcall返回时间晚于NFS rootfs的挂载时间点，就说明存在时序耦合问题。一般要求网卡驱动在rootfs挂载前至少100ms完成probe。
4.4 解决耦合问题的工程实践
解决这个问题，我总结了几种策略，按推荐程度排序：
- 策略一：使用initramfs（最推荐）
把网卡驱动和必要固件打包进initramfs，内核先挂载initramfs，加载驱动，再挂载真正的rootfs。这样彻底解耦。 - 策略二：调整驱动initcall级别
把网卡驱动从module_init改为arch_initcall或subsys_initcall，让它更早加载。但要注意不能破坏子系统依赖。 - 策略三：设备树中增加延时
在网卡节点中添加reset-delay-us属性，给PHY足够时间稳定。治标不治本，但应急好用。 - 策略四：内核配置中固定模块顺序
把网卡驱动编译进内核（built-in），而不是作为模块。这样能保证它在rootfs挂载前就绪。
我的个人习惯：在产品开发阶段，我倾向于用initramfs方案。虽然会增加内核体积，但调试起来省心。量产时如果对启动速度有要求，再考虑把驱动编译进内核并优化probe时间。
4.5 核心流程图：驱动加载与rootfs发现的时序关系
下面这张图是我自己总结的，每次做新平台移植时都会拿出来对照。它清晰地展示了驱动加载和rootfs发现之间的关键时间窗口。
避坑指南：我曾经在一个项目里，网卡驱动probe需要从rootfs加载PHY固件。结果内核启动时，驱动先跑起来，发现固件文件不存在，直接返回-ENODEV。然后rootfs挂载成功，但驱动已经放弃了初始化。最后我不得不在initramfs里预置了固件文件，才解决这个死锁。如果你也遇到类似问题，先检查驱动代码里有没有request_firmware()调用。
4.6 实战：如何确认你的系统是否存在耦合问题
最后，我分享一个快速诊断的方法。在目标系统上执行以下步骤：
- 在启动参数中加入
rootdelay=10，给网卡驱动额外10秒时间。如果能启动，说明是时序耦合。 - 如果加了延时还是不行，检查
dmesg | grep -i "firmware"，看是否有固件加载失败。 - 检查
/sys/bus/platform/drivers/你的网卡驱动/目录，看是否有bind文件。手动echo设备名进去，如果能绑定成功，说明是初始化顺序问题。
嗯，这套方法我用了好几年，基本能覆盖90%的网卡驱动加载问题。剩下的10%，往往是硬件设计问题——比如网卡的复位引脚没接对，或者电源纹波太大导致PHY不稳定。那些就属于硬件工程师的范畴了，咱们软件能做的，就是先把时序和依赖关系理清楚。