SDIO -110排查：Linux内核超时与嵌入式WiFi初始化

新板子第一次上电，串口 log 滚到最后停在一行字上：mmc1: error -110 whilst initialising SDIO card。另一台已经跑起来的产品，用户反馈 WiFi 偶尔掉线，抓内核日志能看到brcmf_sdio_bus_txctl: dongle is not responding: err=-110。这两个场景看起来八竿子打不着，但报出来的错码是同一个：SDIO -110。这个数字不是硬件手册里的寄存器值，也不是什么厂商私有码，它是 Linux 内核里ETIMEDOUT取负之后的样子，翻译成人话就是"我等得太久，对面一直没理我"。

做嵌入式 WiFi 的人迟早会碰到它。它可能出现在板子刚回来第一次 bring-up 的时候，也可能出现在量产几百台之后某一台的偶发故障里。麻烦的地方在于，-110 是个"症状"而不是"病因"，从供电、上电时序、走线、上拉、设备树配置到固件文件缺失，都能让它冒出来。这篇就把我这些年拆 -110 的思路完整摊开：先讲清楚这个错误码在内核协议栈里是怎么产生的，再给一套从日志到示波器的排查流程，然后按硬件、软件两条线把常见元凶逐个点名，最后用一次真实的排查复盘把整套方法串起来。

1. 从 -110 这个数字反推：它到底是谁报的错

很多人第一次看到error -110会下意识去翻 WiFi 芯片的 datasheet，想找出 110 号寄存器或者 110 号状态位。方向就错了。搞清楚这个数字的来源，是后面所有排查的前提。

1.1 内核错误码的约定：负数就是 errno 取负

Linux 内核里有个很统一的约定：函数返回int，成功返回 0，失败返回负的 errno。errno 表里第 110 号是ETIMEDOUT，所以-110就是"超时"。跟它经常一起出现的还有几个兄弟：

这张表很有用。-110 和 -84 的区别，基本就是"没人应答"和"应答了但听不清"的区别。前者优先怀疑供电、时钟、复位、上拉；后者优先怀疑信号质量和时钟频率。我在实际排查里第一步就是看这两个码哪个出现，能砍掉一半的排查方向。

1.2 一次 CMD53 要穿过几层才落到引脚上

要理解超时是怎么发生的，得知道一条命令要过几道手。以一次典型的 SDIO 数据读写（CMD53）为例，从上到下大致是这么几层：

1. WiFi 驱动层（比如 brcmfmac、rtl8xxxu 这类）。驱动组好数据，调用 SDIO core 提供的读写接口，然后阻塞等待完成。
2. MMC/SDIO core 层。把请求翻译成 SDIO 命令，挂到 host 的请求队列上，启动一个超时定时器（通常是几百毫秒到秒级）。
3. Host 控制器驱动层（sdhci、dw_mmc 等）。把命令写进控制器的寄存器，等控制器给出"命令完成"的中断。
4. 硬件控制器。按协议在 CLK 上打节拍，在 CMD 线上发命令，在 DAT0~DAT3 上收数据。
5. SDIO 卡（WiFi 芯片）。芯片内部的状态机响应，或者不响应。

超时可能发生在任何一层。如果是第 3 层就超时了，日志里会看到mmc1: Timeout waiting for hardware interrupt或者Timeout waiting for hardware cmd interrupt，这说明连控制器自己都没等到中断，卡根本没在 CMD 线上回应。如果是第 2 层的请求超时，日志通常是mmc1: error -110 whilst initialising SDIO card或者mmc1: card never left busy state。

而如果是第 1 层的固件邮箱超时，日志会带驱动前缀，比如brcmf_sdio_bus_txctl: dongle is not responding: err=-110。这条特别容易被误读，因为它意味着"SDIO 总线本身是通的，固件也下进去了，但芯片在固件层面没回邮箱消息"。

1.3 为什么日志里的 -110 几乎只出现在两个位置

把上面几层对上现实，-110 高频出现的位置其实就两个：

• 枚举阶段。也就是whilst initialising SDIO card这一段。此时芯片刚上电，正在走 CMD0 → CMD5 → CMD3 → CMD7 的流程，读 CIS、协商电压和时钟。这个阶段超时，九成是硬件问题：电没给对、复位没放开、LPO 时钟没来、上拉缺失。
• 固件下载完成后的通信阶段。典型日志是dongle is not responding。这个阶段超时，往往是芯片中途复位了、电源在发射瞬间塌了、或者固件/NVRAM 文件不匹配导致芯片跑飞。

我个人的经验是：枚举阶段的 -110 先查板子，通信阶段的 -110 先查电源和固件版本。方向对了，能省下好几天。

2. 别急着返修：用三段式流程把范围缩小到板子或代码

拿到一个 -110，最忌讳的就是立刻改板或者立刻换驱动版本。我一般会走一个固定的三段式流程，目的只有一个：用最低成本确定问题在硬件还是软件，再决定往哪个方向深挖。

2.1 第一步：把 dmesg 的时间线按毫秒级对齐

第一件事是拿到完整日志，而且必须带时间戳。命令很简单：

dmesg -T | grep -Ei "mmc|sdio|brcm|wlan|wifi|regulator"

如果内核开了 dynamic debug，还能把 mmc 子系统的调试信息打开，看到每条命令的细节：

mount -t debugfs none /sys/kernel/debug echo 'file mmc* +p' > /sys/kernel/debug/dynamic_debug/control echo 'file core.c +p' > /sys/kernel/debug/dynamic_debug/control

这时候再复现一次，日志会密很多。重点看三件事：从 regulator 上电到第一条 mmc 命令之间隔了多久；枚举过程中第几条命令开始超时；超时之后控制器有没有重新尝试降速枚举。很多板子的问题一看时间线就露馅了，比如 regulator 使能日志比 mmc 枚举还晚，那就是典型的上下电顺序写反了。

同时看一下当前总线状态：

cat /sys/kernel/debug/mmc1/ios

这个文件会告诉你当前的时钟频率、总线宽度、时序模式（legacy / high speed / SDR104）、信号电压。如果显示的是 SDR104 且时钟 208MHz，而你手上是块刚打样的板子，那基本可以确定是这个速度跑不动，先降下来试试。

2.2 第二步：降频与降位宽，最低成本的变量隔离

这是我最推荐的一招：在设备树里把max-frequency从 50MHz 改成 25MHz 甚至更低，把bus-width从 4 降到 1，然后重新编译烧录。如果改完就正常了，说明问题大概率在信号完整性或者供电余量上，而不是驱动逻辑。这一步不需要动硬件，半小时就能出结论。

举个我碰到的真实例子：一块用 SDIO 接 WiFi 模组的板子，4 线 50MHz 下必现 -110，改成 1 线 25MHz 后就稳了。这种情况下问题不在"能不能通"，而在"高速下眼图闭了"。后面查出来是 CLK 走线绕了远路，还跟一路 PWM 背靠背走了很长一段。降频只是验证手段，不是解决方案，但它能帮你把问题定性。

注意：有些模组在低频率下反而不工作，因为芯片内部的初始化固件有一套默认的时钟假设。所以降频如果没效果，别急着否定信号完整性方向，试着换成相邻的几档频率各跑一次，看是不是"某个频段特别差"，这本身就是信号完整性的典型特征。

2.3 第三步：分清"没人应答"和"应答了但校验不过"

把日志里的错误码和超时阶段做个交叉，能画出一张很实用的分诊表：

这张表我几乎每块新板子都会过一遍。它不能直接给答案，但能满足"排除法"的需要——能明确排除掉的方向，本身就是进展。

3. 硬件侧翻车重灾区：供电、时序、走线、上拉

如果前面的流程把问题指向硬件，那接下来就是具体的四个重灾区。这四个地方占了我见过的硬件类 -110 的绝大部分。

3.1 供电：WiFi 发射瞬间的电流坑和去耦电容的真实作用

很多人看 WiFi 模组的平均功耗，觉得 3.3V、一两百毫安，用个普通的 LDO 完全够。然后板子一跑就 -110。问题出在峰值电流上。WiFi 在发射瞬间的瞬时电流可以冲到 300mA 甚至更高，而且上升沿很陡，持续几百微秒。这段时间里，如果电源路径上的等效串联电阻和等效串联电感偏大，模组端的电压就会瞬间掉下去，芯片内部的状态机被复位，SDIO 总线上的表现就是"突然不应答了"。

去耦电容的意义就在这里，而且有个很容易被忽略的点：电容要靠近模组的电源引脚放，而不是靠近稳压器放。我见过好几块板子，10uF 和 0.1uF 都规规矩矩地放在 LDO 输出旁边，离模组有 20mm 远，中间还隔着一段细走线。这种情况下电容对高频瞬态的响应基本无效，因为它和负载之间那段走线的电感已经把高频阻抗抬起来了。

实际操作上的建议是：

• 模组的 VBAT/VDD 引脚旁边放一颗 10uF 的陶瓷或钽电容，再并一两颗 0.1uF 和 1nF，越小越近。
• 电源走线尽量粗，能走平面就走平面，不要用细线串过去。
• 如果 LDO 的瞬态响应一般，考虑换成响应更快的型号，或者在 LDO 输出加一颗大容量电容做能量缓冲。
• 有条件的用电流探头配示波器，直接看发射瞬间模组端的电压波形，比任何推理都直观。

3.2 上电时序：WL_REG_ON 与 32.768kHz LPO 的配合

WiFi 模组基本上都有两个关键的外围信号：一个是使能脚（常见叫法有 WL_REG_ON、WL_EN、CHIP_EN），一个是低功耗时钟输入（通常是 32.768kHz，简称 LPO）。这两个信号的时序错了，枚举阶段的 -110 会稳定复现。

先说要命的顺序问题。正确顺序是：先给 VBAT/VDDIO 上电，稳定之后把使能脚拉高，再等一段时间（一般 50~200ms，具体看手册），然后 mmc 控制器才开始枚举。如果设备树里的 regulator 和 pwrseq 顺序写反，或者 pwrseq 的延时给得太短，芯片还没准备好，host 就开始打 CMD0，那必然超时。这里的延时不能拍脑袋，要去翻模组的 datasheet，找Power-up Sequence那一节的时序图，里面有明确的t1、t2参数。

再说 LPO。有些芯片（尤其是带低功耗模式的方案）在固件下载和休眠唤醒阶段依赖 32.768kHz 时钟。这个时钟通常来自板上的 RTC 或者专门的晶振。如果没接、接错、或者信号幅度不够，表现就是枚举过了、固件也下了，但通信阶段时不时dongle is not responding。这个坑很隐蔽，因为完全不影响它"看起来能起来"，只是稳定性很差。排查手段是用示波器直接量 LPO 引脚，确认频率、峰峰值和波形干净程度。

3.3 走线与串阻：为什么 CLK 线不能随便拉长

SDIO 里最容易出问题的信号是 CLK。它是唯一一个由 host 单向驱动、频率最高的信号，其他信号都要跟着它的节拍走。CLK 走线一旦拉长、绕远、或者旁边有强干扰源，边沿就会出现振铃和过冲，采样窗口被吃掉，最终表现为 -84 或者 -110。

几条我踩出来经验：

• CLK 走线尽量短，尽量直，尽量和同组的 CMD、DAT0~DAT3 保持等长，长度差控制在几毫米以内。
• 在 CLK 源端串一颗 22Ω 到 33Ω 的电阻，用来压振铃。这个电阻的位置很讲究，要串在驱动端附近，不是接收端。
• CMD 和 DAT 线上也可以视情况串小电阻，但别一次全加上，容易把边沿压得太慢导致新的超时。
• 不要在 SDIO 信号线下面铺大面积的开关电源或者 DC-DC 的走线，耦合噪声很难处理。

有一点要提醒：串阻不是万能的，它是用来修整边沿的，不是用来救走线布局的。如果已经拉到 208MHz 跑 SDR104，布局又很糟糕，串阻只能让你从"必现"变成"偶尔"，不能根治。

3.4 上拉电阻、VDDIO 电平与 DAT1 中断线

SDIO 总线上拉的问题经常被忽略，因为很多 SoC 内部已经带了可配置的上拉电阻。但"内部有"不等于"参数合适"。上拉太弱，信号上升沿被拉慢，高速下就是超时；上拉太强，又会让驱动端灌电流变大，功耗和边沿都会变差。

还有两个点值得单独拎出来：

• VDDIO 电平必须匹配。现在很多 WiFi 模组支持 1.8V 和 3.3V 两种 IO 电压，靠寄存器或者配置决定。如果设备树里声明了 1.8V 时序（比如开了 SDR104），但硬件实际供的是 3.3V，或者反过来，就会出现各种奇怪的超时。这类问题特别容易在"换了一批模组"之后出现，因为不同批次默认状态可能不一样。
• DAT1 中断线。SDIO 卡中断是通过 DAT1 上报的，很多板子忘记在这根线上加上拉，导致中断收不到，驱动只能靠轮询等待，表现就是超时变成常态。设备树里对应的是cap-sdio-irq这个属性，用了它就必须保证 DAT1 的硬件条件到位。

4. 软件侧隐形坑：设备树、caps、固件文件三件事

排完硬件，剩下的就是软件配置。这一块的特点是：配置写错不会报错，只会安静地让总线工作在错误的状态下，然后等到某次通信量大了才突然 -110。

4.1 mmc 控制器节点里那几个必须写对的属性

一块板子上 mmc 控制器的设备树节点，看起来平平无奇，但每个属性都在改硬件行为。以常见的嵌入式 SoC 为例，一个 SDIO 接 WiFi 的节点大概是这个结构：

&sdmmc1 { bus-width = <4>; non-removable; cap-sdio-irq; keep-power-in-suspend; disable-wp; max-frequency = <50000000>; mmc-pwrseq = <&sdio_pwrseq>; vmmc-supply = <&vcc_wifi>; vqmmc-supply = <&vcc_wifi_io>; status = "okay"; };

逐个说清楚为什么这么写：

• bus-width = <4>走 4 线。如果硬件只连了 DAT0，这里写 4 就会在枚举后段超时。
• non-removable表示卡是焊死的，不会被拔掉。不写这个，控制器可能会去做卡检测，某些平台会因为检测不到 CD 信号而放弃初始化。
• cap-sdio-irq让驱动使用 DAT1 中断，减少轮询开销。前提是 DAT1 硬件上拉到位。
• keep-power-in-suspend保证系统休眠时 WiFi 不掉电，不然唤醒后重新枚举很容易撞上时序问题。
• max-frequency是上限。我通常先写一个比较保守的值把功能跑通，再逐步往上加，每加一档做一轮长时间压测。

4.2 pwrseq 和 regulator 的启用顺序

mmc-pwrseq-simple这个节点看起来很不起眼，但它决定了使能脚什么时候拉高：

sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <200>; };

这里GPIO_ACTIVE_LOW的写法和很多人直觉相反：它表示"低电平是复位状态"，所以 pwrseq 在供电时会把这个引脚拉高，也就是释放复位。如果你写成了GPIO_ACTIVE_HIGH，那结果就是使能脚一直是低，芯片永远不上电，枚举必超时。这个错误我在别人的板子上至少见过三次。

post-power-on-delay-ms就是前面说的"等芯片准备好"的延时，别嫌它大，200ms 对启动时间影响微乎其微，但能挡掉一大批偶发问题。

至于 regulator，重点是保证vmmc 和 vqmmc 两个电源的顺序和上电时间满足模组手册。有的模组要求 VDDIO 先于 VBAT，有的反过来，看手册。设备树里可以通过regulator-ramp-delay和regulator-enable-ramp-delay来微调。

4.3 固件、NVRAM 与校准文件缺失时的表现

还有一个特别容易被当成硬件问题的软件坑：固件文件缺失或者路径不对。很多 WiFi 方案（尤其是 Broadcom/Cypress 系的 brcmfmac）需要从文件系统加载三个东西：固件.bin、NVRAM 配置.txt、以及某些方案的校准数据。

如果文件缺失或者名字对不上，由于固件根本下不进去，芯片会一直卡在等待状态，表现就是brcmf_sdio_download_firmware: dongle is not responding: err=-110。这种情况你换板子、换电源、降频都没用，因为它压根不是硬件问题。

排查方法很简单，把驱动的调试等级拉高，看它到哪个路径去找文件：

dmesg | grep -i "firmware" ls -l /lib/firmware/brcm/

确认文件名和芯片型号完全对应，注意大小写和连字符。同一个芯片不同封装、不同批次，固件名可能就差一个后缀，这个我吃过亏。

5. 一次真实的 -110 复盘：从复现到定位到修复

前面讲的是方法论，这里用一个完整案例把流程走一遍。

5.1 现象与初始日志

一块基于某国产 SoC 的板子，SDIO 4 线接 WiFi 模组。第一批 10 块样板，其中 3 块在冷启动时必现 -110，另外 7 块偶尔出现，热启动之后基本都能起来。日志长这样：

[ 3.214560] mmc1: Timeout waiting for hardware interrupt. [ 3.215031] mmc1: error -110 whilst initialising SDIO card [ 4.302118] mmc1: Timeout waiting for hardware interrupt. [ 4.302601] mmc1: error -110 whilst initialising SDIO card

注意，卡在了枚举阶段的早期，而且两次重试都失败。

5.2 排查动作与每步的结论

我按顺序做了这么几件事，每一步都记录结论：

1. 看 regulator 与 mmc 的时间线。日志里 regulator 使能比第一条 mmc 命令早了 40ms，看起来对，但模组手册要求的是最少 150ms。结论：延时不够，先改。
2. 改 pwrseq 延时到 200ms。3 块必现的板子里有 1 块变正常了，另外 2 块和 7 块偶发的依旧。结论：延时是个问题，但不是唯一问题，说明还有别的因素。
3. 降频到 25MHz、单线。10 块板子全部正常启动。结论：问题跟信号质量或供电余量强相关。
4. 恢复 4 线，降到 25MHz。10 块里 8 块正常，2 块仍偶发。结论：进一步指向信号完整性。
5. 示波器量 CLK 波形。发现边沿有明显振铃，过冲接近 0.8V，而且 3.3V 的上升沿有明显台阶。结论：走线阻抗不连续，且上拉偏强。
6. 量模组端电源。在启动瞬间能看到约 200mV 的跌落。结论：供电去耦不够。

5.3 根因与改法

综合下来是三个因素叠加：

• pwrseq 延时太短，150ms 是下限，实际量产件一致性差，直接给到 250ms 更稳。
• CLK 走线过长且有一段绕行，导致 50MHz 下边沿振铃。硬件上飞线缩短走线、在 CLK 源端加 27Ω 串阻后，振铃明显收窄。
• 模组 VBAT 引脚旁只有一颗 1uF 电容，去耦不足。补了一颗 10uF 和一颗 0.1uF 后，启动瞬间的电压跌落从 200mV 降到 60mV 以内。

软件侧的最终配置：

&sdmmc1 { bus-width = <4>; non-removable; cap-sdio-irq; keep-power-in-suspend; max-frequency = <25000000>; mmc-pwrseq = <&sdio_pwrseq>; vmmc-supply = <&vcc_wifi>; status = "okay"; }; sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <250>; };

5.4 回归验证要看的几个点

改完之后不能只看"能起来"，要按这几个维度压一轮：

• 冷启动 200 次，每次断电至少 10 秒，统计失败率。改之前是 30% 必现加 70% 偶发，改之后 200 次全过。
• 高低温。低温下晶振和电容特性都会变，很多信号完整性问题只在低温或高温暴露。做 -20℃ 和 70℃ 各 50 次冷启动。
• WiFi 大流量传输时的电源纹波。用 iperf 之类的工具跑满吞吐，同时示波器盯着模组电源，确认没有超过阈值的跌落。
• 反复上下电。模拟用户开关 WiFi，看 pwrseq 释放和复位之间有没有残留状态。

6. 长期维护视角：量产阶段怎么把 -110 挡在出厂之前

研发阶段把 -110 修掉只是第一步，真正难的是量产几百上千台之后，它不会以低频偶发的形式冒出来，然后变成一堆无法复现的客诉。

6.1 把 WiFi 上下电做成压力测试项

出厂测试里加一项：循环开关 WiFi 电源 100 次，每次都要走完枚举、固件下载、扫描、关联的完整流程。任何一次失败就判 NG。这个测试能筛掉大量"只是时序余量不够"的板子。实现上就是循环操作使能脚对应的 GPIO，然后等驱动把网口拉起来，再检查dmesg里有没有出现 -110 或 -84。

for i in $(seq 1 100); do echo 0 > /sys/class/net/wlan0/device/power_control 2>/dev/null ifconfig wlan0 down 2>/dev/null sleep 2 ifconfig wlan0 up 2>/dev/null || echo "FAIL at round $i" dmesg | tail -50 | grep -E "\-110|\-84" && echo "SDIO ERROR at round $i" done

具体路径因平台而异，核心思路是让 SDIO 总线完整地经历一次"断-连"循环。

6.2 老化测试与不同温度下的表现差异

我见过太多这样的案例：常温下跑几个小时没问题，放到 60℃ 的环境里跑两小时就开始掉线，日志里全是 -110。原因通常是电源芯片在高温下效率下降、电容容值变化、或者模组本身发热叠加导致的余量不足。所以老化测试一定要覆盖温度区间，不能只在空调房里跑。

另外一个容易被忽略的是长时间大流量下的热累积。WiFi 芯片持续发射本身就会发热，如果模组周围散热不好，芯片温度上去之后，内部某些模拟电路的工作点会漂移，表现就是跑一段时间后开始超时。这种情况在结构设计阶段就要考虑，比如模组下面加散热焊盘、开散热孔，或者调整射频发射的占空比。

6.3 一份可落地的自检清单

最后给一份我平时用的清单，从软到硬，按排查成本从低到高排列：

1. 确认固件、NVRAM 文件存在且名字匹配，路径正确。
2. 确认设备树里bus-width和实际连线一致，non-removable已加。
3. 确认 pwrseq 的 GPIO 极性和post-power-on-delay-ms满足模组手册。
4. 确认 regulator 上电顺序和延时满足手册，VDDIO 电平一致。
5. 用max-frequency降频测试，确认问题是否与速率相关。
6. 用示波器量 CLK 边沿、LPO 频率、模组端电源跌落。
7. 在 CLK 源端加串阻，检查走线长度和等长情况。
8. 检查模组电源引脚旁的去耦电容布局，确认是靠近负载而不是靠近稳压器。
9. 检查 DAT1 上拉，确认cap-sdio-irq的前提条件成立。
10. 做冷启动、高低温、大流量三类压测，统计失败率。

我自己在实际操作中的体会是，-110 这类问题几乎从来不是单一原因造成的，而是几个"刚好都差一点"的因素叠加。所以排查时不要指望找到某一个神奇的错误点，而是要把每个环节的余量都补足。反过来，一旦你在某个项目上吃过一次亏，就把上面这份清单固化进硬件设计规范和出厂测试脚本里，后面同样的坑就不太会再踩第二次。