开头先交代一下背景手上的全志T527板子需要把板载WiFi跑起来模块用的是AP6256。做之前我也查过这颗料在其它平台上的资料不算少但真到了T527上从内核配置到设备树再到固件路径还是会因为平台差异卡上几天。这篇文章就把我这次BSP调试第16期的完整过程做一次记录从AP6256的芯片底细、驱动使能、设备树配置、固件加载到最后的蓝牙共存和问题排查全部摊开讲清楚给同样在T527上调AP6256的朋友当个参照。1. 先搞清楚AP6256和T527这组搭配要干什么1.1 AP6256这颗料到底是什么底子AP6256是博通BCM43455的封装模组方案WiFi部分走SDIO接口蓝牙部分走UART接口是一颗WiFiBT二合一的Combo芯片。具体规格方面WiFi支持2.4GHz和5GHz双频2.4GHz下802.11n理论最高144.4Mbps5GHz下802.11ac VHT80单流理论最高433Mbps实测TCP吞吐通常在300Mbps上下。蓝牙则是BT4.2支持BLEHCI接口通过UART外接。整颗芯片需要外部提供32.768kHz睡眠时钟和24MHz主晶振这些时钟如果板子上没有预留一般会由SoC侧或者专门的晶振芯片提供。做BSP调试必须先明确一点AP6256在Linux内核里对应的驱动是brcmfmac蓝牙部分对应的是hci_uart或者btbcm。它不是全志自研的WiFi驱动而是内核自带的通用驱动框架所以大部分调试工作其实是围绕“怎么让内核正确识别这颗SDIO设备、把固件加载进去、再把射频参数校准文件放对位置”来展开的。1.2 全志T527上BSP侧要准备什么T527是全志推出的一颗面向工业级和边缘计算场景的SoCCortex-A55架构接口资源很丰富。和这次调试直接相关的接口是SDIO控制器和UART。AP6256的WiFi一般挂在SoC的SDIO2或者SDIO1上具体取决于板厂的原理图设计。BSP侧需要准备的东西主要有三类内核源码树必须确认已经包含drivers/net/wireless/broadcom/brcm80211/目录设备树源文件需要新增或调整SDIO节点的配置固件文件包括WiFi的bin文件、nvram校准文件和蓝牙的hcd文件。我这次是在标准的Linux 5.15内核上加T527 BSP包BSP包本身对AP6256已经有部分支持但仍然踩了一些坑。下面从驱动的使能开始讲。2. 把固件和内核配置摆到台面上2.1 内核配置项一图理清调试的第一步不是敲命令而是把内核的配置项厘清。我这里列一下AP6256在5.15内核上必须要开的配置方便直接对照配置项作用建议CONFIG_BRCMFMACbrcmfmac主驱动必选CONFIG_BRCMFMAC_SDIO支持SDIO接口传输必选CONFIG_CFG80211无线配置管理框架必选CONFIG_MAC80211软件MAC层支持必选CONFIG_WIRELESS_EXT兼容老的无线扩展接口建议开启CONFIG_BRCMUTIL博通工具库建议开启CONFIG_BT蓝牙协议栈用到蓝牙则必选CONFIG_BT_HCIUARTHCI UART传输驱动用到蓝牙则必选我踩过的第一个坑就是只开了CONFIG_BRCMFMAC但没开CONFIG_BRCMFMAC_SDIO结果驱动模块加载时直接报未知符号重新看了Kconfig才发现SDIO传输和USB传输是分开的两个选项。这个问题在文档里不会有人专门提醒自己不注意就会浪费半天。配置内核方式有两种一种是在menuconfig里手动勾选另一种是直接把配置项写进defconfig。量产项目建议直接写进defconfig因为手动选配一旦重新生成.config容易漏项。2.2 设备树里SDIO节点的关键动作设备树是这次调试中最容易出问题的地方。AP6256挂在SDIO总线上对应的设备树节点通常是mmc节点。T527的设备树里SDIO0/1/2各有不同的用途WiFi一般不会挂在SDIO0通常用于eMMC。我手上的板子WiFi挂在mmc1上节点大致长这样mmc1 { pinctrl-names default, sleep; pinctrl-0 mmc1_pins; pinctrl-1 mmc1_pins_sleep; bus-width 4; max-frequency 150000000; sd-uhs-sdr104; sd-uhs-ddr50; non-removable; mmc-pwrseq wifi_pwrseq; status okay; };几个关键点得说清楚bus-width 4AP6256的SDIO是4线模式如果配成8线或者1线都会出问题max-frequency我一开始按参考设计配了200MHz结果固件加载不稳定改成150MHz后稳定了很多。SDR104模式下控制器跑在150MHz是比较稳妥的选择non-removableWiFi芯片不是可插拔卡必须加这个标志否则内核会按热插拔流程处理导致探测异常mmc-pwrseq这个指向一个电源序列节点负责上电时序。AP6256的上电时序比较讲究后面单开一节讲。2.3 固件文件放置与命名细节AP6256的固件文件通常放在/lib/firmware/brcm/目录下我这边用到的文件有brcmfmac43455-sdio.binWiFi主固件brcmfmac43455-sdio.ap6256.txtnvram校准参数文件BCM4345C0.hcd蓝牙固件。注意文件命名的对应关系brcmfmac驱动加载时会按“芯片型号-总线类型”的规则去找固件所以brcmfmac43455-sdio.bin这个名字是固定的不能改。nvram文件则多了个后缀ap6256是模组型号标识这个后缀在不同厂商的文件里可能不同但必须是设备树里compatible属性或者驱动探测到的ID对应的名字。实际加载时固件放在/lib/firmware/brcm/还是/lib/firmware/取决于内核的FW_LOADER路径配置。我这边/lib/firmware/brcm/路径可用但如果你的rootfs里没建这个子目录建议直接用绝对路径查一下。一个快速验证固件路径的方法find /lib/firmware -name *43455*如果找不到文件驱动就会在启动日志里报brcmf_fw_alloc_request: Unknown chip 43455之类的错误。3. 开机Bring Up从固件加载到wlan0出现3.1 驱动加载全链路日志解读设备树和内核配置都准备好之后开机后可以通过dmesg观察驱动加载流程。一次正常启动的日志关键片段大概是这样的brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio.bin brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio.ap6256.txt brcmfmac: brcmf_bus_start: successful brcmfmac: brcmf_c_preinit_done: Firmware version wl0: Sep 11 2017 11:03:10 version 7.45.41.46 brcmfmac: brcmf_cfg80211_attach: success看到Firmware version和cfg80211_attach: success这两行基本可以确定WiFi固件已经加载成功。随后用ifconfig -a或者ip link就能看到wlan0接口。如果日志停在brcmf_sdio_htclk相关的位置通常是SDIO通信异常优先检查设备树里的频率和电压配置。如果日志根本没打印brcmfmac相关内容可能是驱动没编译进内核或者SDIO设备没有被枚举到。3.2 用wpa_supplicant打通联网wlan0出现只是第一步真正能连上路由器才算数。在根文件系统里配置wpa_supplicantcat /etc/wpa_supplicant.conf EOF ctrl_interface/var/run/wpa_supplicant network{ ssidtest_ap psk12345678 } EOF然后启动wpa_supplicant -D nl80211 -i wlan0 -c /etc/wpa_supplicant.conf -B wpa_cli -i wlan0 status拿到IP地址udhcpc -i wlan0我建议这里用BusyBox自带的udhcpc而不是dhclient轻量且调试方便。执行完wpa_cli status后重点关注几个字段wpa_state必须是COMPLETEDip_address必须已经被赋上。如果wpa_state一直停在SCANNING那就是扫描阶段出了问题去检查射频相关配置。3.3 SDIO速率与供电强相关参数核对AP6256对SDIO信号质量比较敏感尤其是高吞吐场景。这一节虽然是Bring Up但如果不提前核对供电参数后面跑吞吐测试时会吃大亏。我手里的板子WiFi供电用的是3.3V的DC-DC再加一颗LDO转1.8V给SDIO电平SDIO VDD是1.8V这个电压如果波动超过±5%在150MHz速率下就会出现偶发丢包。所以验证时最好用万用表测一下SDIO供电脚的实际电压不要只看原理图标注。另外mmc-pwrseq这个电源序列节点也要仔细配置。T527平台上我配置的内容是wifi_pwrseq: wifi-pwrseq { compatible mmc-pwrseq-simple; reset-gpios pio 3 1 GPIO_ACTIVE_LOW; post-power-on-delay-ms 200; };这里的reset引脚对应的是实际板子的WL_REG_ON脚不同板子GPIO编号不一样按原理图改。post-power-on-delay-ms我建议给足200ms以上AP6256的固件加载对上电时序要求比较严格太短会导致固件加载失败。4. 蓝牙伴生调试与WiFi共存处理4.1 蓝牙当独立外设来配AP6256的蓝牙部分挂在UART上不是通过SDIO传输。T527上我这边接到的是ttyS1。设备树里需要确保对应的UART节点打开并且没有和别的外设冲突。蓝牙驱动的加载方式是brcm_patchram_plus --enable_hci --baudrate 115200 --patchram /lib/firmware/brcm/BCM4345C0.hcd --no2bytes /dev/ttyS1 sleep 1 hciconfig hci0 up这里的--baudrate 115200是默认波特率实际使用中如果蓝牙需要高速传输可以在brcm_patchram_plus里加--baudrate 3000000这样的参数但前提是板子的UART控制器支持3Mbps。注意波特率切换时btbcm和hci_uart驱动可能会因为固件返回的ACL包时间戳而判定超时需要实测调整。调试蓝牙时有一个重要技巧hcitool scan能扫到手机不代表蓝牙就完全OK。还得用hcitool info mac查询远程设备的功能列表以及实际跑一轮蓝牙音频或BLE连接才能真正确认链路OK。只做扫描验证的话漏检低功耗蓝牙问题几乎必然发生。4.2 共存问题排查的切入角度WiFi和蓝牙在同一颗芯片上共用天线所以共存是绕不开的话题。AP6256在硬件设计上有BT_WAKE_HOST、WL_WAKE_HOST、BT_ACTIVE、WL_ACTIVE这几个引脚用来做共存协商BSP调试阶段如果这几个引脚没有在设备树里配置正确最常见的现象是蓝牙音频卡顿、WiFi吞吐掉一半。如果板子的硬件设计没有把共存引脚完全接出来只能从软件侧做妥协AP6256的nvram文件里有个btc_params相关的配置项某些固件版本允许通过nvram调整共存策略。但说实话以我的经验来看软件侧能调的非常有限核心还是硬件设计的电平逻辑。BSP阶段的建议很朴实别在共存问题上恋战确认原理图的引脚连接无误、驱动加载正常、功能验证通过就先往下走。共存性能的终极优化硬件依赖大于软件依赖这一点需要提前和硬件工程师沟通。5. 现场问题与排查方法实录5.1 wlan0反复不上电排查我曾经遇到过一次现象固件日志打印到一半就停wlan0始终不出现。最开始怀疑是固件文件不匹配反复换版本没用。最后用示波器量了WL_REG_ON引脚的上电时序才知道是电源序列里的post-power-on-delay-ms设置太短。板子晶振起振需要一定时间固件加载时时钟还没稳定驱动自然就死了。把延时从50ms加到200ms后问题解决。这个案例值得记住的原因在于当固件加载异常时第一个要查的不是固件本身而是供电和时钟是否先稳定。5.2 扫描列表空白但驱动正常Firmware version打印正常wlan0也出现了但用wpa_cli scan后scan_results一直是空列表。这种情况多半和nvram里的ccode国家码或macaddr配置有关。如果你手里的模组是在海外市场用的nvram里可能默认配了ccodeALL或者ccode00此时5GHz频段可能被限制扫描。可以临时在nvram文件里加一行ccodeCN然后重启内核或重新加载驱动模块再试扫描。注意nvram文件里的配置项大小写敏感改错了文件驱动会直接加载失败。5.3 吞吐量只能跑一半的嫌疑点WiFi连上了但iperf3测吞吐只有150Mbps左右而理论值应该奔着300Mbps去AP6256单流AC极限433Mbps。第一嫌疑就是SDIO没有跑在高带宽模式上。检查方法cat /sys/kernel/debug/mmc1/ios看里面的timing字段。如果是SD High-Speed50MHz而不是SD UHS SDR104那就确认是设备树里少了sd-uhs-sdr104。加上这个字段后重新编译设备树时序就会切到SDR104吞吐量立刻上来。另一个容易忽略的点是max-frequency。如果控制器不支持200MHz强行配置会导致信号不稳定逻辑上表现为吞吐忽高忽低而不是完全跑不动。我这边稳定跑在150MHz吞吐量完全可以跑满。5.4 连接后瞬间断流的电源纹波案例这是本期调试里最有意思的一个问题WiFi连接正常但只要一跑大流量几秒钟后必然断流dmesg里出现brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout。排查到最后问题出在WiFi模块的DC-DC电源上——大电流场景下纹波超标导致SDIO数据线信号质量劣化驱动层的重传机制被打崩。处理方式是让硬件工程师调整了DC-DC反馈回路的补偿电容同时在设备树里把max-frequency从200MHz降到150MHz双管齐下后问题彻底消失。6. 稳定性验证清单与个人心得6.1 量产前必做的几项验证BSP调试的终点不是wlan0出现、能连上网就结束了。量产项目需要做一轮系统性的稳定性验证我通常会按以下清单过一遍长时间连接测试连续ping外网网关8小时以上观察丢包率与延迟抖动重连测试通过ifconfig wlan0 down再up反复操作50次确认每次都能重新关联吞吐压测iperf3 -c server -t 120分别测2.4G和5G的TCP/UDP确认下行、上行吞吐都符合预期休眠唤醒测试系统进入suspend后再resume确认wlan0还能正常通信蓝牙功能完整性测试蓝牙耳机播放、BLE扫描、经典蓝牙文件传输三样都要跑。这些验证在调试阶段看似枯燥但如果你跳过等到客户端手里出问题再查成本会翻好几倍。6.2 一点关于BSP调试这件事的真话AP6256的调试经验放到全志T527上有一个方法论层面的心得BSP调试80%的时间不是在写代码而是在“对信息”。设备树引脚有没有对、内核配置有没有对、固件路径有没有对、上电时序有没有对这些对完之后驱动自己就能跑起来。剩下的20%才是真正的信号质量、共存性能这类硬件相关调优。我个人的习惯是每调一个模块就把所有涉及到的文件路径、关键寄存器值、实测参数记录下来形成一个板级配置表。这个表不仅对自己后续维护有用硬件工程师改版时也能直接参照。很多BSP问题之所以反复出现就是因为项目里没有一个清晰的配置记录全凭记忆在改。建议你也试试把这个习惯建立起来。