i.MX Processors中的主题 Re: help on linux and SDIO detection

help on linux and SDIO detection

angelo_d — Fri, 06 Mar 2015 10:29:36 GMT

Dear all,

i have imx6q connected on usdhc1 with a murata sdio module sn8000, with his external pinout directly connected to internal bcm43362 broadcom chip. Using brcmfmac linux driver, on kernel 3.10 (and some adaption to the brcmfmac driver since this chip starts to be supported on kernel 3.14), i could have the module correctly SDIO-probed (4-bit mode) and working properly. It seems that after some changes to the drive-strength controlling processor pin config, the module started to get successfully probed.

The sequence of the init operations seems to be the following:

a. linux generic SDIO driver probe the bus

b. once chip is detected, brcmfmac driver specific probe is used

c. brcmfmac initialize the chip and upload the firmware

d. userspace setup

e. wlan0 up

Now, after some days, the module started to fail on SDIO probe (step "a", still no brcmfmac driver involved here), and then, after some additional retries, the module is no more successfully probed.

So issue is still at SDIO probing stage (linux throw SDIO error -110, timeout). I would appreciate any information useful to debug and understand why the probe fails, especially:

- any useful information on the driver strength or configuration of the pins

- any sample sn8000 devicetree

Actaully i am not setting "vqmmc", if i set it, the kernel complains that cannot set the lines voltage level (tested both 3.3 or 1.8).

I have oscilloscope available, i see SDIO clk and commands happening, but no replies or state changes in the 4 data lines.

Every help is very appreciated

angelo

Re: help on linux and SDIO detection

igorpadykov — Sat, 14 Mar 2015 00:31:46 GMT

Hi angelo

if this device worked well some time ago, this seems as

quality issue: one can try another device or check power supplies and

connector, test signals with oscilloscope.

It may be useful to test basic device operations with SDK

i.MX 6Series Platform SDK

Best regards

igor

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

Note: If this post answers your question, please click the Correct Answer button. Thank you!

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

Re: help on linux and SDIO detection

angelo_d — Wed, 08 Apr 2015 20:46:03 GMT

Well, no, never worked reliably, except fro some hours.

Seems wifi module is reacting to hot/cold someway,

since re-soldering terminator 0ohm bridges seems to make the

detection to work for some time.

Or tracks and signal seems to benefit of re-soldering.

Module is far about 12cm from the cpu, so tracks are quite long. Could this

be a problem ?

Here below a successful detection:

[	2.607114] mmc0: no vqmmc regulator found
[	2.653856] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[	2.663312] sdhci-esdhc-imx 219c000.usdhc: could not get ultra high speed state, work on normal mode
[	2.671222] mmc1: no vqmmc regulator found
[	2.700890] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[	2.707773] mmc0: queuing unknown CIS tuple 0x80 (6 bytes)
[	2.713855] mmc1: SDHCI controller on 219c000.usdhc [219c000.usdhc] using ADMA
[	2.721788] mmc0: queuing unknown CIS tuple 0x80 (8 bytes)
[	2.727419] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[	2.734728] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[	2.741421] mmc0: queuing unknown CIS tuple 0x80 (5 bytes)
[	2.759816] mmc0: new high speed SDIO card at address 0001

Every idea is welcome

Re: help on linux and SDIO detection

nikolajøsterbye — Fri, 17 Apr 2015 11:53:29 GMT

I have the same problem.

I'm trying to get the module from the SN8000-EVK working on a RIoTboard.

I'm using fslc kernel 3.18.

During boot I see the "mmc0: queuing unknown CIS tuple 0x80" lines, that Angelo is mentioning.

When calling "ifup wlan0" I get the following output:

root@imx6dl-riotboard:~# ifup wlan0

Successfully initialized wpa_supplicant

[12189.789490] brcmfmac: brcmf_sdiod_regrw_helper: failed to write data F1@0x1000e, err: -110

[12189.797831] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -110

[12189.804922] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame

[12189.817360] brcmfmac: brcmf_sdiod_regrw_helper: failed to write data F1@0x1000d, err: -110

[12189.831312] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x1001a, err: -110

[12189.843176] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x10019, err: -110

[12189.855246] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x1001a, err: -110

[12189.867815] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x10019, err: -110

[12189.880605] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x1001a, err: -110

[12189.893131] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x10019, err: -110

Could not set interface wlan0 flags (UP): Input/output error

WEXT: Could not set interface 'wlan0' UP

wlan0: Failed to initialize driver interface

ifconfig: SIOCSIFFLAGS: Input/output error

I can see the SDIO clock and activity on the CMD line.

It would be really nice with some information and sample code for the device tree.

The only thing I have changed is the usdhc2 block in imx6dl-riotboard.dts:

&usdhc2 {

#address-cells = <1>;

#size-cells = <0>;

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_usdhc2>;

vmmc-supply = <&reg_3p3v>;

non-removable;

status = "okay";

brcmf: bcrmf@1 {

reg = <1>;

compatible = "brcm,bcm4329-fmac";

};

br.

Nikolaj

Re: help on linux and SDIO detection

angelo_d — Fri, 17 Apr 2015 13:45:59 GMT

Just to close the thread,

if someone have issues with sn8000 timeouts, note that internal LDO (internal low drop out regulator) in the sn8000 must be enabled.Related pin must be connected to 3.3V.

Re: help on linux and SDIO detection

angelo_d — Fri, 17 Apr 2015 16:26:16 GMT

hi nikolaj,

1) be sure of hw connections:

- check VDD_BAT and VDD_IO pin to be at 3.3

- check VDD_3V3_EN to be 3.3V

- check eventually reset sequence timing

2) check usdhc2 drive strength (see imx6q datasheet), set it to maximum (lower resistance) in devicetree

if it is sn8000 it is brcm43362 based, so remove

brcmf: bcrmf@1 {

reg = <1>;

compatible = "brcm,bcm4329-fmac";

};

3) see that you have a correct nvram txt and binary firmware files loaded in dmesg.

I can confirm sn8000 works reliably with brcmfmac driver.

Re: help on linux and SDIO detection

nikolajøsterbye — Mon, 20 Apr 2015 12:26:05 GMT

Hi angelo.

Thanks for replying.

VDD_3V3_EN and VDD on the SDIO interface are both 3.3V.

I removed the "brcmf: bcrmf@1 {" block from the dts file and changed the drive strength to minimum resistance.

The behavior is still the same.

I can see that the brcmfmac driver actually detects that it is a 43362 chipset that is connected. So it seems that probing and initialization goes well. However, after this, any communication to the module times out.

I haven't been able to find any documentation on how to create a proper nvram file, so I have taken the values from one of the WICED examples.

Do you know where I can find documentation on the nvram file?

br.

Nikolaj

Re: help on linux and SDIO detection

nikolajøsterbye — Tue, 21 Apr 2015 07:18:44 GMT

Hi angelo.

Thanks for your help.

The issue seemed to be that I had connected the cable from the sn8000 EVK mainboard, to the sn8000 module, in order to supply 3.3V, enable signal and GND to the module. However, this cable also connects GPIO0, GPIO1, and a slow clock to the module.

Apparently something on the extra connections prevented the module from running properly.

After detaching the cable, and supplying 3.3V, reset signal, and GND from separate connections, it works.

br.

Nikolaj

Re: help on linux and SDIO detection

angelo_d — Thu, 23 Apr 2015 20:11:02 GMT

Hi Nikolaj,

happy it works.

The reason you was not detecting it is that GPIO0 is a bootsrtrap pin that selects betwen SDIO and SPI communication mode, so if it is connected to something and read as 1 from the module at powert up, module boots in SPI and not SDIO. :smileyhappy:

Also, it is always a good pratice to avoid connections to GPIO if you are not 100% sure of their state after boot, since you can have

shorts/conflicts on the lines (ie out as 0 against out as 1).

Re: help on linux and SDIO detection

taruntejkanakam — Thu, 16 Jun 2016 10:32:21 GMT

Hi Angelo and Nikolaj,

I am working to bring up WiFi on a custom board made out of IMX6UL. It has the WiFi module SN8000 connected to USDHC2, two GPIOs, each connected to RST_N and VDD_3V3_EN of the WiFi module. VDD_BAT is coming from external regulator and VDD_IO is coming from the source. Using kernel 4.1.15.

I have the following structure in the .dts file as I am using the BCMDHD as a module. (Included both BCMDHD, BRCMFMAC as modules in the menuconfig)

bcmdhd_wlan_0: bcmdhd_wlan@0 {

compatible = "android,bcmdhd_wlan";

wlreg_on-supply = <&wlreg_on>;

};

Once I insert the module bcmdhd.ko I could get the wlan0 interface enabled with a proper MAC address.

insmod /lib/modules/4.1.15-1.1.1+g1881fb8/kernel/drivers/net/wireless/bcmdhd/bcmdhd.ko \

firmware_path=/lib/firmware/brcm/brcmfmac43362-sdio.bin \

nvram_path=/lib/firmware/brcm/brcmfmac43362-sdio.txt

But in the later steps when I give the command ifup wlan0 or ifconfig wlan0 up, I get a Kernel panic situation as shown below.

# ifup wlan0

Successfully initialized wpa_supplicant

rfkill: Cannot open RFKILL control device

CFG80211-ERROR) wl_update_wiphybands : error reading vhtmode (-23)

ioctl[SIOCSIWPMKSA]: Invalid argument

ioctl[SIOCSIWMODE]: Invalid argument

ioctl[SIOCGIWRANGE]: Invalid argument

ioctl[SIOCGIWMODE]: Invalid argument

ioctl[SIOCSIWAP]: Invalid argument

ioctl[SIOCSIWESSID]: Invalid argument

ioctl[SIOCSIWENCODEEXT]: Invalid argument

ioctl[SIOCSIWPMKSA]: Invalid argument

udhcpc (v1.23.2) started

Unable to handle kernel paging request at virtual address 889da900

pgd = 88aa8000

[889da900] *pgd=8881141e(bad)

Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM

Modules linked in: brcmfmac brcmutil bcmdhd

CPU: 0 PID: 374 Comm: dhd_dpc Not tainted 4.1.15-1.1.1+g1881fb8 #84

Hardware name: Freescale i.MX6 Ultralite (Device Tree)

task: 88123440 ti: 88c14000 task.ti: 88c14000

PC is at 0x889da900

LR is at rcu_process_callbacks+0x460/0x578

pc : [<889da900>] lr : [<800778fc>] psr: a0010113

sp : 88c15da0 ip : 88508780 fp : 00000000

r10: 889da600 r9 : 0000000a r8 : 00000000

r7 : 88c14000 r6 : 8bb35e1c r5 : 80b04740 r4 : 8bb35e00

r3 : 889da900 r2 : 8840c8e8 r1 : 8840c8e8 r0 : 88508780

Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel

Control: 10c53c7d Table: 88aa806a DAC: 00000015

Process dhd_dpc (pid: 374, stack limit = 0x88c14210)

Stack: (0x88c15da0 to 0x88c16000)

5da0: 10b87200 88bd8000 00000201 80b04d40 80af3dc0 8079989c 80b608b1 80af3dc0

5dc0: 8840c8e8 80b04740 00000001 00000000 00000009 80af80a4 88c14000 00000101

5de0: 80af8080 80af8080 40000009 800379fc 00000001 80af8594 88c15df0 80b66000

5e00: 00000009 ffffadd3 80af8100 00208140 80af8594 60010113 00000201 00000000

5e20: 7f04ea48 885e1800 ffffd8f1 00000000 00000000 80037b88 88bd8000 80037c8c

5e40: 88bd8000 00000000 00000000 7f0096f0 88bd8000 7f04c604 88bdb9a0 a0010193

5e60: 00000014 80796108 00000014 80796488 88bd8000 a0010113 88bdb000 000007d0

5e80: 889e0900 7f00f378 7f0763f8 00000003 00000014 80796488 7f0763f8 885e1800

5ea0: 7f0763f8 7f07acac 00000000 889e0900 00000000 00000000 00000014 7f057374

5ec0: 00000000 600b0013 88bdb8bc 00000032 ffffae9a 88bdb000 80ba8140 80af3800

5ee0: 01000000 0b042000 80ba8140 80052b28 88bdb858 ffffae9a 00000000 80796488

5f00: 88bdb858 8007a8cc 00000000 a0010193 88bd8000 a0010113 88bdb000 88bd8000

5f20: 88bdb8a8 88bdb8e0 00000000 60010113 88bdb8bc 00000000 00000000 7f00f528

5f40: 88bdb8a8 00000001 00000000 00000000 8899de00 88bdb8a8 7f00f440 00000000

5f60: 00000000 8004cdf8 e3130001 00000000 e3000000 88bdb8a8 00000000 00000000

5f80: 88c15f80 88c15f80 00000000 00000000 88c15f90 88c15f90 88c15fac 8899de00

5fa0: 8004cd1c 00000000 00000000 8000f528 00000000 00000000 00000000 00000000

5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 eaffff1a e5973000

[<800778fc>] (rcu_process_callbacks) from [<800379fc>] (__do_softirq+0x120/0x238)

[<800379fc>] (__do_softirq) from [<80037b88>] (do_softirq.part.2+0x30/0x38)

[<80037b88>] (do_softirq.part.2) from [<80037c8c>] (__local_bh_enable_ip+0xfc/0x100)

[<80037c8c>] (__local_bh_enable_ip) from [<7f0096f0>] (dhd_os_wlfc_unblock+0x1c/0x40 [bcmdhd])

[<7f0096f0>] (dhd_os_wlfc_unblock [bcmdhd]) from [<7f04c604>] (dhd_wlfc_commit_packets+0x90/0x660 [bcmdhd])

[<7f04c604>] (dhd_wlfc_commit_packets [bcmdhd]) from [<7f057374>] (dhdsdio_dpc+0x15c/0x1024 [bcmdhd])

[<7f057374>] (dhdsdio_dpc [bcmdhd]) from [<7f00f528>] (dhd_dpc_thread+0xe8/0x130 [bcmdhd])

[<7f00f528>] (dhd_dpc_thread [bcmdhd]) from [<8004cdf8>] (kthread+0xdc/0xf4)

[<8004cdf8>] (kthread) from [<8000f528>] (ret_from_fork+0x14/0x2c)

Code: 00000000 00000000 00000000 00000000 (00000000)

---[ end trace 953822d756db6542 ]---

Kernel panic - not syncing: Fatal exception in interrupt

---[ end Kernel panic - not syncing: Fatal exception in interrupt

sched: RT throttling activated

Neither am I able to do the iw wlan0 scan operation (apparently because the wlan0 is not UP).

You have mentioned in the above answer that "sn8000 works reliably with brcmfmac driver". I want to know from you on what should be the compatible property for BRCMFMAC driver and what all the drivers should be enabled in the menuconfig other that BRCMFMAC? What are the other drivers that need to be enabled for this module.?

Thanks,

Tarun