Platform: sabre-lite imx6 Q board
Kernel: 3.0.35
Wifi chipset: Marvell SD8787 based wifi module
wifi driver : mwifiex
We are facing an issue in Wi-Fi bring-up on 3.0.35 kernel. The Wi-Fi module connected to sabre-lite board through SDIO interface.
The driver is able to load the firmware. But if we try to a data transfer the driver crashes with following message.
root@freescale /$ dhclient mlan0
Internet Systems Consortium DHCP Client V3.0.3b1
Copyright 2004-2005 Internet Systems Consortium.
Listening on Socket/eth0
Sending on Socket/eth0
Listening on Socket/mlan0
Sending on Socket/mlan0
Sending on Socket/fallback
DHCPDISCOVER on mlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on mlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id (97.892473) = 0xce, act = 0x1c8c
mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0
mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0
mwifiex_sdio mmc1:0001:1: num_cmd_timeout = 1
mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0
mwifiex_sdio mmc1:0001:1: last_cmd_index = 3
mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 2
mwifiex_sdio mmc1:0001:1: last_event_index = 4
mwifiex_sdio mmc1:0001:1: data_sent=0 cmd_sent=1
mwifiex_sdio mmc1:0001:1: ps_mode=1 ps_state=0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on mlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
Further looking into the issue, I have found a patch for "eSDHC misses SDIO interrupt when CINT is disabled" for imx processors.
https://patchwork.kernel.org/patch/2446091/
Does this patch is applicable to imx6 processors? If yes, do you have a patch for 3.0.35 kernel?
Thanks in advance,
Krishnan.
According to the /drivers/mmc/host/sdhci-esdhc-imx.c file in the imx6Q kernel, this patch should not be applied since that problem should not occur in i.mx6. Look here:
But just to double check, have you tried probing the SDIO DAT1 pin to see if it stays low until the card is reset? If this is the case, then the interrupt is not being serviced.
Also, according to this:
Linux/drivers/net/wireless/mwifiex/fw.h - Linux Cross Reference - Free Electrons
Timeout cmd id (97.892473) = 0xce, corresponds to the command HostCmd_CMD_11N_ADDBA_REQ, which is a Block Acknowledgement request cmd. This is an 802.11n feature (Block acknowledgement - Wikipedia, the free encyclopedia). Its possible that the mwifiex driver you are could be out of date. It is at least 2 yrs old according to here:linux-imx6/drivers/net/wireless/mwifiex at boundary-imx_3.0.35_4.0.0 · boundarydevices/linux-imx6 · .... So would suggest updating this to a later version from the mainline linux kernel. You may not be able to do this because of other incompatibilities with the 3.0.35 kernel. So another approach is to load the 3.9 kernel for the sabrelite by following these instructions:i.MX6x SABRE Lite - Linux on ARM - eewiki and seeing if the problem persists.
Also, there is an updated firmware file for the 8787 chipset. Have you given this a try?: kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel. My guess is this fimrware will work with the latest 3.9 kernel.
Also to glean some more info (from here:RE: [PROBLEM] linux-3.2.7:mwifiex:when associating with ap ,there are some strange warning (Linux Wi...):
In kernel .config file (or through menuconfig):
CONFIG_DYNAMIC_DEBUG=y
Re-compile the whole kernel tree, install and reboot. Before running wpa_supplicant, turn on debug:
mkdir /tmp/debug
mount -t debugfs debugfs /tmp/debug
echo "module mwifiex +p" > /tmp/debug/dynamic_debug/control
echo "module mwifiex_sdio +p" > /tmp/debug/dynamic_debug/control
cat /tmp/debug/mwifiex/mlan0/info
After command timeout happens,
cat /tmp/debug/mwifiex/mlan0/debug
Here is some debug info that the driver spits out: Linux/drivers/net/wireless/mwifiex/README - Linux Cross Reference - Free Electrons
Hello varsmolta,
Thank you for the help.
The SDIO DAT1 line has been probed and that is toggling so we can rule out the interrupt related patch. I have enabled the debug option in kernel and
captured the debug info pls see the logs below.
Bringing up the new kernel may take some time so I kept that option to last one to try.
Meanwhile I have tried another sdio based wifi module on the board. This driver also giving same kind of issue.
The Wi-Fi driver was working with a different arm platform. This lead me to suspect sdio driver in host. What are the issues identified with sdio driver for i.MX6 ?
Did any one used SDIO based wifi module on an i.MX6 platform?
I want to close this doubt before switching to higher version of kernel..
Appreciate your help.
------------------
Logs
-------------------
After the association with AP
-----------------------------
root@freescale ~$ cat /tmp/debug/mwifiex/mlan0/info
driver_name = "mwifiex"
driver_version = mwifiex 1.0 (14.66.9.p96)
verext = w8787-Ax, RF878X, FP66, 14.66.9.p96, BT_SDIO
interface_name="mlan0"
bss_mode="Ad-hoc"
media_state="Connected"
mac_address="4c:aa:16:c2:0f:ca"
multicast_count="1"
essid="dlink"
bssid="1c:7e:e5:58:77:2b"
channel="6"
region_code = "10"
multicast_address[0]="01:00:5e:00:00:01"
num_tx_bytes = 0
num_rx_bytes = 0
num_tx_pkts = 0
num_rx_pkts = 0
num_tx_pkts_dropped = 0
num_rx_pkts_dropped = 0
num_tx_pkts_err = 0
num_rx_pkts_err = 0
carrier on
tx queue started
root@freescale ~$ cat /tmp/debug/mwifiex/mlan0/info
driver_name = "mwifiex"
driver_version = mwifiex 1.0 (14.66.9.p96)
verext = w8787-Ax, RF878X, FP66, 14.66.9.p96, BT_SDIO
interface_name="mlan0"
bss_mode="Ad-hoc"
media_state="Connected"
mac_address="4c:aa:16:c2:0f:ca"
multicast_count="1"
essid="dlink"
bssid="1c:7e:e5:58:77:2b"
channel="6"
region_code = "10"
multicast_address[0]="01:00:5e:00:00:01"
num_tx_bytes = 0
num_rx_bytes = 0
num_tx_pkts = 0
num_rx_pkts = 0
num_tx_pkts_dropped = 0
num_rx_pkts_dropped = 0
num_tx_pkts_err = 0
num_rx_pkts_err = 0
carrier on
tx queue started
root@freescale ~$ cat /tmp/debug/mwifiex/mlan0/debug
int_counter=0x0
wmm_ac_vo=0x0
wmm_ac_vi=0x0
wmm_ac_be=0x0
wmm_ac_bk=0x0
max_tx_buf_size=0x800
tx_buf_size=0x700
curr_tx_buf_size=0x0
ps_mode=0x1
ps_state=0x3
is_deep_sleep=0x1
wakeup_dev_req=0x1
wakeup_tries=0x0
hs_configured=0x0
hs_activated=0x0
num_tx_timeout=0x0
num_cmd_timeout=0x0
timeout_cmd_id=0x0
timeout_cmd_act=0x0
last_cmd_id=0x6 0x12 0xe4 0x71 0x28
last_cmd_act=0x3 0x7e1c 0xff 0x0 0x113
last_cmd_index=0x3
last_cmd_resp_id=0x8006 0x8012 0x80e4 0x8071 0x8028
last_cmd_resp_index=0x3
last_event=0x17 0x2b 0xa 0xb 0xa
last_event_index=0x3
num_cmd_h2c_fail=0x0
num_cmd_sleep_cfm_fail=0x0
num_tx_h2c_fail=0x0
num_evt_deauth=0x0
num_evt_disassoc=0x0
num_evt_link_lost=0x0
num_cmd_deauth=0x0
num_cmd_assoc_ok=0x1
num_cmd_assoc_fail=0x0
cmd_sent=0x0
data_sent=0x0
cmd_resp_received=0x0
event_received=0x0
cmd_pending=0x0
tx_pending=0x0
rx_pending=0x0
root@freescale ~$ cat /tmp/debug/mwifiex/mlan0/debug
int_counter=0x0
wmm_ac_vo=0x0
wmm_ac_vi=0x0
wmm_ac_be=0x0
wmm_ac_bk=0x0
max_tx_buf_size=0x800
tx_buf_size=0x700
curr_tx_buf_size=0x0
ps_mode=0x1
ps_state=0x3
is_deep_sleep=0x1
wakeup_dev_req=0x1
wakeup_tries=0x0
hs_configured=0x0
hs_activated=0x0
num_tx_timeout=0x0
num_cmd_timeout=0x0
timeout_cmd_id=0x0
timeout_cmd_act=0x0
last_cmd_id=0x6 0x12 0xe4 0x71 0x28
last_cmd_act=0x3 0x7e1c 0xff 0x0 0x113
last_cmd_index=0x3
last_cmd_resp_id=0x8006 0x8012 0x80e4 0x8071 0x8028
last_cmd_resp_index=0x3
last_event=0x17 0x2b 0xa 0xb 0xb
last_event_index=0x4
num_cmd_h2c_fail=0x0
num_cmd_sleep_cfm_fail=0x0
num_tx_h2c_fail=0x0
num_evt_deauth=0x0
num_evt_disassoc=0x0
num_evt_link_lost=0x0
num_cmd_deauth=0x0
num_cmd_assoc_ok=0x1
num_cmd_assoc_fail=0x0
cmd_sent=0x0
data_sent=0x0
cmd_resp_received=0x0
event_received=0x0
cmd_pending=0x0
tx_pending=0x0
rx_pending=0x0
After the ping command
-------------------------
root@freescale ~$ cat /tmp/debug/mwifiex/mlan0/debug
int_counter=0x0
wmm_ac_vo=0x0
wmm_ac_vi=0x0
wmm_ac_be=0x0
wmm_ac_bk=0xf
max_tx_buf_size=0x800
tx_buf_size=0x700
curr_tx_buf_size=0x0
ps_mode=0x1
ps_state=0x0
is_deep_sleep=0x1
wakeup_dev_req=0x0
wakeup_tries=0x0
hs_configured=0x0
hs_activated=0x0
num_tx_timeout=0x0
num_cmd_timeout=0x1
timeout_cmd_id=0xce
timeout_cmd_act=0x1c00
last_cmd_id=0x6 0x12 0xe4 0x71 0xce
last_cmd_act=0x3 0x7e1c 0xff 0x0 0x1c00
last_cmd_index=0x4
last_cmd_resp_id=0x8006 0x8012 0x80e4 0x8071 0x8028
last_cmd_resp_index=0x3
last_event=0xb 0xb 0xb 0xb 0xa
last_event_index=0x4
num_cmd_h2c_fail=0x0
num_cmd_sleep_cfm_fail=0x0
num_tx_h2c_fail=0x0
num_evt_deauth=0x0
num_evt_disassoc=0x0
num_evt_link_lost=0x0
num_cmd_deauth=0x0
num_cmd_assoc_ok=0x1
num_cmd_assoc_fail=0x0
cmd_sent=0x1
data_sent=0x1
cmd_resp_received=0x0
event_received=0x0
cmd_pending=0x0
tx_pending=0x21
rx_pending=0x0
Tx BA stream table:
tid = 0, ra = 1c:7e:e5:58:7
I tried with AzureWare NH-387 module which is also Marvell SD8787 based wireless module on iMX6 sabresd board.
It does work.Fortunately I got marvell newer driver 14.66.35.p16. Both sta and uap work on iMX6 android platform.
hi Raymond Wang:
I will move SD8787 to imx6dq(kernel 3.10.53,android 5.0),following your suggestion, I found some fucntion doest'n match,can you give me how to midify it,looking forward your help
Hi varsmolta & raymond
Thanks a bunch for your help.
I have taken mwifiex driver in 3.2.39 kernel to 3.0.35 kernel and now device working fine in Adapter mode. This proves that no issue on processor interface side.
Now I need to enable uAP support on 3.0.35?
I have checked out 3.10 kernel and analyzed the changes with 3.0.35. Looks like a lot of changes happened in mainline.
Can you suggest a starting point where I can start down porting ? A of list of changes will help me...
I'd like to share my driver porting on iMX6 android 4.2.2 with you.
1. my wireless relevant code on BoardConfig.mk:
TARGET_KERNEL_MODULES := \
kernel_imx/net/wireless/cfg80211.ko:system/lib/modules/cfg80211.ko
BOARD_WPA_SUPPLICANT_DRIVER := NL80211
WPA_SUPPLICANT_VERSION := VER_0_8_X
BOARD_WPA_SUPPLICANT_PRIVATE_LIB := lib_driver_cmd_mrvl8787
BOARD_HOSTAPD_DRIVER := NL80211
BOARD_HOSTAPD_PRIVATE_LIB := lib_driver_cmd_mrvl8787
BOARD_WLAN_DEVICE := mrvl8787
BOARD_WLAN_VENDOR := MRVL
WIFI_SDIO_IF_DRIVER_MODULE_PATH := "/system/lib/modules/mlan.ko"
WIFI_SDIO_IF_DRIVER_MODULE_NAME := "mlan"
WIFI_SDIO_IF_DRIVER_MODULE_ARG := ""
WIFI_DRIVER_MODULE_PATH := "/system/lib/modules/sd8xxx.ko"
WIFI_DRIVER_MODULE_NAME := "sd8xxx"
WIFI_DRIVER_MODULE_ARG := "drv_mode=5 cfg80211_wext=0xc sta_name=wlan uap_name=wlan wfd_name=p2p max_uap_bss=1 fw_name=mrvl/sd8787_uapsta.bin"
WIFI_DRIVER_FW_PATH_PARAM := "/proc/mwlan/config"
WIFI_DRIVER_FW_PATH_STA := "drv_mode=5"
WIFI_DRIVER_FW_PATH_AP := "drv_mode=6"
WIFI_DRIVER_FW_PATH_P2P := "drv_mode=5"
2. Attached files:
wifi.zip->/hardware/libhardware_legacy/wifi
marvell.zip->/hardware/imx/wlan
You should note that I just write different drv_mode to sd8xxx.ko driver to change different sta/uap/p2p mode. Details in wlan_src/readme_mlan:
The bit settings of drv_mode are,
Bit 0 : STA
Bit 1 : uAP
Bit 2 : WIFIDIRECT
3.Add a framework overlay file on product makefile
/frameworks/overlay/core/res/res/values/config.xml
Edit that option:
<!-- List of regexpressions describing the interface (if any) that represent tetherable
Wifi interfaces. If the device doesn't want to support tethering over Wifi this
should be empty. An example would be "softap.*" -->
<string-array translatable="false" name="config_tether_wifi_regexs">
<item>"wlan.*"</item>
</string-array>
Note that bolded "wlan.*" match my wlan interface name "uap_name=wlan" (BoardConfig.mk). Since Android does not support WiFi station and uAP mode simultaneously, It does not matter we have the same interface name for station and uAp (sta_name=wlan uap_name=wlan).
Hope these material can help you!
Hello, Raymond !
Thanks for sharing your experience - it helped me a lot in my attempts to configure Wi-Fi on my device.
Now I cannot bring up the hotspot mode ...
After configuring everything more or less the way you suggest, that's what I get in the logcat:
...
D/hostapd ( 3307): nl80211: Register frame type=0x40 nl_handle=0x4054b230
D/hostapd ( 3307): nl80211: Register frame match - hexdump(len=0): [NULL]
D/hostapd ( 3307): nl80211: Register beacons command failed: ret=-95 (Operation not supported on transport endpoint)
E/hostapd ( 3307): nl80211: Failed to set interface wlan0 into AP mode
D/hostapd ( 3307): netlink: Operstate: linkmode=0, operstate=6
D/hostapd ( 3307): nl80211: Set mode ifindex 9 iftype 2 (STATION)
E/hostapd ( 3307): nl80211 driver initialization failed.
...
While the hotspot never seems ready, the wlan0 interface does acquire IP address.
Did the hotspot mode work for you ?
What is your hostapd.conf file ?
Are there specific requirements about network capabilities, in order to be able to serve as an hotspot (my device has Ethernet along with Wi-Fi) ?
My system consists of i.MX6, sd8787 (Azurewave), Wi-Fi driver and wpa_supplicant extensions that you have posted above.
Any advice will be highly appreciated !
Please check your wlan driver makefile, enable CONFIG_ANDROID_KERNEL=y (default n).
Can you start another thread for sd8787 bluetooth? I am facing same problem about bluetooth stability.
there are something wrong....??
make: *** No rule to make target `out/target/product/sabresd_6dq/obj/STATIC_LIBRARIES/lib_driver_cmd_mrvl8787_intermediates/export_includes', needed by `out/target/product/sabresd_6dq/obj/EXECUTABLES/hostapd_intermediates/import_includes'. Stop.
marvell\wpa_supplicant_8_lib
The private static library is located at marvell\wpa_supplicant_8_lib
you can compile it manually or Add it's Android.mk to your whole building tree.
i dont' know how to add it.
it seems that Boardconfig.mk has
WPA_SUPPLICANT_VERSION := VER_0_8_X
and wpa_supplicant_8_lib\android.mk
LOCAL_PATH := $(call my-dir)
ifeq ($(WPA_SUPPLICANT_VERSION),VER_0_8_X)
why can't it compile automatic ?
You can refer to broadcom library in hardware/broadcom/wlan/bcmdhd/wpa_supplicant_8_lib