Title: i.MX95 19x19 EVK with JODY-W263-00B: WiFi firmware activation timeout on Android 15 / Linux 6.12.23
Hello NXP Team,
I am debugging WiFi initialization on the following setup:
Board: NXP i.MX95 19x19 EVK
WiFi module: u-blox JODY-W263-00B
Android build: AOSP 15 (Android property verification pending)
Running kernel: 6.12.23-android16-5-maybe-dirty-4k
Exact NXP Android BSP release/tag: not yet confirmed
WiFi driver: mlan/moal (MWLAN)
Selected firmware: sduart8987_combo.bin
SDIO device: mmc2:0001:1
Running kernel information:
The SDIO device is detected, and the driver reports “FW download over”. However, the firmware does not become active within the timeout, and the WiFi SDIO probe fails.
Relevant boo$ adb shell uname -a
Linux localhost 6.12.23-android16-5-maybe-dirty-4k #1 SMP PREEMPT Thu Jan 1 00:00:00 UTC 1970 aarch64 Toybox
t logs:
[ 10.845985] mlan: loading out-of-tree module taints kernel.
[ 10.961712] wlan: Loading MWLAN driver
[ 10.973277] wlan: Register to Bus Driver...
[ 11.016613] Attach moal handle ops, card interface type: 0x105
[ 11.070275] sta_name=wlan
[ 11.086277] uap_name=wlan
[ 11.086294] fw_name=sduart8987_combo.bin
[ 11.168031] Enable moal_recv_amsdu_packet
[ 11.168086] Attach mlan adapter operations.card_type is 0x105.
[ 11.257673] wlan: Enable TX SG mode
[ 11.257679] wlan: mpa_tx.buf_size=65280
[ 11.257682] wlan: Enable RX SG mode
[ 12.226020] Wlan: FW download over, firmwarelen=628200 downloaded 619156
[ 17.279039] FW failed to be active in time!
[ 17.286246] wlan_dnld_fw fail ret=0xffffffff
[ 17.296825] WLAN: Fail download FW with nowwait: 0
[ 17.502477] woal_request_fw failed
[ 17.537460] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1
[ 17.547534] wlan: Register to Bus Driver Done
[ 17.553159] wlan: Driver loaded successfullyAfter unloading and reloading the driver, I also observed:
[ 4051.080660] fw_name=sduart8987_combo.bin
[ 4051.159940] Wlan: FW download over, firmwarelen=628200 downloaded 0
[ 4056.079262] FW failed to be active in time!
[ 4056.084697] wlan_dnld_fw fail ret=0xffffffff
[ 4056.089909] WLAN: Fail download FW with nowwait: 0
[ 4056.250548] woal_request_fw failed
[ 4056.273119] wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1I found this related community discussion:
The discussion concerns 88W8801 on Nvidia AGX Orin, so it is a different module/platform. The author reported improvement after removing no-sd and changing bus-width from 4 to 1, followed by successful operation with the original configuration. I have not yet tested these changes on my board.
Could you please help clarify:
Is sduart8987_combo.bin the correct firmware for JODY-W263-00B? Which firmware release and mlan/moal driver revision are recommended for this Android/kernel combination?
What are the recommended SDIO device-tree settings for this module on the i.MX95 19x19 EVK, particularly bus width, maximum frequency, pinctrl, power supplies, reset GPIO, and power-sequence delays?
Would testing bus-width = <1> or a lower SDIO clock help diagnose this timeout? Is removing no-sd relevant or recommended for this platform?
What could cause the firmware activation timeout after the driver reports firmware download completion? Does downloaded 0 after driver reload indicate that a full module power cycle or hardware reset is needed before retrying?
Are there known issues or required patches for this board/module/kernel combination?
Which additional debug settings, SDIO register dumps, or logs should I collect to distinguish firmware/driver compatibility issues from SDIO communication or power/reset sequencing issues?
I can provide the full boot log, relevant device-tree nodes, wifi_mod_para.conf, and exact BSP/driver revisions once confirmed.
Thank you.
Hello NXP Team,
We have collected further diagnostic evidence for the firmware activation timeout on i.MX95 19x19 EVK with JODY-W263-00B.
Hardware mode verification
Both register reads succeed:
WIFI_DIAG: magic_reg=0xf0 magic_raw=0x24 read_ret=0
WIFI_DIAG: strap_reg=0xf4 strap_raw=0xd2 read_ret=0
WIFI_DIAG: magic=0x24 strap=0x0
WIFI_DIAG: explicit fw_name=sduart8987_combo.bin; skipping automatic selectionThe masked strap indicates SD-UART mode according to our driver source, consistent with the configured firmware name.
Download-loop exit confirmed
WIFI_DL_DIAG: exit=zero_request offset=619156 firmwarelen=628200 tries=100 max_tries=100
WIFI_DL_DIAG: base0_reg=0xf8 base0=0x0 base1_reg=0xf9 base1=0x0 last_txlen=16
Wlan: FW download over, firmwarelen=628200 downloaded 619156
Fail to poll firmware status: firmwarestat=0xf005
FW failed to be active in time!The requested-length registers remain zero throughout 100 polling attempts, causing the download loop to exit.
Firmware binary inspection
Using the source’s 16-byte FWHeader layout and command-length rules, offline parsing identifies a CMD4 record at offset 619140, ending at 619156—exactly matching the download counter. The source defines CMD4 as FW_HAS_LAST_BLOCK.
There are 9044 bytes after this record. We have not established their purpose or confirmed that these parsing rules fully describe the SDIO bootloader format. We therefore do not consider the counter difference alone proof of an incomplete download.
Additional details:
MOAL/MLAN version: 537.p9
Embedded firmware string: w8987o-V0, RF878X, FP92, 16.92.21.p151.4
Firmware size: 628200 bytes
SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34
Actual 1-bit SDIO operation was previously verified at 50 MHz, with the same timeout.
The latest diagnostic test runs at 4-bit, 50 MHz.
Expected firmware READY status is 0xfedc; observed status remains 0xf005.
No Wi-Fi network interface is created.
Exact NXP BSP release/tag is still being confirmed.
Could you please clarify:
Is stopping at the CMD4 boundary, offset 619156, expected for this specific image? What is the purpose of the remaining 9044 bytes?
What does 0xf005 indicate during SD8987 firmware activation?
Is firmware containing version string 16.92.21.p151.4 supported with driver 537.p9 for JODY-W263-00B? Which BSP and firmware/driver package should we use?
Which module power/reset timing, supply and reference-clock checks are recommended for this failure?
Which additional registers or diagnostics would distinguish a firmware startup failure from a communication or hardware initialization issue?
The firmware binary remains unchanged. Our source modifications add diagnostic logging, and full boot logs and source diffs are available.
Thank you.
One important clarification about the failure stage:
The processor detects the SD8987 Wi-Fi device over SDIO, and the firmware download routine reports “FW download over”. However, during the subsequent activation check, the driver expects SDIO_FIRMWARE_READY = 0xfedc, while the reported status is 0xf005.
Firmware initialization and the SDIO probe therefore fail, and no Wi-Fi network interface is created. This remains unchanged after verifying actual 1-bit SDIO operation at 50 MHz.
Could you please explain what 0xf005 indicates for SD8987 at this stage and which additional register values or logs would help identify why the firmware does not reach READY status?
Hello NXP Team,
Following up on my original report, we have completed additional checks and a controlled SDIO bus-width experiment. Wi-Fi initialization still fails at the firmware activation stage.
1. Confirmed device and software details
Board/module: i.MX95 19x19 EVK with JODY-W263-00B
Android fingerprint: Android/evk_95_car/evk_95:15/BP1A.250505.005/eng.nisar:userdebug/dev-keys
Kernel: 6.12.23-android16-5-maybe-dirty-4k
Exact NXP BSP release/tag: still being confirmed
SDIO device: mmc2:0001:1
SDIO ID: 02DF:9149, mapped to SD8987 in the driver source
Host controller: USDHC3, mmc@428b0000
Both moal and mlan report version 537.p9
MOAL srcversion: 358C14898F4DDF4EB40AB03
Source repository revisions:
nxp-mwifiex: 9630752ea1d9e28d9956adf27c652f40399e85ad
imx-firmware: 34faa4b3008bf9c6f814b5767cacbc3857cdc49b
Both commits have the subject “MA-23689-1 [Android-15]WCS Q2 release patch integrate”. Mapping these source revisions to the installed module build is still being verified.
2. Firmware identity verified
The selected firmware is /vendor/firmware/sduart8987_combo.bin, size 628200 bytes.
The source copy and installed board copy have the same SHA-256:
db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34This confirms that the copies match; firmware compatibility with the module still needs confirmation.
3. Actual 1-bit SDIO test completed
Initially, the live Device Tree reported bus-width = <1>, but /sys/kernel/debug/mmc2/ios still showed 4-bit operation.
In our source, mmc_of_parse() does not clear an existing 4-bit capability for bus-width = <1>, while generic SDHCI setup adds MMC_CAP_4_BIT_DATA unless SDHCI_QUIRK_FORCE_1_BIT_DATA is set.
We therefore added a diagnostic block in sdhci-esdhc-imx.c, immediately after the mmc_of_parse() error check:
{
u32 bus_width;
if (!of_property_read_u32(np, "bus-width", &bus_width) &&
bus_width == 1) {
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
host->mmc->caps &=
~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA);
}
}After rebuilding and deploying the modified kernel and DT configuration, we verified:
Live DT bus-width: 00 00 00 01
clock: 50000000 Hz
bus width: 0 (1 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)However, the same failure remained:
Request firmware: sduart8987_combo.bin
Wlan: FW download over, firmwarelen=628200 downloaded 619156
Fail to poll firmware status: firmwarestat=0xf005
FW failed to be active in time!
Firmware Init Failed
wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1No Wi-Fi network interface appears.
The configured maximum frequency is 100 MHz, but actual operation remained at 50 MHz. We have therefore not completed a lower-clock test. Also, no-sd was absent from the reviewed USDHC3 configuration, so no removal was performed.
4. WLAN-only firmware reload test
We temporarily bind-mounted sd8987_wlan.bin over the configured firmware path and reloaded MOAL. The driver read the alternative file size, but reported:
firmwarelen=416836 downloaded 0
firmwarestat=0xf005
FW failed to be active in time!Because this was a reload after an earlier failed initialization, we consider the result inconclusive. It does not establish WLAN-only firmware compatibility or successful transfer.
A reboot removed the temporary bind mount, and the original 628200-byte combo firmware was verified again.
5. Current investigation
We are preparing diagnostic logging in moal_sdio_mmc.c to capture:
Raw chip magic and host strap register values.
Return status of both register reads.
Masked magic and strap values.
The source defines CHIP_MAGIC_VALUE = 0x24 and CARD_TYPE_SD_UART = 0. The existing boot log did not expose these values. This logging change has not yet been deployed.
The exact meaning of firmwarestat=0xf005 and the repeated 9044-byte difference between firmware size and download counter remain unresolved. We are not treating the completion message as proof that firmware is active.
Could you please advise on the following?
Is this firmware/driver package appropriate for JODY-W263-00B on this BSP/kernel? How can we identify the exact firmware release from the binary or package?
Is downloaded 619156 for a 628200-byte combo image expected for this firmware format, or does it indicate premature termination?
What does firmware status 0xf005 mean for SD8987 during initialization?
Is the diagnostic host-driver change above appropriate for enforcing a 1-bit test, or is there a preferred BSP mechanism?
Which registers/logging should we collect to verify strap-based firmware selection, and does an explicit fw_name override that selection?
What power/reset sequence is required before retrying after this failure? Would you recommend a lower-clock test or another targeted experiment next?
We can provide the full boot logs, DT/overlay changes, host-driver diff, and wifi_mod_para.conf.
Thank you.
Dear @Rakesh_Kumar-Thakur ,
Thanks for your Inquiry.
I saw you are using uSDHC3 interface for your WiFi module, i.MX95-EVK supports the uSDHC3 on M.2 KEY E connector, so I assume you are using M.2 WiFi module, JODY-W263-00B based on 88W8987.
We need to clarify the following steps when enabling SDIO WiFi on M.2 KEY E connector.
-- uSDHC3 IO level is determined by NVCC_WAKEUP
NVCC_WAKEUP is 1.8V (from VDD_1V8_S).
--M.2 Power,VCC_KE_3V3 is disabled by default
The power is generated by NX5P2924DUK, M2_KE_PWREN is controlling it's enablement.
3. What software will do
(1) Adding uSDHC3 node to imx95-19x19-evk.dts
There is no uSDHC3 node by default, it should be added manually.
[Note]
You can refer to imx95-15x15-evk.dts's usdhc3 code to add it.
please pay attention to different GPIOs.
--Enabling power GPIO
--Pull up W_DISABLE1# and W_DISABLE2 pins of M.2
--SDIO_WAKE# & SDIO_RST# pins
(3)Android 15 SDIO WiFi Power Enablement
Check haredBoardConfig.mk files for i.MX95 and confirm if pwrseq_simple.ko has been supported, if not , add it, please. maybe like below:
......
$(KERNEL_OUT)/net/wireless/cfg80211.ko \
$(KERNEL_OUT)/drivers/mmc/core/pwrseq_simple.ko \
......
(3) Enabling imx95-19x19_gki.fragment (Maybe different name, confirm it , please.)
......
CONFIG_PWRSEQ_SIMPLE=m
......
(4) Disabling pcie1 node (in imx95-19x19-evk.dts)
......
&pcie1 {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
reset-gpio = <&i2c7_pcal6524 16 GPIO_ACTIVE_LOW>;
vpcie-supply = <®_slot_pwr>;
status = "disabled";
};
......
(5) BoardConfig.mk can support 8987 directly
You can change default WiFi firmware files' name to 88W8987's.
OK, try it, please.
Thanks,
Regards,
Weidong
Hi Weidong,
Thank you for your guidance.
I tested the following configuration updates, but firmware initialization still fails:
Disabled pcie1 in imx95-19x19-evk.dts. The existing uSDHC3 configuration was retained.
Updated the Wi-Fi configuration labels and module-parameter filename in BoardConfig.mk and SharedBoardConfig.mk.
Updated the firmware configuration destination name in evk_95.mk.
Found CONFIG_PWRSEQ_SIMPLE=m already present in the kernel fragments. Runtime loading of pwrseq_simple.ko and the DTS power-sequence connection still need verification.
The latest boot uses:
moal.mod_para=wifi_mod_para_sd8987.confThe module is reported as JODY-W263-00B, based on NXP 88W8987, and the Wi-Fi driver version is 537.p9.
Current firmware:
Path: /vendor/firmware/sduart8987_combo.bin
Size: 628200 bytes
SHA-256: db9e2ef58aba5778cddd7b7fbc84a34884bebef076052186e8b0d036e68d9f34Boot logs:
SD8987: init module param from usr cfg
card_type: SD8987, config block: 0
fw_name=sduart8987_combo.bin
Request firmware: sduart8987_combo.bin
Wlan: FW download over, firmwarelen=628200 downloaded 619156
Fail to poll firmware status: firmwarestat=0xf005
FW failed to be active in time!
Firmware Init Failed
wlan_sdio mmc2:0001:1: probe with driver wlan_sdio failed with error -1Previously, I also tested a replacement firmware from branch lf-6.18.20_2.0.0:
Size: 644352 bytes
SHA-256: ccaff1bc0a0232fb59111bb01f27cd28ba985d9a0bcb79beca61cde5e67ca823Its deployed hash was verified, but it produced the same firmwarestat=0xf005 activation failure.
Could you please provide or point me to a validated sduart8987_combo.bin for JODY-W263-00B / 88W8987 compatible with driver 537.p9? Please include the firmware version, repository commit/tag, SHA-256 and recommended module parameters. If another driver release is required, please specify the matching driver–firmware pair.
For reference, our source revisions are:
Driver: 9630752ea1d9e28d9956adf27c652f40399e85ad
Original firmware repository: 34faa4b3008bf9c6f814b5767cacbc3857cdc49bPlease also advise what 0xf005 indicates and which additional status-register captures or power/reset checks would help identify the cause. Electrical measurements and complete reset-sequence verification are still pending.
Regards,
Rakesh
Dear @Rakesh_Kumar-Thakur ,
Thanks for your update.
>>Regarding 0xf005
code 0xf005 means that the driver did not observe the firmware reaching the Ready/Active state within the polling timeout. It is a firmware activation status, not a specific hardware-fault code. However, hardware issues such as SDIO communication, power, reset, or clock problems may still cause this status.
>>Regarding switching to the lf-6.18.20_2.0.0 branch:
The correct approach is to use the complete, matching Wi-Fi driver and firmware from that branch. We should not replace only the firmware, because the driver and firmware versions must be compatible and kept in sync.
So you can try to update Wi-Fi driver & firmware to the latest branch.
I have one question and one suggestion:
-
Do you have to use Android 15? Since the i.MX95 is relatively new, it would be better to use the latest BSP version. You could use Android 16.0.0_2.0.0 with the L6.18.20_2.0.0 BSP.
-
I suggest first verifying the Wi-Fi hardware, driver, and firmware on the Linux BSP. Once the Wi-Fi module works properly on Linux, you can migrate the solution to Android 16. This approach can reduce the complexity of Android-specific configuration and make debugging more efficient.
Thanks,
Regards,
Weidong