Wi2Wi WM828CC6 wifi module not working on Colibri iMX6


I’m trying to use the Wi2Wi WM828CC6 (Marvell 88W8887) Wifi module on SDIO2 interface of a iMX6dl module.

I can not see any SDIO2 on linux, so I guess some device-tree error is occurring.

Basically, these are the modifications I did on device-tree:


aliases {
mmc2 = &usdhc2;
&usdhc2 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usdhc2>;
	/* non-removable;*/
	status = "okay";
	 * Does not work for a WiFi chip since vmmc get turned on only during
	 * SDIO communication...
//	vmmc-supply = <&reg_wifi_pwd>;


pinctrl_csi_gpio_1: csi_gpio-1 {
fsl,pins = <
                MX6QDL_PAD_EIM_A24__GPIO5_IO04   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_D18__GPIO3_IO18   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_A19__GPIO2_IO19   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_D29__GPIO3_IO29   PAD_CTRL_HYS_PD
                MX6QDL_PAD_EIM_A23__GPIO6_IO06   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_A20__GPIO2_IO18   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_A17__GPIO2_IO21   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_A18__GPIO2_IO20   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_EB3__GPIO2_IO31   PAD_CTRL_HYS_PU
                MX6QDL_PAD_EIM_D17__GPIO3_IO17   PAD_CTRL_HYS_PU

pinctrl_mmc2_cd: gpio_mmc2_cd {
             fsl,pins = <
                 MX6QDL_PAD_GPIO_4__SD2_CD_B    PAD_CTRL_NO  /* MMC2 CD */

pinctrl_usdhc2: usdhc2grp {
			fsl,pins = <
				 MX6QDL_PAD_SD2_CMD__SD2_CMD    0x17071
                 MX6QDL_PAD_SD2_CLK__SD2_CLK    0x10071
                 MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17071
                 MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
                 MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
                 MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071

pinctrl_weim_gpio_3: weim_gpio-3 {
			fsl,pins = <
                MX6QDL_PAD_EIM_BCLK__GPIO6_IO31    PAD_CTRL_HYS_PU
                MX6QDL_PAD_NANDF_CS3__GPIO6_IO16   PAD_CTRL_HYS_PU
                MX6QDL_PAD_NANDF_CS1__GPIO6_IO14   PAD_CTRL_HYS_PU
                MX6QDL_PAD_NANDF_RB0__GPIO6_IO10   PAD_CTRL_HYS_PU
                MX6QDL_PAD_NANDF_CS0__GPIO6_IO11   PAD_CTRL_HYS_PU
                MX6QDL_PAD_GPIO_19__GPIO4_IO05     PAD_CTRL_HYS_PU
                MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19   PAD_CTRL_HYS_PU
                MX6QDL_PAD_GPIO_5__GPIO1_IO05      PAD_CTRL_HYS_PU
                MX6QDL_PAD_GPIO_2__GPIO1_IO02      PAD_CTRL_HYS_PU


Kernel version: 4.1.44

I’m not sure about the pins. I have tried to modify my device tree based on imx6ull module but some pins conflict were related so I believe it s not the same configuration.

Thank you

Hi @mk23

Could you provide the version of the Hardware and Software of your module?
Which carrier board are you using?

Could you share the dmesg log and the kernel config in a file? Thanks.

Best regards, Jaski

thank you @jaski.tx for the reply.
Module: Colibri iMX6Dl 512MB IT V1.1A.
The system was built using Yocto Rocko Kernel version: 4.1.44-2.8.1 based on layers meta-toradex-bsp-common, meta-toradex-nxp.

We have developed our own board. You can find attached the wifi connection scheme and the dmesg log.

Thank you

Link for files:

Please note that our Rocko BSP 2.8b5 is on the Linux kernel branch toradex_4.9-2.3.x-imx now and any older beta BSP is no longer supported.

Thank you @marcel.tx. It means the first thing should I do is upgrading my bsp version? There is some alternative for us double check it before to execute this bsp upgrade? I Just ask it because I have some drivers which probably I’ll need to update to execute them in a new bsp in this board we made and we are using. I just suppose it because I had some issues in older versions, so If I could test something before it will take less time probably. Anyway, I go starting work to execute the bsp upgrade. It is an old version. Thank you, appreciate it so much.

Like Marcel said, you should flash the Bsp 2.8b5 and just do the needed changes for your board in kernel or device tree and do a Kernel Compilation as described here. This approach will be more simple and faster than creating a complete updated custom image using Yocto.

Best regards, Jaski

Update on this: we have tested this using the latest BSP and the Wi-Fi module still doesn’t work.

This is what we’ve done so far:

First, we brought up SDIO2 and tested it was working with an SD card.

Then we built an image with Yocto, enabling the MWIFIEX and MWIFIEX_SDIO kernel modules, patching the device tree to bring up SDIO2 and installing linux-firmware.

Upon flashing this new image and running modprobe on the module, we have:

root@colibri-imx6:~# modprobe mwifiex_sdio
[   19.472270] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   19.498340] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

dmesg | grep mmc2 yields:

root@colibri-imx6:~# dmesg | grep mmc2
[    1.942975] mmc2: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA

dmesg | grep mwifiex_sdio shows no output.

We’re starting to think this is a hardware issue. Any clues?


Maybe try “non-removable” instead of “broken-cd” in device tree? Other than that, is the Wifi device stuck in hardware reset?

As for the W-iFi drivers are you using backports like we usually do in our BSPs? Is that particular device known to work in any other configuration? If the slot is working with SD cards then it is most likely a hardware issue on the Wi-Fi device side.

Hi @marcel.tx! This is the exact same Wi2Wi Wi-Fi module used on our Colibri iMX6ULL V1.0A, which works alright.

The slot is indeed working with SD cards, that’s why it seems like a hardware issue.

We tried using non-removable instead of broken-cd but the result is the same.

We can’t assess if the device is stuck in hardware reset because there’s no indication of it being ever detected in Linux and we don’t have access to the Wi-Fi module pins on the board, for now.

You have some nice testpoints to work with. What do you measure on
TP 51,52,14,17,18,19,65,66?

-The module needs to be powered (via enable_wf_bt)
-32khz clock needs to be on
-gpio shouldn’t assert powerDown-

Hmm, maybe it’s as easy as asserting enable_wf_bt in U-boot before loading kernel?
ALTF5 for mxm.77 = GPIO3_IO18
Looks like mxm.77 = (3-1)*2+18= Linux GPIO_82?
Try using “GPIO clear 82” or “GPIO set 82” in U-boot before running kernel? You can check with the probe on the testpoint that I calculated the right GPIO#

Unfortunately I don’t have the module connected to an eval board. It’s soldered to a custom board inside a customer product that cannot be opened.

I’ll be getting a custom board from the customer in the next few days and then I’ll be able to properly probe the signals.

I’ll check the enable_wf_bt signal and try asserting it from U-Boot. Thanks for the tip.