WL1835MOD Linux Boot Fail

Hi Mark,

Please paste the full boot logs and also what wl18xx driver version is the customer using?

Regards,
Gigi Joseph. 

I've made a lot of progress since I asked my original question.  Now I’m able to bring up wlan0, perform a scan, connect to an AP, and route out to the Internet.  The reason that the firmware failed to load previously (which of course prevented me from bringing the interface up), was that the WLAN_EN line wasn't asserted as I thought it was.  The Atmel SDIO driver detected the WL1835MOD on the bus, and wl18xx and dependencies were loaded, so it appeared to already be operational.  Right now I am using a userspace utility that hooks sysfs to toggle GPIO pins to manually assert the WLAN_EN line.  Once I did that, I could successfully bring up the wlan interface:

# ifconfig wlan0 up

wlcore: PHY firmware version: Rev 8.2.0.0.212

wlcore: firmware booted (Rev 8.9.0.0.17)

Those are the versions reported when I bring up the interface.  According to a page on your wiki (http://processors.wiki.ti.com/index.php/WL18xx_Driver_Debug) I should be able to grep out the build string from the driver, but I get no output using the method described there.

On your Platform Integration page, you mention a method involving describing a voltage regulator in the DTS to assert power to the WL18xx.  Is this the only alternative to the "old way" of creating a set_power() callback?  I'm new to Device Tree, so I apologize if this is common knowledge.  Going forward, we obviously don't want to use our sysfs method to manually toggle the enable lines.

Could you elaborate on the "why" and "how" of the voltage regulator method?

Hi,

The firmware you are using is the latest official version. The driver version gets displayed when you insmod the wl18xx modules - you can do dmesg | grep ol_ to find that out.

With the Device tree mechanism, the set_power() method won't work. The only option is to use the voltage regulator method. It is explained in: http://processors.wiki.ti.com/index.php/WL18xx_Platform_Integration_Guide#Power_Control_.E2.80.93_using_a_fixed_voltage_regulator

Regards,
Gigi Joseph.

Hello Gigi,

I have already seen that part of the URL you posted, and copied that DTS snippet into mine (changing the GPIO specification for our board, and fixing the incorrect board-ref-clock value).  Then I reference the regulator in my mmc device definition as the power source.  However, when the board is powered up and the WL1835 is detected on the SDIO bus, and the atmel-mci driver is loaded, the WLAN_EN line is not raised as expected, so the firmware cannot be loaded automatically.  I'm not sure how this could work anyway, considering that there is nothing in the atmel-mci driver source which looks for a reference to a voltage regulator in the DTS.

This issue is preventing me from getting to the next stage, which is running this chip simultaneously as a WiFi client and an AP.  Do I need alternate firmware for this?  I don't see anything about this in the Platform Integration Guide for WL18xx.

Please answer these questions:

(Q1) On the URL you posted, it states "For power up/down we can initialize a software(GPIO based) fixed voltage regulator structure that is used for controlling the WLAN_Enable pin by the kernel power manager" -- what exactly does this mean, and how is that related to triggering power up/down from the wl18xx driver?

(Q2) Do I need alternative firmware in order to use the WL1835 in a multi-role setup?  If so, where do I get it?

Thanks,
Bijoy

P.S.  I'm attaching the relevant sections of my DTS file, in case there are any glaring errors.

    wlan_en_reg: fixedregulator@2 {
        compatible = "regulator-fixed";
        regulator-name = "wlan-en-regulator";
        regulator-min-microvolt = <1800000>;
        regulator-max-microvolt = <1800000>;
 
        /* WLAN_EN GPIO for this board - Bank A, pin 4 */
        gpio = <&pioA 4 0>;
 
        /* WLAN card specific delay */
        startup-delay-us = <70000>;
        enable-active-high;
    };
 
    wlcore {
                compatible = "wlcore";
                gpio = <14>; /* Bank A, pin 14 connected to IRQ line of WL1835MOD */
 
                /*
                 * TODO: use edge irqs for suspend/resume.
                 * in newer kerenls, we seem to miss interrupts when
                 * working with edge irqs, so revert back to level irqs.
                 */
                platform-quirks = <1>;
 
                /* if a 12xx card is there, configure the clock to
                   WL12XX_REFCLOCK_38_XTAL */
                /*
                board-ref-clock = <4>;
                */
 
                /* For WL1835MOD, WL12XX_REFCLOCK_26_XTAL */
                board-ref-clock = <5>;
    };
 
    kim {
                compatible = "kim";
                nshutdown_gpio = <29>; /* Bank A, pin 29 */
                dev_name = "/dev/ttyO1";
                flow_cntrl = <1>;
                baud_rate = <3000000>;
    };
 
    btwilink {
                compatible = "btwilink";
    };

---------------------------------------------------------- 
 
Inside apb, ahb:
 
        mmc0: mmc@f0008000 {
            status = "okay";
            vmmc-supply = <&wlan_en_reg>;
            non-removable;
            cap-power-off-card;
            keep-power-in-suspend;
        };

Hi Bijoy,

(A1) What it means is that the WLAN_EN pin is controlled by the Linux power manager. Please take a look at <kernel>/drivers/regulator/fixed.c and <kernel>/drivers/regulator/core.c

The mmc host need to have the "vmmc-supply" in its device tree as below:

&mmc3 {

/* these are on the crossbar and are outlined in the
xbar-event-map element */
dmas = <&edma 12
&edma 13>;
dma-names = "tx", "rx";

status = "okay";
vmmc-supply = <&wlan_en_reg>;
bus-width = <4>;
ti,non-removable;
ti,needs-special-hs-handling;
cap-power-off-card;
keep-power-in-suspend;
};

You can also take a look at <drivers>/mmc/host/omap_hsmmc.c :: omap_hsmmc_reg_get() )


(A2) No.

I see the below in your dts file:
gpio = <&pioA 4 0>; 

In my case, it is:
gpio = <&gpio1 16 0>;

I am not sure if what you have put is correctly parsed. Maybe you can debug of_get_fixed_voltage_config() in drivers/regulator/fixed.c 

config->gpio = of_get_named_gpio(np, "gpio", 0);

Regards,
Gigi Joseph.

Hello Gigi,

RE: (A1)
Your mmc3 example assumes an MMC host driver (like the OMAP-based one you mentioned) that actually has of_* calls that are looking for a property with the name "vmmc-supply" -- am I to assume that the WL18xx will only work with TI boards?

I looked at the relevant driver source (atmel-mci) for our board (AT91SAM9G25-based) and there are definitely no references to "vmmc-supply" or similar.  My virtual fixed-voltage regulator gets instantiated, but my MMC host will never look for a regulator to power the WLAN_EN line.  I am still not understanding how that mechanism is intended to work.

RE: (A2)

You are asserting that I can run my WL1835 in multi-role mode, with the firmware (wl18xx-fw-4.bin) that I have now.  Do you have instructions on how to do this?  I would expect a wlan0 and wlan1 to be created in order to be able to run as a WiFi client and host simultaneously.

RE: the gpio specification
Our syntax is slightly different because we are on different boards.  Not sure how that would be unexpected.  When I look at the resultant value under /proc/device-tree for the regulator gpio, it appears to be correct.

We are running short on time for simply getting this part up and running with wpa_supplicant and hostapd.  It's starting to look like we will have to select a part from a different vendor.

Thanks,
Bijoy

Hi Bijoy,

1. I am not familiar with the atmel-mci host, but I did see a patch on the internet that adds the "vmmc-supply" support. 
Please see this link: https://lkml.org/lkml/2013/10/17/152 

It doesn't look like it made it into the mainline. But I think its worth a try.

2. Please see this page: http://processors.wiki.ti.com/index.php/WiLink8_WLAN_Demo:_Linux#MultiRole_.28STA.2BAP.29
for the Multirole demo.
Yes, you need two interfaces 'wlan0' & 'wlan1'.

Regards,
Gigi Joseph.

Hello Gigi,

Thank you for finding that patch.  Now I can bring the wlan interface up and down without having to do my previous workaround.

As before, I am able to run wpa_supplicant successfully -- I'm able to connect to an AP, get an IP address, and get out to the Internet.  However I am having trouble with hostapd -- it comes up without any errors, yet other wifi devices (including wlan0) do not see the SSID specified when scanning.  I am following the directions, and using the example configuration shown on the URL that you posted.

Any ideas?

Thanks,

Bijoy

Hi Bijoy,

Can you please share the hostapd  (with "-dd" option) + driver logs for the scenario?
The wlan0 interface on the same host would not show the AP (on wlan1). 

Are you able to scan for the AP when running in single role?

Regards,
Gigi Joseph.

Hello Gigi,

I'm not sure what you mean by driver logs -- I'm not seeing anything in /var/log/messages that's not showing up on stdout.  Here's what I get when I try to start it up in single role with your example hostapd configuration:

# hostapd -dd -B ti-sr-hostapd.conf
random: Trying to read entropy from /dev/random
Configuration file: ti-sr-hostapd.conf
ctrl_interface_group=0
nl80211: interface wlan0 in phy phy0
rfkill: Cannot open RFKILL control device
nl80211: RFKILL status not available
nl80211: Using driver-based off-channel TX
nl80211: Use separate P2P group interface (driver advertised support)
nl80211: Add own interface ifindex 6
nl80211: Set mode ifindex 6 iftype 3 (AP)
nl80211: Create interface iftype 6 (MONITOR)
nl80211: New interface mon.wlan0 created: ifindex=15
nl80211: Add own interface ifindex 15
wlcore: PHY firmware version: Rev 8.2.0.0.212
wlcore: firmware booted (Rev 8.9.0.0.17)
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz
nl80211: 2457-2482 @ 40 MHz
nl80211: 2474-2494 @ 20 MHz
nl80211: 5170-5250 @ 160 MHz
nl80211: 5250-5330 @ 160 MHz
nl80211: 5490-5730 @ 160 MHz
nl80211: Added 802.11b mode based on 802.11g information
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=20 dBm
Completing interface initialization
Mode: IEEE 802.11g Channel: 11 Frequency: 2462 MHz
nl80211: Set freq 2462 (ht_enabled=0 sec_channel_offset=0)
Failed to update rate sets in kernel module
RATE[0] rate=60 flags=0x1
RATE[1] rate=90 flags=0x1
RATE[2] rate=120 flags=0x1
RATE[3] rate=180 flags=0x1
RATE[4] rate=240 flags=0x1
RATE[5] rate=360 flags=0x0
RATE[6] rate=480 flags=0x0
RATE[7] rate=540 flags=0x0
Flushing old station entries
Deauthenticate all stations
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=3 set_tx=0 seq_len=0 key_len=0
Using interface wlan0 with hwaddr 84:dd:20:9c:30:b7 and ssid 'SoftAP_Role'
nl80211: Set beacon (beacon_set=0)
wpa_driver_nl80211_set_operstate: operstate 0->1 (UP)
netlink: Operstate: linkmode=-1, operstate=6
wlan0: Setup of interface done.

# ps -e | grep host

9261 ?        00:00:00 hostapd

I have wlan1 configured as described in your instructions, but I want to get single role working on wlan0 first.

I'm getting a bunch of these errors on the console after leaving hostapd running for a while:

wlcore: WARNING trying to record key replacement
wlcore: ERROR Could not add or replace key
wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-22)

No, I still am not able to see my SSID when I scan from other devices.

Thanks,
Bijoy