告别SD卡识别玄学：深入Linux MMC子系统，从驱动源码层面搞定‘error -110’初始化失败
深入Linux MMC子系统：从源码层面解决SD卡初始化超时错误
当你在嵌入式设备上看到"error -110 whilst initialising SD card"这个报错时，是否曾感到困惑？这个看似简单的错误背后，隐藏着Linux内核MMC子系统与SD卡硬件之间复杂的交互过程。本文将带你深入Linux内核源码，从技术底层理解这个问题的成因和解决方案。
1. 理解error -110的本质
在Linux内核中，错误码-110对应的是ETIMEDOUT，表示操作超时。当SD卡初始化过程中某个命令在规定时间内没有得到响应时，驱动就会返回这个错误。这种现象通常发生在以下几种场景：
- 硬件设计存在缺陷，导致信号完整性不足
- SD卡与控制器之间的电压模式不兼容
- 时序参数配置不当，无法满足高速通信要求
要真正解决这个问题，我们需要先了解SD卡的标准初始化流程。根据SD协会规范，完整的初始化序列包括：
- CMD0 - 复位卡到空闲状态
- CMD8 - 检查电压兼容性
- ACMD41 - 初始化卡并协商工作条件
- CMD2 - 获取卡CID
- CMD3 - 获取相对卡地址(RCA)
- CMD9 - 获取卡特定数据(CSD)
其中，ACMD41是最容易出问题的环节，因为它涉及到电压和总线模式的协商。当控制器支持1.8V低电压模式(UHS)，但SD卡或硬件设计无法稳定工作时，就可能出现超时错误。
2. 深入MMC子系统源码分析
Linux内核的MMC子系统代码位于drivers/mmc目录下，其中核心的SDHCI控制器驱动在host/sdhci.c中。让我们重点分析__sdhci_read_caps函数，这是初始化过程中读取控制器能力的关键函数。
void __sdhci_read_caps(struct sdhci_host *host, const u16 *ver, const u32 *caps, const u32 *caps1) { host->version = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION); host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES); host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1); /* 应用quirks修正控制器能力 */ if (host->quirks & SDHCI_QUIRK_MISSING_CAPS) host->caps = host->ops->get_cd(host) ? host->caps : 0; }在这个函数中，控制器报告的能力会被读取并存储在host->caps和host->caps1中。这些能力位决定了控制器支持的功能，如高速模式、DDR模式、1.8V电压等。
当遇到"error -110"问题时，一个常见的解决方案是添加SDHCI_QUIRK2_NO_1_8_V这个quirks标志。让我们看看这个quirks的具体作用：
if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) { host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50); mmc->caps2 &= ~(MMC_CAP2_HSX00_1_8V | MMC_CAP2_HS400_ES); mmc->caps &= ~(MMC_CAP_1_8V_DDR | MMC_CAP_UHS); }这段代码做了以下几件事：
- 清除控制器能力寄存器中与1.8V相关的模式位(SDR104/SDR50/DDR50)
- 移除MMC核心层的高速模式能力标志(HS200/HS400)
- 禁用UHS(超高速)和1.8V DDR模式支持
这样做的实质是让驱动"降级"到只使用3.3V电压和更保守的通信模式(如High-Speed)，从而规避因硬件限制导致的高速模式通信失败。
3. SDHCI quirks的深入应用
SDHCI_QUIRK2_NO_1_8_V只是众多quirks中的一个。Linux内核为应对各种硬件差异，定义了大量quirks标志。以下是一些常见的SDHCI quirks及其应用场景：
| Quirks标志 | 作用 | 典型应用场景 |
|---|---|---|
| SDHCI_QUIRK_BROKEN_DMA | 禁用DMA传输 | 控制器DMA功能有缺陷 |
| SDHCI_QUIRK_NO_HISPD_BIT | 忽略高速模式位 | 不支持高速模式的老旧控制器 |
| SDHCI_QUIRK_BROKEN_ADMA | 禁用ADMA(高级DMA) | ADMA实现有问题的控制器 |
| SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | 使用SDCLK计算超时 | 某些特殊硬件需要 |
| SDHCI_QUIRK_RESET_AFTER_REQUEST | 每个请求后复位控制器 | 解决特定硬件稳定性问题 |
在实际开发中，正确识别硬件问题并选择合适的quirks是解决问题的关键。以下是一个典型的调试流程：
- 复现问题：确保能稳定复现error -110错误
- 分析日志：查看内核日志，确定错误发生的具体阶段
- 硬件检查：确认PCB设计、信号完整性、电压稳定性
- 软件调试：
- 尝试降低总线速度
- 添加适当的quirks标志
- 必要时修改时序参数
- 验证方案：测试各种操作场景下的稳定性
4. 设备树配置与驱动协同工作
除了修改驱动代码，设备树(Device Tree)也是解决SD卡兼容性问题的重要手段。以TI SoC为例，设备树中可以配置各种时序参数：
main_sdhci1: sdhci@4fb0000 { ti,otap-del-sel-legacy = <0x2>; /* 注释掉高速模式时序参数 */ /* ti,otap-del-sel-sd-hs = <0xf>; */ /* ti,otap-del-sel-sdr12 = <0xf>; */ /* ti,otap-del-sel-sdr25 = <0xf>; */ /* ti,otap-del-sel-sdr50 = <0xc>; */ /* ti,otap-del-sel-sdr104 = <0x5>; */ /* ti,otap-del-sel-ddr50 = <0xc>; */ sdhci-caps-mask = <0x2 0x0>; dma-coherent; };这些配置项的作用是：
ti,otap-del-sel-*：设置不同模式下的输出延迟参数sdhci-caps-mask：屏蔽控制器报告的某些能力位
通过合理配置这些参数，可以优化信号时序，提高通信稳定性。特别是在高速模式下，精确的时序配置对信号完整性至关重要。
5. 实战：从零开始调试SD卡问题
假设我们遇到一个全新的SD卡兼容性问题，以下是一个系统化的调试方法：
步骤1：收集基本信息
- SD卡型号和规格
- 控制器型号和Linux驱动版本
- 完整的错误日志
步骤2：简化问题
- 尝试不同的SD卡(最好是已知良好的卡)
- 降低总线频率(如设置最大频率为25MHz)
- 禁用所有高级功能(UHS, HS200等)
步骤3：深入分析
# 启用MMC子系统的调试日志 echo 8 > /sys/module/mmc_core/parameters/debug_level步骤4：修改驱动根据分析结果，可能需要：
- 添加新的quirks标志
- 调整超时时间
- 修改能力报告逻辑
步骤5：验证与优化
- 测试各种极端条件(高温、低温、振动)
- 评估性能是否满足需求
- 考虑硬件修改的可能性(如终端电阻调整)
在实际项目中，我曾遇到一个案例：某定制板卡的SD卡在高温环境下频繁出现error -110。通过分析发现是1.8V电压稳定性不足，最终解决方案是同时应用SDHCI_QUIRK2_NO_1_8_V和降低最大总线频率，既保证了稳定性又满足了性能需求。