wifi works when BBGW first powered on, but not after a warm reboot

When I first plug power into my BBGW, everything works great. But if I issue a “reboot” or “shutdown -r now” command, when the device boots back up I have no wifi.

Anyone else having problems with wifi not working when doing a “warm” reboot? Is this a known problem, or is there a known workaround?

I’ve diff’d the output of the serial console when it works and when it doesn’t, and I only see 1 line difference at the very start of the boot process.

When it works:

DRAM: 512 MiB
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1

When it doesn’t work:

DRAM: 512 MiB

Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1

When it doesn’t work, I get this message logged in dmesg every few seconds after the boot has finished:

[ 612.676285] wlcore: ERROR firmware boot failed despite 3 retries
[ 620.458410] wlcore: ERROR timeout waiting for the hardware to complete initialization
[ 622.558761] wlcore: ERROR timeout waiting for the hardware to complete initialization
[ 624.634344] wlcore: ERROR timeout waiting for the hardware to complete initialization

The only other thing I’ve noticed is a 20-line error message and backtrace logged to /var/log/messages. That start of which looks like this:

May 21 15:34:57 beaglebone kernel: [ 31.978453] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
May 21 15:34:57 beaglebone kernel: [ 32.067899] wlcore: loaded
May 21 15:34:57 beaglebone kernel: [ 32.454957] wlcore: PHY firmware version: Rev 8.2.0.0.236
May 21 15:34:57 beaglebone kernel: [ 32.494528] wlcore: firmware booted (Rev 8.9.0.0.69)
May 21 15:34:57 beaglebone kernel: [ 32.511704] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 21 15:34:57 beaglebone kernel: [ 32.857933] ------------[ cut here ]------------
May 21 15:34:57 beaglebone kernel: [ 32.858199] WARNING: CPU: 0 PID: 1781 at drivers/net/wireless/ti/wlcore/main.c:797 wl12xx_queue_recovery_work.part.8+0x46/0x48 wlcore
May 21 15:34:57 beaglebone kernel: [ 32.858207] Modules linked in: arc4 wl18xx wlcore mac80211 snd_soc_evm snd_soc_wilink8_bt omap_aes_driver omap_sham omap_rng rng_core snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap wlcore_sdio snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore evdev uio_pdrv_genirq uio usb_f_acm u_serial usb_f_rndis g_multi usb_f_mass_storage u_ether libcomposite cfg80211 rfkill
May 21 15:34:57 beaglebone kernel: [ 32.858314] CPU: 0 PID: 1781 Comm: irq/54-wl18xx Not tainted 4.4.19-ti-r41 #1
May 21 15:34:57 beaglebone kernel: [ 32.858321] Hardware name: Generic AM33XX (Flattened Device Tree)

I’m using this build: https://rcn-ee.com/rootfs/bb.org/testing/2016-09-04/seeed-iot/BBGW-blank-debian-8.5-seeed-iot-armhf-2016-09-04-4gb.img.xz

TIA.

Stéphane

I still don't think we are properly resetting the wl18xx on startup.
(in u-boot is the easiest place)

Regards,

How can I help? Are there BB specific files, scripts, or a fork of U-Boot that is used on the BB? Can you point me in the right direction so I can start poking?

And perhaps more importantly for me before I go further, do other people see this same problem, or is it just my BBGW which is messed up? I only have 1 BBGW to test with, so i don’t know if this is a common issue.

Stéphane

I tried on TI’s forums to get help for this issue, but their only response is to contact the BBGW community here or on IRC since I’m using one of RCN’s builds.

  1. Is anyone else seeing this problem where WIFI on BBGW doesn’t work on warm reboots?
  2. Can someone point me to where the source/scripts are located for Das U-Boot used on recent BBGW builds? Is there something like a github project from which the BBGW builds are generated?

Thanks,

Stéphane

Yes, I have this problem, too. I have not tried figuring out a SW solution. I just power cycle on the thankfully few times I need to reboot.

Mark

Switching to using gpio-hog vs the regulators seem to have helped..

I'm about a dozen soft-reboot's into testing, so i pushed this

debian@beaglebone:~$ dmesg | grep wl
[ 34.377974] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[ 34.507372] wlcore: loaded
[ 34.909463] wlcore: PHY firmware version: Rev 8.2.0.0.236
[ 34.961172] wlcore: firmware booted (Rev 8.9.0.0.69)
[ 34.989579] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 35.386337] wlcore: down
[ 36.388055] wlcore: down
[ 36.458640] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 36.488482] device wlan0 entered promiscuous mode
[ 36.689006] tether: port 1(wlan0) entered forwarding state
[ 36.694649] tether: port 1(wlan0) entered forwarding state

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/eeb801eadd3ce8e5c22b803727499807fcdd9a84

i need to update the cm3-fw, then i'll tag this and push it out...

Regards,

While we wait for the kernel to build and get pushed out via apt, you
can run this to update the *.dtb's..

debian@beaglebone:~$ git clone -b 4.4-ti
https://github.com/RobertCNelson/dtb-rebuilder
Cloning into 'dtb-rebuilder'...
remote: Counting objects: 7564, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 7564 (delta 4), reused 0 (delta 0), pack-reused 7547
Receiving objects: 100% (7564/7564), 5.12 MiB | 1.96 MiB/s, done.
Resolving deltas: 100% (3507/3507), done.
Checking connectivity... done.
debian@beaglebone:~$ cd dtb-rebuilder/
debian@beaglebone:~/dtb-rebuilder$ make ; sudo make install

and reboot..

Regards,

I installed build BBGW-blank-debian-8.6-seeed-iot-armhf-2016-09-18-4gb tonight. But I cannot get WIFI to work at all with this build. I think the most recent changes have made things worse.

On both cold and warm boot, the serial console spits out the same message every few seconds:

wlcore: ERROR firmware boot failed despite 3 retries

/var/log/syslog has lots of repeating messages, such as:

Sep 18 18:47:24 beaglebone wifidog_server[3940]: [3][Sun Sep 18 18:47:24 2016]3943 Could not create web server: Cannot assign requested address
Sep 18 18:47:24 beaglebone systemd[1]: wifidog-gateway.service: Main process exited, code=exited, status=1/FAILURE
Sep 18 18:47:24 beaglebone systemd[1]: wifidog-gateway.service: Unit entered failed state.
Sep 18 18:47:25 beaglebone systemd[1]: wifidog-gateway.service: Failed with result ‘exit-code’.
Sep 18 18:47:28 beaglebone systemd[1]: wifidog-pre-startup.service: Service hold-off time over, scheduling restart.

This is the latest build freshly installed on the BBGW. I’ve not run any commands yet except for “cat” and “ifconfig” to see what interfaces are available (lo and usb0).

Hello, Robert I have BBGW with Debian image of 2016-05-27, what’s the best way to apply this fix for Wifi module powerup onto that existing image? I’ve done:

./update_kernel.sh --lts-4_4 --ti-channel

and

~/dtb-rebuilder$ make ; sudo make install

both took, I’ve rebooted and confirmed kernel version has changed:

~$ uname -a

Linux beaglebone 4.4.22-ti-r48 #1 SMP Tue Sep 27 22:40:34 UTC 2016 armv7l GNU/Linux

currently Wifi module is not being recognized, no wlcore statements in dmesg, just one error that seems related:

mmc2: error -5 whilst initialising SDIO card

Yeah, i'm seeing that too..

I have a few bbgw's, that work great with the led-on power setup,
while others that work great with the mmc regulator control..

A few guy's at ti are looking into this still.

But till then, (starting with 4.4.22-ti-rt-r49/4.4.22-ti-r49) both
options will be available. * it's building right now, should be out in
a couple hours..

(the old way)
dtb=am335x-bonegreen-wireless.dtb

(the led-on way (this is the method we've been testing this week))
dtb=am335x-bonegreen-wireless-led-hack.dtb

Regards,

Where does this line go if I want to go back to the old way? In /boot/uEnv.txt or somewhere else?

Stéphane

When I first plug power into my BBGW, everything works great. But if I issue a “reboot” or “shutdown -r now” command, when the device boots back up I have no wifi.

This morning, TI finally replied to me on their forum in regards to this ongoing wifi problem. While I understand the meaning in the message, I don’t have the skills to know what to do with this information. Here is what they had to say:

I believe we have found the root cause for the BBGW wifi related issues.
Bottom line is that BT_AUD_OUT from wl1835 has to be pulled low when WL_EN is activated.
in case it isn’t, wilink8 ends up in one of the test modes that introduces various issues (elp wakeup timeouts etc.)
On the BBGW this pin is routed through the level shifter (U21) that introduces a pullup on the line and wilink8 ends up in a bad state.
To work around this, I have used a gpio hog to force this pin low.
An alternative may be adding an external pulldown on U21 pin 4 but this would require an ECO.

Please see section 10.4 in the following document:
http://www.ti.com/lit/ug/swru437/swru437.pdf

You can see that AUD_OUT_BT has to be 0 when BT or WLAN enable bit is set to high.

BR,
Eyal

Stéphane

When I first plug power into my BBGW, everything works great. But if I issue a “reboot” or “shutdown -r now” command, when the device boots back up I have no wifi.

This morning, TI finally replied to me on their forum in regards to this ongoing wifi problem. While I understand the meaning in the message, I don’t have the skills to know what to do with this information. Here is what they had to say:

I believe we have found the root cause for the BBGW wifi related issues.
Bottom line is that BT_AUD_OUT from wl1835 has to be pulled low when WL_EN is activated.
in case it isn’t, wilink8 ends up in one of the test modes that introduces various issues (elp wakeup timeouts etc.)
On the BBGW this pin is routed through the level shifter (U21) that introduces a pullup on the line and wilink8 ends up in a bad state.
To work around this, I have used a gpio hog to force this pin low.
An alternative may be adding an external pulldown on U21 pin 4 but this would require an ECO.

Please see section 10.4 in the following document:
http://www.ti.com/lit/ug/swru437/swru437.pdf

You can see that AUD_OUT_BT has to be 0 when BT or WLAN enable bit is set to high.

BR,
Eyal

Note that Robert has already incorporated the recommended work-around from the TI WiFi team:

https://github.com/RobertCNelson/dtb-rebuilder/commit/a0c693246e1abcbb3ed58f5a7319c6250416736c