嵌入式Linux开发踩坑记：TI AM62x平台SD卡初始化报错-110的完整修复流程
嵌入式Linux开发实战：TI AM62x平台SD卡初始化报错-110的深度解析与修复
当你在TI AM62x平台上调试嵌入式Linux系统时，突然在串口日志中看到"error -110 whilst initialising SD card"的红色报错信息，那种感觉就像在高速公路上突然爆胎。作为一名长期奋战在嵌入式一线的开发者，我深知这种硬件兼容性问题带来的挫败感。本文将带你深入剖析这个问题的根源，并提供一套经过实战验证的修复方案。
1. 问题现象与初步诊断
SD卡初始化报错-110通常出现在U-Boot和Linux内核两个阶段，但表现略有不同。在最近的一个工业控制器项目中，我们使用AM62x处理器搭配某品牌32GB SD卡时，遇到了典型的症状：
U-Boot阶段表现：
- 执行
mmc dev 1命令后无任何响应 - SD卡读写操作完全失败
- 串口终端无SD卡识别相关信息输出
Linux内核阶段表现：
mmc1: error -110 whilst initialising SD card mmc1: card never left busy state mmc1: error -110 whilst initialising SD card这种错误代码-110在Linux内核中对应ETIMEDOUT，表示操作超时。但为什么会出现超时？我们需要深入SD卡初始化的底层机制。
提示：在开始调试前，建议先用
mmc list命令确认SD卡控制器已被正确识别，排除硬件连接问题。
2. 根本原因分析：SD卡与SoC的"沟通障碍"
经过多次实验和代码追踪，我们发现问题的核心在于SD卡1.8V信号模式与AM62x SoC时序配置的不兼容。具体来说：
- SD卡规范冲突：现代SD卡支持多种电压模式（3.3V/1.8V），而某些SD卡在1.8V模式下CMD信号时序不符合AM62x的预期
- OTAP延迟配置：AM62x的Output Tap Delay（OTAP）参数对高速信号至关重要，默认配置可能不适合特定SD卡
- 驱动兼容性问题：Linux内核的SDHCI驱动默认尝试启用高速模式（SDR104/SDR50），但某些SD卡无法正确处理这些模式下的初始化命令
以下是对比正常与异常SD卡初始化流程的关键差异点：
| 阶段 | 正常流程 | 问题表现 |
|---|---|---|
| 电源初始化 | 3.3V稳定供电 | 3.3V供电正常 |
| CMD0复位 | 收到正确响应 | 响应正常 |
| CMD8电压检查 | 返回支持的电压范围 | 某些卡在1.8V模式响应异常 |
| ACMD41初始化 | 完成初始化流程 | 超时无响应(error -110) |
| 高速模式切换 | 成功切换到SDR104/SDR50 | 切换命令无响应 |
3. 完整修复方案：从设备树到内核驱动
3.1 U-Boot阶段修改：调整设备树配置
首先需要修改AM62x的设备树源文件（.dts），通常位于arch/arm/dts/目录下。找到main_sdhci1节点并进行如下调整：
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-legacy配置 - 注释掉所有高速模式下的OTAP延迟设置
sdhci-caps-mask用于屏蔽控制器不支持的SD卡特性
3.2 Linux内核驱动修改：禁用1.8V模式
在内核源码中，需要修改SDHCI驱动以禁用1.8V高速模式。编辑drivers/mmc/host/sdhci.c文件，在__sdhci_read_caps函数中添加：
void __sdhci_read_caps(struct sdhci_host *host, const struct sdhci_ops *ops) { /* 添加针对AM62x的特殊处理 */ host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; 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); } }这段修改的核心作用：
- 设置
SDHCI_QUIRK2_NO_1_8_V标志，告知驱动不支持1.8V模式 - 清除控制器能力标志中与1.8V高速模式相关的位
- 确保MMC子系统不会尝试使用不兼容的高速模式
3.3 验证修改是否生效
完成上述修改后，按照以下步骤验证：
重新编译U-Boot和设备树：
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am62x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf-重新编译Linux内核：
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- menuconfig make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf-烧录测试后，观察串口输出：
- U-Boot阶段应能正常识别SD卡
- 内核启动时不应出现-110错误
- 执行
dmesg | grep mmc应显示SD卡初始化成功
4. 解决方案的适用范围与性能影响
这个修复方案虽然有效，但也有其适用范围和性能代价，开发者需要权衡考虑：
适用场景：
- TI AM62x系列SoC平台
- 特定品牌/批次的SD卡（多见于某些工业级SD卡）
- 系统无法从SD卡启动或挂载的情况
- 出现"-110"初始化错误的场景
性能影响评估：
| 模式 | 理论速度 | 实际可用性 |
|---|---|---|
| 默认(SDR104) | 104MB/s | 不可用(报错) |
| SDR50 | 50MB/s | 不可用(报错) |
| DDR50 | 50MB/s | 不可用(报错) |
| 修复后(High Speed) | 25MB/s | 稳定可用 |
替代方案比较：
- 更换SD卡：最简单但可能影响产品一致性
- 硬件修改：调整PCB上的上拉电阻，但增加BOM成本
- 本方案：软件修改，零硬件成本，但牺牲部分性能
在实际项目中，我们最终采用了软件方案，因为：
- 工业控制器对SD卡速度要求不高（主要用作启动介质）
- 保持硬件设计不变更利于量产一致性
- 无需额外的硬件认证流程
5. 深入理解：SD卡初始化流程与AM62x特殊设计
要真正掌握这个问题，需要理解SD卡初始化的关键步骤和AM62x的特殊设计：
标准SD卡初始化序列：
- CMD0 - 复位卡到空闲状态
- CMD8 - 检查电压兼容性
- ACMD41 - 初始化卡并查询OCR寄存器
- CMD2 - 获取卡CID
- CMD3 - 设置相对卡地址(RCA)
- CMD9 - 读取CSD寄存器
- CMD7 - 选择卡
- CMD6 - 切换高速模式（可选）
AM62x的特殊考量：
- 采用可编程OTAP延迟线调节信号时序
- 默认配置针对主流消费级SD卡优化
- 工业环境可能需要更宽松的时序容限
- 1.8V模式对信号完整性要求更高
在最近的一个客户案例中，我们发现同一批次的不同SD卡也有不同表现，这提示我们：
- SD卡固件版本差异可能导致兼容性问题
- 温度变化会影响信号时序余量
- 电源质量对初始化过程至关重要
因此，除了软件修改外，我们还建议：
- 在PCB设计阶段确保SD卡电源干净稳定
- 保留信号完整性测试点
- 考虑在量产前进行多品牌SD卡兼容性测试