[LBEE5HY1MW-230] brcmf_chip_cr4_set_passive is hanging while boot up

[kmagi]

Hello,

I am are now doing board bring up of Wifi (LBEE5HY1MW-230) , but having trouble, I get part way through initialization but when preparing/starting to send the FW over SDIO to the chipset I get a system lockup.

I am using kernel version 4.14.98 and building on a Yocto project.

Below are the logs for reference,

root@imx6ull-everett-p1:~# cd /lib/modules/4.14.98-imx+g1175b5961153/kernel/drivers/net/wireless/broadcom/brcm80211/

root@imx6ull-everett-p1:/lib/modules/4.14.98-imx+g1175b5961153/kernel/drivers/net/wireless/broadcom/... insmod brcmutil/brcmutil.ko

root@imx6ull-everett-p1:/lib/modules/4.14.98-imx+g1175b5961153/kernel/drivers/net/wireless/broadcom/... insmod brcmfmac/brcmfmac.ko debug=0x00100006 &

[1] 339

root@imx6ull-everett-p1:/lib/modules/4.14.98-imx+g1175b5961153/kernel/drivers/net/wireless/broadcom/... [  111.671764] brcmfmac: brcmfmac_module_init No platform data available.

[  111.773418] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)

[  111.780974] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)

[  111.789270] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)

[  111.798355] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)

[  111.807746] mmc0: queuing unknown CIS tuple 0x80 (6 bytes)

[  111.888967] brcmfmac: brcmf_sdio_probe Enter

[  111.893298] brcmfmac: brcmf_sdio_probe_attach enable F2: err=0

[  111.900387] brcmfmac: F1 signature read @0x18000000=0x15264345

[  111.907174] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4345, rev=6

[  111.923562] brcmfmac: brcmf_chip_cores_check  [1 ] core 0x800:51 base 0x18000000 wrap 0x18100000

[  111.932489] brcmfmac: brcmf_chip_cores_check  [2 ] core 0x812:54 base 0x18001000 wrap 0x18101000

[  111.941918] brcmfmac: brcmf_chip_cores_check  [3 ] core 0x83e:9  base 0x18002000 wrap 0x18102000

[  111.950832] brcmfmac: brcmf_chip_cores_check  [4 ] core 0x83c:14 base 0x18003000 wrap 0x18103000

[  111.960211] brcmfmac: brcmf_chip_cores_check  [5 ] core 0x829:21 base 0x18004000 wrap 0x18104000

[  111.969121] brcmfmac: brcmf_chip_cores_check  [6 ] core 0x135:0  base 0x00000000 wrap 0x18107000

[  111.978475] brcmfmac: brcmf_chip_cores_check  [7 ] core 0x240:0  base 0x00000000 wrap 0x00000000

[  111.987370] brcmfmac: brcmf_chip_set_passive Enter

The hang is experienced when the driver is trying to set the chip in passive mode; precisely brcmf_chip_cr4_set_passive() function is causing the hang.

Could you please help in pointing out the problem and suggesting the solution?

Thanks,

Kiran

[GauravS_31]

Please ensure that the kernel modules are insmoded in the following order:

insmod compat.ko
insmod cfg80211.ko
insmod brcmutil.ko
insmod brcmfmac.ko

Also i see the message "brcmfmac_module_init No platform data available." Have you loaded the appropriate DTB file based on your setup?

[kmagi]

I don't see compat.ko module being compiled and generated. I could see only the other 3 kernel modules being generated. Can you explain me what's the role of compat.ko and how can I enable that?

I am sure about using the right DTB file too.

Further, debugging reveled that the hang is happening when usleep_range() function is invoked from brcmf_chip_ai_coredisable() function in ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c file of the driver code.

If I try to bypass the usleep_range() or replace with udelay(),  I could see the hang is happening somewhere in work queue initialization / spin lock initialization. I guess the hang is happening in general when there is context switching is imposed. Can someone please help with this?

[GauravS_31 · Accepted solution]

compat.ko is the kernel backport module and required for backporting to older kernel version. It is expected to be generated by following the instructions in the attached README under the section "Build the cypress driver/backports modules". You can also check the loaded kernel modules using the "lsmod" command. All the 4 .ko files should be present.

Regarding the hang, it appears to me that the host is being brought up much faster than the radio and possibly more time would be required to be given to the radio. Can you try extending the sleep time in usleep_range(10, 20)?