企业官网建设流程全解析

1. 瞅一眼全局：Linux WiFi驱动到底在搞什么

说到Linux下的WiFi设备驱动开发，很多人第一反应是：这玩意儿不就是移植一个驱动模块嘛，厂商给个源码，交叉编译一下、insmod一下，完事。真上手做一遍就会发现，水比想象中深。你以为的“移植”只是整个链条里最简单的一环，真正吃时间的，是搞懂硬件接口、内核无线子系统、设备树、固件加载、电源管理、共存策略这些东西之间的咬合关系。

这篇文章我按照实际项目的推进顺序来写，面向的是做过一点Linux驱动、想往无线方向深入的同学，或者已经在做嵌入式Linux、突然要接一个WiFi模组的人。如果你只是想在笔记本上装个无线网卡、用系统自带的驱动，那你不需要看这篇；但如果你是在做板子、做模组、做物联网设备，要在自己的硬件上把一个WiFi芯片“点亮”，这篇文章应该能帮你少踩几个坑。

先说清楚WiFi设备驱动在整个系统里的位置。从应用层往下数，依次是：socket接口 -> 网络协议栈 -> 驱动 -> WiFi芯片。驱动层往上要对接内核网络子系统，往下要控制具体的芯片。一个完整的Linux WiFi驱动，不光是“让芯片能发数据”，它还要负责扫描、连接、认证、省电、多天线、频段切换这些事情。所以Linux内核专门有一套无线子系统来处理这些逻辑，也就是cfg80211和mac80211这两兄弟。驱动工程师的工作，大半是在跟这两个框架打交道。

后面我会从整体设计思路开始讲，然后是核心框架和数据结构、设备树和内核配置、完整实操流程，最后是问题排查。内容偏实战，尽量少讲虚的。

2. 方案选型与整体设计思路：先搞清楚芯片挂在哪个总线上

2.1 三种常见硬件接口：SDIO、USB、PCIe

拿到一个WiFi模组，第一步不是翻驱动源码，而是看它的硬件接口是什么。这直接决定了驱动框架的选择，也决定了你后面调试用什么工具。目前主流的WiFi芯片接口就三种：SDIO、USB、PCIe（或者更准确地说，SDIO和USB是嵌入式设备上用最多的，PCIe更多用在PC和高端平台上）。

SDIO接口在嵌入式里最常见，因为很多主控芯片（比如各种ARM SoC）本身就带SD/MMC控制器，而且SDIO走的是MMC子系统，延迟比USB低、功耗也更可控。市面上大量的小型WiFi模组都做成SDIO接口，跟eMMC、SD卡槽共用一套总线。缺点是SDIO的时钟频率、电压域、上电时序都比较讲究，板级设计不好的话经常会遇到“识别不到设备”的问题。

USB接口的WiFi模组也不少，特别是在一些Linux开发板上（比如用RT5370、RTL8188这类老芯片的模组），插上就能用，调试相对简单。但USB接口的缺点是功耗高、传输效率不如SDIO，而且USB驱动里处理URB（USB Request Block）的代码写起来要比SDIO那套繁琐一些。

PCIe接口则是胖终端、路由器主控板上的常客，驱动模型又不一样，要走PCI子系统，还要处理BAR空间映射、MSI中断这些东西。做工业路由器、边缘网关的工程师应该比较熟。

2.2 用自带驱动还是厂商驱动？我的建议

确定接口之后，第二件事是搞清楚：你这个芯片，内核主线里有没有现成驱动，还是只能用厂商提供的源码？

我个人的建议是：优先看内核主线。Linux内核的无线子系统已经收录了大量芯片驱动，比如ath9k、ath10k、mt76、brcmfmac、rtl8xxxu、rtw88等。如果你用的芯片恰好被主线支持，那真是省了一大半事，直接打开Kconfig里的对应选项，配置好固件文件就行，稳定性和后续维护都不用愁。

如果内核没有，那就只能用厂商驱动。这类驱动的质量参差不齐，有的写得挺规范、能在新内核上编译通过；有的则停留在老内核时代，需要你手动修一堆API兼容性错误。拿到厂商驱动之后，我建议先干这些事：第一，确认它针对的内核版本，跟你当前内核差多少；第二，看它的构建方式，是独立的Makefile还是要打进内核源码树；第三，找它的固件文件、配置工具、README，把这些东西一口气看完再动手。别急着编译，先把文档读完，后面能省很多时间。

2.3 与字符设备驱动的本质区别

我见过不少从字符设备驱动转过来的人，一开始容易陷入一个误区：以为WiFi驱动也要实现file_operations里的open、read、write。其实完全不是这样。

字符设备驱动面向的是“设备文件”，你用open/read/write去操作它；而网络接口驱动面向的是“网络接口”，它注册的是struct net_device，内核通过net_device_ops里的ndo_open、ndo_start_xmit、ndo_stop这些回调跟驱动打交道。数据路径上，发数据走ndo_start_xmit，收数据靠驱动把skb往netif_rx或者napi_gro_receive里塞，完全不是read/write那套逻辑。

这个认知差异挺重要。如果你拿字符设备驱动的经验去套WiFi驱动，会觉得处处别扭。反过来，如果你理解了网络设备驱动是“协议栈往下走的一层接口”，你就明白为什么WiFi驱动上面还要套cfg80211和mac80211——因为无线网络的连接管理太复杂了，协议栈没法直接跟每一种芯片的私有接口打交道，必须抽象一层公共接口出来。

3. 核心框架拆解：cfg80211、mac80211与驱动的关系

3.1 内核无线子系统的分工

Linux无线子系统从上到下大概是这么个结构：用户空间的无线管理工具（iw、wpa_supplicant、NetworkManager）通过netlink跟内核通信，内核侧的第一个大模块是cfg80211，它负责管理无线设备的配置、扫描结果、连接状态、加密参数等；再往下是mac80211，它实现了大部分802.11协议逻辑，包括帧格式封装、管理帧处理、软件加密、电源管理等；最下层才是具体芯片的驱动，它通过mac80211抽象出来的接口操作硬件。

这里需要说清楚一件事：mac80211并不是每个WiFi驱动都要用。如果你的芯片是个“全MAC”芯片，也就是说硬件自己就能处理完整的802.11协议栈，那驱动可以直接对接cfg80211，不需要碰mac80211。这种情况多见于老式全功能网卡和部分USB网卡。而如果你的芯片是“半MAC”芯片，硬件只处理底层的收发、调制解调，协议的帧管理、加密等都得由软件来干，那驱动必须用mac80211，驱动要填一堆ieee80211_ops回调。

做驱动开发时，这两种模式在编码上有天壤之别。全MAC驱动比较省心，你要做的主要是把硬件寄存器配置好、把数据包从网卡搬到协议栈；半MAC驱动则要求你对802.11协议本身有较深理解，比如关联请求、认证帧、Beacon帧这些都要在软件层面处理好，代码量会大一个数量级。

3.2 驱动要实现的关键回调

如果你用的是mac80211框架，核心就是实现struct ieee80211_ops。这个结构体里回调非常多，但真正要你全部实现的场景很少，多数时候你只需要关心其中几个：

• start和stop：启动和停止无线硬件，对应网卡up/down。
• config：配置硬件参数，比如信道、频段、发射功率。
• add_interface和remove_interface：添加/移除一个虚拟无线接口（比如sta模式、ap模式）。
• config_interface：配置接口参数，比如BSSID。
• configure_filter：配置硬件要接收哪些帧，比如Beacon、Probe Request。
• tx：发送数据帧，这是数据路径的核心。
• set_key：设置加密密钥，如果硬件支持硬件加密就写到硬件，否则留给mac80211软件加密。
• hw_scan：发起硬件扫描，如果支持的话。

实际操作中，你拿到厂商驱动后，基本不用从头实现这些回调，厂商源码里已经写好了。你真正要改的是芯片初始化、GPIO控制、电源时序这些跟你的具体板子强相关的部分。所以“驱动开发”这个活，很多时候是“驱动适配”加“平台移植”。

3.3 收发路径与firmware的作用

WiFi芯片内部不是靠裸寄存器就能把所有事干完的，绝大多数芯片都有一个内置的MCU，驱动要往这个MCU里加载一段固件，它才能正常工作。这就是为什么你在文件系统里要放一堆.fw文件，比如rtlwifi/rtl8821cufw.bin、brcm/brcmfmac43455-sdio.bin这种。固件文件在哪个目录、叫什么名字、引导时怎么校验，是新手最容易出错的地方。

数据收发路径上，SDIO接口的驱动通常用sdio_readb/sdio_writeb或者sg模式批量收发；USB接口的驱动要把skb的数据拆成USB URB，批量发送；PCIe接口则直接操作DMA描述符。不管是哪种，数据方向都是：协议栈 -> ndo_start_xmit -> mac80211的tx -> 驱动 -> 芯片固件 -> 天线。收包反过来，芯片收到数据后通过中断或者轮询通知驱动，驱动把数据塞给mac80211，再往协议栈送。

这段路径如果哪一层出问题，表现都不同：驱动层的问题多在设备识别和初始化阶段，固件问题会导致芯片无法正常工作，收发路径问题则表现为能连上但ping不通、网速极慢、疯狂掉包。排查的时候按这个层次去定位会快很多。

4. 设备树与内核配置：点亮芯片的前置动作

4.1 设备树里怎么描述一个WiFi节点

如果你的板子用的是SDIO接口的WiFi芯片，那么设备树里通常要做两件事：一是配置SDIO/MMC控制器节点，二是添加WiFi芯片的子节点。下面是一个典型的设备树片段，我把关键属性都标了注释，方便你对照自己的板子改：

&mmc1 { status = "okay"; vmmc-supply = <&reg_3p3v>; /* 卡槽供电，3.3V */ vqmmc-supply = <&reg_1p8v>; /* IO域供电，1.8V */ bus-width = <4>; /* 使用4位SDIO总线 */ max-frequency = <50000000>; /* 50MHz时钟，根据芯片手册调整 */ non-removable; /* eMMC/WiFi这种不可拆卸设备 */ cap-sd-highspeed; /* 使能SDIO高速模式 */ wifi@1 { compatible = "vendor,sdio-wifi"; /* 要和驱动里的of_match_table匹配 */ reg = <1>; /* SDIO function号，一般是1 */ interrupt-parent = <&gpio0>; interrupts = <23 IRQ_TYPE_LEVEL_LOW>; /* 芯片的host-wake引脚 */ interrupt-names = "host-wake"; reset-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>; /* 复位引脚，有就配 */ }; };

这里面有几个值容易搞错。reg的<1>不是随便写的，它表示这个WiFi芯片在SDIO总线上占用的function编号，你可以在驱动初始化代码里通过sdio_read_func_cis等接口去读CIS信息确认，也可以查芯片手册；如果你的芯片挂的是function 0，很多代码逻辑会跟function 1不一样。总线宽度、时钟频率、供电这三个参数我建议先按芯片参考设计的默认值来，不要拍脑袋调，否则容易把卡控制器搞到不稳定。

USB接口的WiFi芯片一般不需要设备树节点，直接靠USB VID/PID让驱动自动绑定。PCIe接口则需要在PCIe控制器节点下正常枚举，一般也不用专门写子节点。所以设备树这块的工作量，SDIO最多，USB和PCIe相对少。

4.2 内核配置项清单

内核配置是整个环节里最容易被忽略的一步。很多人在厂商源码里编出一个ko，insmod进去发现设备出不来，最后排查一圈，发现是内核里某些依赖选项没开。这里我先列一份通用的配置清单，照着勾基本不会缺：

CONFIG_WIRELESS=y CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_FW_LOADER=y CONFIG_NETDEVICES=y CONFIG_WLAN=y

如果你是USB接口，还要加上：

CONFIG_USB=y CONFIG_USB_SUPPORT=y CONFIG_USB_STORAGE=y # 有些模组内部是usb mass storage，需要这个

如果是PCIe接口：

CONFIG_PCI=y CONFIG_PCIE_BUS_PERFORMANCE=y # 可选，有些网卡需要

再往下就是具体芯片的驱动选项了。不同芯片在menuconfig里的位置不一样，Realtek的在Device Drivers -> Network device support -> Wireless LAN下，比如CONFIG_RTL8XXXU；Broadcom的也是在这个目录，方案是brcmfmac；MTK的mt76等也在附近。你可以用menuconfig搜索功能直接输入芯片型号或者驱动名去定位。

这里多提一句“系统裁剪优化”。很多嵌入式项目为了减小内核体积，会把大量驱动选项去掉，但裁剪的时候千万不要把内核无线子系统的依赖链给剪断了。我见过有工程师为了省空间，把CONFIG_FW_LOADER直接关了，结果所有需要加载固件的WiFi芯片全部工作不正常，报错还特别隐晦。所以在裁剪时，至少要保留cfg80211、mac80211、firmware loader这三根支柱。

4.3 固件文件怎么放、怎么加载

固件这块看着简单，其实坑也不少。内核的固件加载机制很简单：驱动初始化时调用request_firmware接口，内核会在文件系统里按顺序搜索几个目录，比如/lib/firmware/，找到同名文件之后把它读进内存，传给驱动，让驱动把数据写到芯片的MCU里。

具体要注意三点。第一，文件路径要放对。不同驱动期望的固件路径可能不一样，比如brcmfmac喜欢/lib/firmware/brcm/目录下，Realtek的有些驱动则直接放在/lib/firmware/rtlwifi/。如果你不确定，最直接的办法是看驱动的fw_files定义，或者modinfo模块名来看文件列表。第二，文件名不能错。有的驱动根据芯片版本会加载不同后缀的固件，比如brcmfmac会根据board type选4366b2、43455c0等文件，文件名错一个字符就会加载失败。第三，固件版本跟驱动版本要匹配。驱动跟固件一般是配套发布的，混用新旧固件经常导致莫名奇妙的问题，比如扫描不到网络、连上就断，这时候先怀疑固件版本对不对。

5. 实操全流程：从拿到模组到连上WiFi

5.1 动手前的检查清单

我把整个实操流程串一遍，就当是走一个具体项目。假设我现在拿到一块SDIO接口的WiFi模组，主控SoC是某个常见的ARM平台，内核版本是5.10或5.15。

拿到模组之后，我按这个顺序检查：

1. 翻原理图，确认模组的供电、复位、中断、SDIO时钟/数据线分别接到了主控的哪些引脚。把引脚对应关系抄下来，后面写设备树用得上。
2. 确认主控的SDIO控制器是哪一路，看它在设备树里是不是已经启用，有没有被eMMC占掉。
3. 去内核源码里查，这颗WiFi芯片在主线有没有对应驱动。有的话直接用；没有的话联系厂商要驱动包。
4. 确认内核版本和驱动要求的版本是否兼容。如果驱动是老内核的，先预估一下要修多少编译错误。
5. 准备好固件文件，放到rootfs的/lib/firmware/对应目录下。

这个过程听起来平淡，但非常关键。很多人跳过前面几步，直接编译驱动、加载，发现设备出不来，再回头查，效率反而低很多。

5.2 设备树改完之后的检查方法

假设我用的是一块CSR或者Semtech风格的SDIO WiFi模组（这里拿某款常见模组举例），驱动已经确定用厂商提供的源码。第一步是改设备树，把mmc节点和wifi子节点加上。改完之后，先不急着编译整个内核，可以先单独编译设备树，然后重启加载。

重启之后，在Linux命令行下执行：

# 查看mmc总线上枚举到了什么设备 ls /sys/bus/sdio/devices/ # 查看dmesg里跟mmc/sdio相关的信息 dmesg | grep -i mmc dmesg | grep -i sdio dmesg | grep -i wifi

如果你能看到类似这样的输出：

mmc1: new high speed SDIO card at address 0001 mmc1: sdio device 0x1234:0xabcd (manufacturer)

说明SDIO层已经成功识别到这个设备了，接下来就等驱动绑定。如果卡在这一步，说明设备树配置、供电或SDIO总线有问题。这个阶段是纯硬件/总线问题，跟驱动代码关系不大。

如果SDIO识别不到，我一般先查三样东西：供电有没有到位、复位脚电平对不对、SDIO的时钟和数据线有没有接反。实测中“供电没到位”占了大概一半的原因，特别是那些需要先拉高使能脚、再给电源的模组，时序错了就会导致上电后SDIO设备不响应。

5.3 编译驱动模块的两种方式

编译WiFi驱动有两种方式：直接编进内核，或者编成模块（ko）。我的建议是调试阶段一律编成模块，方便改代码、方便卸载重载，也方便用insmod/modprobe控制加载顺序。等驱动稳定了，再考虑要不要编进内核，减少启动时间。

厂商驱动一般自带一个独立的Makefile，编译的时候要指定内核源码目录和交叉编译工具链前缀，比如：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KDIR=/path/to/kernel_source modules

如果驱动是放在内核源码树里的，那就直接在menuconfig里把它配成m，然后编译：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules

编出来的ko文件，用insmod加载之后，用dmesg看有没有报错。常见的问题是符号找不到，比如undefined symbol，说明内核版本太新或太旧，需要修代码或者换分支。

模块加载成功之后，用iw dev看有没有生成无线接口。正常情况会多出一个类似wlan0或者phy0的接口。如果没有，看一下dmesg，大概率是固件没加载或者mac80211注册失败。

5.4 用工具验证驱动是否真的跑通

驱动加载成功、无线接口出现，只是第一步。接下来要验证它能不能扫描、能不能连接、能不能正常传数据。我常用的验证步骤是这样的：

# 查看无线设备能力 iw list # 扫描周围热点 iw dev wlan0 scan # 连接一个开放网络测试 iw dev wlan0 connect YourSSID # 查看连接状态 iw dev wlan0 link # 启用DHCP获取IP udhcpc -i wlan0 # ping外部网关 ping -I wlan0 192.168.1.1

这里要注意，iw dev wlan0 connect只能连开放网络，如果热点有WPA/WPA2加密，需要用wpa_supplicant来管理认证。很多驱动在驱动的驱动层面没有问题，但跟wpa_supplicant配合的时候会有兼容问题，比如扫描结果为空、频繁掉线。这时候用iw去操作是绕开了wpa_supplicant，能帮你判断问题是出在驱动还是出在上层的无线管理工具。

在验证阶段，我还喜欢在驱动代码里加一些printk日志，观察收发路径是否走到驱动内部。比如在tx回调里加打印，然后ping一下；在收包中断里加打印，看能不能收到对方的回应。如果发出去的包没有回应，先用iw dev wlan0 link确认关联状态，再用tcpdump在wlan0口上抓包。抓包是最快定位问题的手段。

6. 常见问题与排查技巧实录

6.1 设备状态是unclaimed，驱动没有绑定

这个现象在Linux下很常见。拿PCIe网卡举例，你用lspci能看到设备，但设备状态显示“unclaimed”，说明内核里没有驱动认领它。SDIO设备也有类似的情况，/sys/bus/sdio/devices/能看到设备节点，但里面没有driver目录。

排查思路很简单：先确认内核里对应的驱动选项有没有打开，编译出来的ko有没有装上，模块有没有被modprobe自动加载。如果都没问题，那就看驱动里的设备ID表，跟设备实际读出来的VID/PID是否匹配。

我遇到过几次“设备ID表不匹配”的情况：同一颗芯片的不同批次，厂商会微调PID，驱动里老旧的ID表跟不上，导致驱动拒绝绑定。解决办法是把实际读到的VID/PID加到驱动的id_table里。要查看设备ID，可以读/sys/bus/sdio/devices/xxx/device和vendor两个文件。

6.2 固件加载失败的排查

固件加载失败是另一大高发问题。dmesg里一般会有明确提示，比如：

brcmfmac: brcmf_fw_alloc_request: Unknown chip, chip id 0x1234 brcmfmac: brcmf_sdio_checkdied: firmware file not found

首先看固件文件的路径和名字是否跟驱动期望一致。其次要确认固件文件的权限，rootfs下一般644就行。再次，要确认rootfs里确实包含这个文件，有些情况下你的板子虽然文件系统上有目录，但打包rootfs的时候没把固件文件打进去，导致运行时找不到。

如果你用的是NFS挂载rootfs调试，还要注意NFS目录的属性和缓存问题。我踩过一次很傻的坑：固件文件改了个新版本，名字没变，但系统一直加载旧文件，后来发现是NFS缓存导致的。重启NFS服务或者换路径就好了。

6.3 SDIO识别不到、WiFi掉线、速率上不去

SDIO设备的稳定性问题比较玄学。如果时好时坏，先怀疑供电和时钟。供电纹波大就容易出现“默认能识别、负载大就掉线”的现象；SDIO时钟频率设得太高、板子走线又不好的话，偶尔也会出现信号完整性问题。这种问题在驱动层很难彻底解决，需要板级配合。

另外一个常见毛病是电源管理。很多WiFi芯片在空闲时会进入省电模式，SDIO总线挂起、时钟停掉。如果驱动的suspend/resume代码写得不好，或者中断唤醒逻辑不对，就会出现“连接一会儿就断、唤醒不回来”的情况。调试时可以在驱动里暂时把电源管理相关代码禁用，比如把rtw_ips_mode改成RTW_IPS_NONE，先排除是省电模式导致的掉线。

速率上不去的问题，多半不是驱动代码逻辑错误，而是天线匹配、射频校准数据、信道带宽设置这些外部因素。你可以先用iw list看芯片支持哪些带宽和速率，然后用iw dev wlan0 set channel命令手动指定信道和带宽测试。如果硬件本身不错，但吞吐率就是上不去，再查协议栈配置，比如TCP offload有没有开启、NAPI的权重配置等。

6.4 关于TX校准和量产

很多网卡出厂后要做射频校准，比如TX Power校准、IQ校准、频偏校准，这些参数一般存在芯片的OTP区域或者单独的配置分区里。驱动启动时会把校准参数加载进来。如果你发现网卡的信号强度、吞吐率明显低于正常水平，怀疑是校准数据丢失或不对，可以先看驱动日志里有没有校准相关的提示。

量产阶段这个东西尤其重要。很多工程师以为只要驱动跑通就能量产，结果产线上做出几十台机器后，WiFi信号忽高忽低，查来查去发现是校准数据没烧进去。建议在样机阶段就确认好校准数据的烧录方式和保存位置，量产的烧录脚本里要包含这一步。

6.5 查问题的心法和常用命令

排查驱动问题，我总结了一条原则：先外围后内核，先硬件后软件，先接口后协议。设备没识别出来，先查供电、时钟、复位、设备树；识别出来但无法扫描，先查固件和驱动里的MAC/PHY初始化；能扫描但连不上，先查wpa_supplicant配置和认证逻辑；能连上但传数据不稳定，再查驱动收发路径和协议栈。

常用命令里，我最依赖这么几个：

dmesg | tail -100 # 看内核日志 iw list / iw dev / iw dev wlan0 scan # 无线设备信息 lspci -v / lsusb / ls /sys/bus/sdio/devices # 看设备枚举情况 cat /proc/interrupts # 看中断有没有触发 tcpdump -i wlan0 # 抓包 cat /sys/kernel/debug/ieee80211/phy0/ # 内核无线调试节点

有一些驱动会开启专用的debugfs节点，比如mac80211的debugfs会提供许多底层信息，比如信号强度、噪声底、当前信道、队列状态。如果驱动自身带debugfs支持，一定要学会用它，比你在源码里加一堆printk高效得多。

个人经验需要提醒一下：printk不是万能的。在中断上下文、原子上下文里乱加printk会影响时序，反而制造问题。尤其是SDIO和USB这类接口，如果收包中断里加了printk导致中断处理过慢，就可能触发看门狗或者协议栈超时。调试收发路径的时候，我一般先抓包确认问题在协议栈还是驱动层，再决定要不要加日志。直接在驱动里大海捞针式地加日志，往往事倍功半。

7. 收尾前的一点经验

最后分享一个我自己的体会。做Linux WiFi驱动开发，技术栈很宽，从硬件时序到内核框架，从固件管理到用户空间工具，每一层都可能出问题。但真正能让你从容应对这些问题的，往往不是某个具体的函数或者宏，而是对整个数据链路和状态管理的理解。

刚开始接触这个方向的时候，我也喜欢照着网上的教程改设备树、编驱动，碰到问题就搜，搜到答案就试。时间长了才明白，网上的答案很多都是针对特定板子的，别人能跑通不代表你也能。真正靠谱的做法是吃透内核的无线子系统架构，把cfg80211、mac80211、net_device这几层之间的关系理清楚，再遇到问题的时候，你能根据现象快速判断出问题出在哪一层，排查起来就快了。

另外建议新手一定准备一块JTAG调试板和一个稳定的无线抓包工具。JTAG可以在芯片初始化阶段用硬件断点来核对寄存器写入是否正确，无线抓包工具则能让你看到空口上的帧交互情况，这两样东西在排查疑难问题时能起到事半功倍的效果。一个SDIO接口接反都能让你折腾两天，有了示波器或逻辑分析仪，这些低级但致命的硬件问题几分钟就能定位。