前言：

在嵌入式Linux項目中，把WiFi模組切換為AP模式是個常見需求——配網(wǎng)、調(diào)試、本地組網(wǎng)都離不開它。但AP6256這顆模組在AP模式下踩坑的概率，遠比STA模式高得多。今天基于 RK3588 平臺搭配 AP6256模塊，給大家分享一份超實用、可直接落地的內(nèi)核級 WiFi 調(diào)試筆記。

一、故障環(huán)境

1.1開發(fā)環(huán)境

?主控平臺：RK3588

?WiFi 芯片：AP6256（BCM43456）

?內(nèi)核版本：Linux 5.10

?文件系統(tǒng)：Ubuntu 20.04

?通信接口：SDIO

1.2問題表現(xiàn)

你可能遇到過這些場景：

?hostapd啟動后，手機死活搜不到熱點

?搜到了熱點，輸入密碼卻反復提示"正在連接"

?好不容易連上了，幾秒后自動斷開，周而復始

?日志里一堆看不懂的報錯：rsn_cap_value error、Match already configured、ctrl_iface exists...

這類故障在量產(chǎn)設備中極其常見：掉電重啟一切正常，軟件重啟 / 驅(qū)動重載就 “瘸腿”，隱蔽性強、定位難度高。本文幫助大家解決不掉電軟重啟后 AP 模式無法創(chuàng)建、但 STA 模式正常的隱蔽問題。

1.3根因分析

對比正常 / 異常兩種場景的驅(qū)動日志，找到了最關鍵的差異點：MAC 地址來源不同。

正常的情況下，wifi模塊加載后的MAC地址是讀取自身的MAC地址；

不正常的情況下，wifi在加載驅(qū)動時是通過加載nvram_ap6256.txt文件中定義的mac地址。

如下圖所示：

圖1 nvram_ap6256.txt

圖2 異常狀態(tài)下的wifi驅(qū)動加載信息.log

圖3 正常狀態(tài)下的wifi驅(qū)動加載信息.log

二、解決方案

2.1核心原理

AP6256的無線功能依賴bcmdhd驅(qū)動。如果驅(qū)動沒起來，后面所有配置都是空中樓閣。由于wifi模塊是以SDIO的通信的，相關的配置如下：

sdio_pwrseq: sdio-pwrseq {compatible ="mmc-pwrseq-simple";pinctrl-names ="default";pinctrl-0= <&wifi_enable_h>;/* * On the module itself this is one of these (depending * on the actual card populated): * - SDIO_RESET_L_WL_REG_ON * - PDN (power down when low) */post-power-on-delay-ms = <200>;reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;};wireless_wlan: wireless-wlan {compatible ="wlan-platdata";wifi_chip_type ="ap6256";pinctrl-names ="default";pinctrl-0= <&wifi_host_wake_irq>;WIFI,host_wake_irq = <&gpio1 RK_PD6 GPIO_ACTIVE_HIGH>;status ="okay";};&sdmmc {//wifimax-frequency = <150000000>;supports-sdio;bus-width = <4>;disable-wp;cap-sd-highspeed;cap-sdio-irq;keep-power-in-suspend;pinctrl-names ="default";pinctrl-0= <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_det>;//sd-uhs-sdr104;mmc-pwrseq = <&sdio_pwrseq>;non-removable;status ="okay";};

查詢博通官方手冊明確規(guī)定，在不掉電的情況下重新加載，需要把WL_REG_ON下拉至少200ms。

圖4 WL_REG_ON 復位時序說明

如果復位時間不足：

STA 模式：只需要基礎初始化，能正常用

AP 模式：需要完整射頻 + 模式配置，直接失效

這就是 “STA 好、AP 壞” 的本質(zhì)原因。

2.2踩坑實錄

第一時間在設備樹sdio_pwrseq節(jié)點配置了 200ms 延時：

sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&wifi_enable_h>; post-power-on-delay-ms = <200>; // 這里我以為會生效 reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;};

結果：完全不生效！

實際測量 GPIO 波形，不管設置為什么值，下拉時間永遠只有20ms，遠達不到 200ms 要求。

跟蹤內(nèi)核drivers/mmc/core/pwrseq_simple.c后，問題暴露：

①系統(tǒng)冷上電會依次執(zhí)行：

mmc_pwrseq_simple_pre_power_onmmc_pwrseq_simple_post_power_on

②驅(qū)動重載 / 軟重啟

只執(zhí)行 pre_power_on，完全不執(zhí)行 post_power_on

而post-power-on-delay-ms這個設備樹屬性，只在 post_power_on 函數(shù)里生效。所以無論設多少，都不會被調(diào)用。

2.3最終處理

解決方案也非常直接：把延時邏輯移到 pre_power_on 里。

修改mmc_pwrseq_simple_pre_power_on函數(shù)，添加延遲的代碼：

staticvoidmmc_pwrseq_simple_pre_power_on(structmmc_host *host){structmmc_pwrseq_simple *pwrseq = to_pwrseq_simple(host->pwrseq);if(!IS_ERR(pwrseq->ext_clk) && !pwrseq->clk_enabled) {clk_prepare_enable(pwrseq->ext_clk);pwrseq->clk_enabled =true;}mmc_pwrseq_simple_set_gpios_value(pwrseq,1);+if(pwrseq->post_power_on_delay_ms)+msleep(pwrseq->post_power_on_delay_ms);}

三、調(diào)試總結

該問題在RK3568/RK3588 + AP6256/AP6275系列方案中高度通用，建議直接收藏，遇到同類 WiFi AP 故障可直接套用。

如果按照本文的順序排查，90%的AP模式異常都能定位到根因。剩下的10%，通常是硬件層面的射頻干擾或供電不穩(wěn)，那就需要示波器和頻譜儀上場了。

關注眺望電子公眾號，獲取更多嵌入式Linux調(diào)試實戰(zhàn)經(jīng)驗！