前言在嵌入式Linux项目中把WiFi模组切换为AP模式是个常见需求——配网、调试、本地组网都离不开它。但AP6256这颗模组在AP模式下踩坑的概率远比STA模式高得多。今天基于 RK3588 平台搭配 AP6256模块给大家分享一份超实用、可直接落地的内核级 WiFi 调试笔记。一、故障环境1.1开发环境• 主控平台RK3588• WiFi 芯片AP6256BCM43456• 内核版本Linux 5.10• 文件系统Ubuntu 20.04• 通信接口SDIO1.2问题表现你可能遇到过这些场景• hostapd启动后手机死活搜不到热点• 搜到了热点输入密码却反复提示正在连接• 好不容易连上了几秒后自动断开周而复始• 日志里一堆看不懂的报错rsn_cap_value error、Match already configured、ctrl_iface exists...这类故障在量产设备中极其常见掉电重启一切正常软件重启 / 驱动重载就 “瘸腿”隐蔽性强、定位难度高。本文帮助大家解决不掉电软重启后 AP 模式无法创建、但 STA 模式正常的隐蔽问题。1.3根因分析对比正常 / 异常两种场景的驱动日志找到了最关键的差异点MAC 地址来源不同。正常的情况下wifi模块加载后的MAC地址是读取自身的MAC地址不正常的情况下wifi在加载驱动时是通过加载nvram_ap6256.txt文件中定义的mac地址。如下图所示图1 nvram_ap6256.txt图2 异常状态下的wifi驱动加载信息.log图3 正常状态下的wifi驱动加载信息.log二、解决方案2.1核心原理AP6256的无线功能依赖bcmdhd驱动。如果驱动没起来后面所有配置都是空中楼阁。由于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 { //wifi max-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; };查询博通官方手册明确规定在不掉电的情况下重新加载需要把WL_REG_ON下拉至少200ms。图4 WL_REG_ON 复位时序说明如果复位时间不足STA 模式只需要基础初始化能正常用AP 模式需要完整射频 模式配置直接失效这就是 “STA 好、AP 坏” 的本质原因。2.2踩坑实录第一时间在设备树sdio_pwrseq节点配置了 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 要求。跟踪内核drivers/mmc/core/pwrseq_simple.c后问题暴露①系统冷上电会依次执行mmc_pwrseq_simple_pre_power_on mmc_pwrseq_simple_post_power_on②驱动重载 / 软重启只执行 pre_power_on完全不执行 post_power_on而post-power-on-delay-ms这个设备树属性只在 post_power_on 函数里生效。所以无论设多少都不会被调用。2.3最终处理解决方案也非常直接把延时逻辑移到 pre_power_on 里。修改mmc_pwrseq_simple_pre_power_on函数添加延迟的代码static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host) { struct mmc_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); }三、调试总结该问题在RK3568/RK3588 AP6256/AP6275系列方案中高度通用建议直接收藏遇到同类 WiFi AP 故障可直接套用。如果按照本文的顺序排查90%的AP模式异常都能定位到根因。剩下的10%通常是硬件层面的射频干扰或供电不稳那就需要示波器和频谱仪上场了。关注眺望电子公众号获取更多嵌入式Linux调试实战经验
RK3588+AP6256｜不掉电重启AP模式踩坑调试实录
发布时间：2026/5/16 13:03:10
前言在嵌入式Linux项目中把WiFi模组切换为AP模式是个常见需求——配网、调试、本地组网都离不开它。但AP6256这颗模组在AP模式下踩坑的概率远比STA模式高得多。今天基于 RK3588 平台搭配 AP6256模块给大家分享一份超实用、可直接落地的内核级 WiFi 调试笔记。一、故障环境1.1开发环境• 主控平台RK3588• WiFi 芯片AP6256BCM43456• 内核版本Linux 5.10• 文件系统Ubuntu 20.04• 通信接口SDIO1.2问题表现你可能遇到过这些场景• hostapd启动后手机死活搜不到热点• 搜到了热点输入密码却反复提示正在连接• 好不容易连上了几秒后自动断开周而复始• 日志里一堆看不懂的报错rsn_cap_value error、Match already configured、ctrl_iface exists...这类故障在量产设备中极其常见掉电重启一切正常软件重启 / 驱动重载就 “瘸腿”隐蔽性强、定位难度高。本文帮助大家解决不掉电软重启后 AP 模式无法创建、但 STA 模式正常的隐蔽问题。1.3根因分析对比正常 / 异常两种场景的驱动日志找到了最关键的差异点MAC 地址来源不同。正常的情况下wifi模块加载后的MAC地址是读取自身的MAC地址不正常的情况下wifi在加载驱动时是通过加载nvram_ap6256.txt文件中定义的mac地址。如下图所示图1 nvram_ap6256.txt图2 异常状态下的wifi驱动加载信息.log图3 正常状态下的wifi驱动加载信息.log二、解决方案2.1核心原理AP6256的无线功能依赖bcmdhd驱动。如果驱动没起来后面所有配置都是空中楼阁。由于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 { //wifi max-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; };查询博通官方手册明确规定在不掉电的情况下重新加载需要把WL_REG_ON下拉至少200ms。图4 WL_REG_ON 复位时序说明如果复位时间不足STA 模式只需要基础初始化能正常用AP 模式需要完整射频 模式配置直接失效这就是 “STA 好、AP 坏” 的本质原因。2.2踩坑实录第一时间在设备树sdio_pwrseq节点配置了 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 要求。跟踪内核drivers/mmc/core/pwrseq_simple.c后问题暴露①系统冷上电会依次执行mmc_pwrseq_simple_pre_power_on mmc_pwrseq_simple_post_power_on②驱动重载 / 软重启只执行 pre_power_on完全不执行 post_power_on而post-power-on-delay-ms这个设备树属性只在 post_power_on 函数里生效。所以无论设多少都不会被调用。2.3最终处理解决方案也非常直接把延时逻辑移到 pre_power_on 里。修改mmc_pwrseq_simple_pre_power_on函数添加延迟的代码static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host) { struct mmc_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); }三、调试总结该问题在RK3568/RK3588 AP6256/AP6275系列方案中高度通用建议直接收藏遇到同类 WiFi AP 故障可直接套用。如果按照本文的顺序排查90%的AP模式异常都能定位到根因。剩下的10%通常是硬件层面的射频干扰或供电不稳那就需要示波器和频谱仪上场了。关注眺望电子公众号获取更多嵌入式Linux调试实战经验
