SD9098 "abnormal driver state"

[ddebaun]

I am running an 88Q9098 and am testing that one MAC can run in AP mode while the other MAC runs simultaneous AP/STA mode. I am using an iMX6ULL EVK as the host and am running Wi-Fi via SDIO and Bluetooth via UART. 

Driver version: SD9098----17.92.1.p98.1-MM5X17299.p1-GPL-(FP92)

Kernel Version: 5.10.93

My tests involve switching the STA connection to a new network, updating the hostapd configurations according to the proper bands (e.g. keeping uap0 and mlan0 on the same band, muap0 on opposite band), and restarting those hostapd services. Occasionally, I am seeing an "abnormal driver state" occur which seems to render any further Wi-Fi scanning or operations impossible. It only seems to be recoverable with a hard reboot.

I have attached a log with the contents of the dump that occurs. Please let me know what further information I can provide to help get this resolved.

I think this might be related to some of the issues in this ticket:

https://community.nxp.com/t5/Wireless-Connectivity/88Q9098-Configuration-Issues-for-Dual-MAC-Operati...

My setup and objectives are essentially the same as in that posting.

Thank you!

[weidong_sun]

Hello @ddebaun ,

The above configurations should be no problem.

then confirm what is SDIO IO level between CPU sdie and 9098 side? 1.8V or 3.3V?

Regards,

weidong

[jrhaws]

@weidong_sun 

SDIO signal levels on our custom board are 1.8V and we leave out the no-1-8-v device tree option.

When working with the EVKs, we are 3.3V, thus we have the no-1-8-v device tree option in the usdhc block.

Does that sound right?

[weidong_sun]

Dear @jrhaws ,

>>When working with the EVKs, we are 3.3V, thus we have the no-1-8-v device tree option in the usdhc block.
i.MX6ULL USDHC IO level is 3.3V, and WiFi SDIO IO Level is 1.8V.

so IO level is not matched, which caused wifi can't normally work.

See i.mx6ull som schematic, please!

In order to match IO level, you do like below:

we can remove SD_VSELECT and iomux GPIO1_IO05 to be GPIO, and control the GPIO output HIGH.

pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059

/*remove or comment the line, please!*/
MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059 /* SD1 CD */
MX6UL_PAD_GPIO1_IO05__USDHC1_VSELECT 0x17059 /* SD1 VSELECT */
MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x17059 /* SD1 RESET */
>;
};

Then add it to iomux node as a gpio.

&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog>;
pinctrl_hog: hoggrp {
fsl,pins = <
/* mux GPIO1_IO05 as gpio*/
MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x1A020
>;
};

After system boots, you can measure NVCC_SD's voltage. if it is 1.8V, OK, continue to check wifi. if it is still 3.3V,  you can control the GPIO output HIGH on linux command line, then output should be 1.8V.

Regards,

weidong

[jrhaws]

@weidong_sun 

So now I'm confused. Per this other issue I posted about, you told me that I needed to add the no-1-8-v to the device tree for the EVK and that I only would need to mess with the GPIO lines to increase performance.

https://community.nxp.com/t5/Wireless-Connectivity/88Q9098-88W8987-connectivity-problems-with-statio...

Is that not still the case? I had thought that on the iMX6ULL EVK, the SD interface was 3.3V natively, which is why we added the no-1-8-v option; but we could switch to 1.8V if we wanted to increase performance.

Based on that information, we've been running the EVK with that option. However, since our custom board has the SDIO lines operating at 1.8V, we took the no-1-8-v option out.

The issue @ddebaun is posting about here is happening on the EVK setup, with the no-1-8-v option in place. The issue in my other post (https://community.nxp.com/t5/Wireless-Connectivity/88Q9098-Configuration-Issues-for-Dual-MAC-Operati...) is present on both the EVK and our custom hardware.

Is that not the correct setup?

Right now, we are not concerned about performance - we are concerned about stability.

--

You are correct - that other ticket you commented on is very much related and the same project. 

[weidong_sun]

Hello @jrhaws ，

 no-1-8-v is added to usdhc node in dts, which is no problem.

But we should pay attention to the poiont.  Adding no-1-8-v means that usdhc will work at sdio2.0 mode.

the max frequency is 50MHz. 

After adding  no-1-8-v,  we can do some test, connection to internet , throughput etc. if these operations are no problem, we consider improving performance.

--------------------------------------

1. Removing  no-1-8-v from usdhc node in dts.

We will use sdio 3.0.

2. On hardware, we should ensure the IO LEVEL of usdhc on cpu side & sdio on 88Q9098 side is 1.8V.

1.8V io level between CPU and wifi must used for SDIO 3.0.

--------------------------------------

So please check if above 2 items are ok in your system.

Have a good day!

Regards,

weidong

[jrhaws]

@weidong_sun 

I will certainly check this, but I still am not seeing how this will resolve the issue. If we are operating at a lower frequency (50 MHz instead of 100 MHz or 200 MHz) that just means that we won't have as fast of Wi-Fi performance, correct? Or is there something else going on here?

I would think that if the driver was working properly, it would operate the same at 50 MHz as 100 MHz or 200 MHz, except for the performance numbers being a bit lower. Is that not the case?

Again - per the other open issue, I see this same problem on our custom hardware where the IO lines are at 1.8V and this has been verified by the hardware engineers. That tells me it is more a driver problem than a hardware configuration problem.

[weidong_sun]

Hello @jrhaws ,

>>If we are operating at a lower frequency (50 MHz instead of 100 MHz or 200 MHz) that just means that we won't have as fast of Wi-Fi performance, correct? 

Yes, right.

>>I would think that if the driver was working properly, it would operate the same at 50 MHz as 100 MHz or 200 MHz, except for the performance numbers being a bit lower. Is that not the case?

Yes, right.

>>I see this same problem on our custom hardware where the IO lines are at 1.8V and this has been verified by the hardware engineers. That tells me it is more a driver problem than a hardware configuration problem.

OK, It means that the IO level of both sides are matched, that is 1.8V.

>>about clock speed of i.MX6ULL USDHC

due to hardware limitation, usdhc clock is limited not more than 132MHz.

I will continue to check the issues you encounterred.

Regards,

weidong

[ddebaun]

Hi @weidong_sun, I'd like to follow up and see if you have found anything further on this issue? We continue to see the same problems in our testing.

Thanks!

Dave

cc: @jrhaws 

[jrhaws]

It seems that this is related to the low power modes of the device. Thanks to @achyut_hegde for pointing out this as something to try.

By setting the ps_mode and auto_ds settings to 2 instead of 1 in the wifi_mod_para.conf file, this effectively disabled all low power modes, and we have not seen this issue since.

SD9098_0 = {
cfg80211_wext=0xf
max_vir_bss=1
cal_data_cfg=none
ps_mode=2
auto_ds=2
host_mlme=1
fw_name=nxp/sdiouart9098_combo_v1.bin
}

SD9098_1 = {
cfg80211_wext=0xf
max_vir_bss=1
cal_data_cfg=none
ps_mode=2
auto_ds=2
host_mlme=1
fw_name=nxp/sdiouart9098_combo_v1.bin
}

If it resurfaces due to other configurations or anything else, we'll post back here.

Thanks for the support!

[weidong_sun]

Dear @ddebaun ,

Did you add parameter 'host_mlme=1'  when loading 9098 wifi driver?

if not, add it and try.

Regards,

weidong

[jrhaws]

@weidong_sun

Here is the configuration being loaded:

SD9098_0 = {
cfg80211_wext=0xf
max_vir_bss=1
cal_data_cfg=none
ps_mode=1
auto_ds=1
host_mlme=1
fw_name=nxp/sdiouart9098_combo_v1.bin
}

SD9098_1 = {
cfg80211_wext=0xf
max_vir_bss=1
cal_data_cfg=none
ps_mode=1
auto_ds=1
host_mlme=1
fw_name=nxp/sdiouart9098_combo_v1.bin
}

host_mlme=1 is already being set.