Older Duoveros (R3921 and 3922) running 3.18 kernel: Problem with built-in Wi-Fi and Bluetooth

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Older Duoveros (R3921 and 3922) running 3.18 kernel: Problem with built-in Wi-Fi and Bluetooth

Gumstix mailing list

The new Duovero Zephyr “Y” boards work well with the latest “stable” release (3.18.21-custom). I am watching the latest “morty” one build right now; with hopes that the problem I am having has already been resolved.

 

Using our older Duovero boards (with the Marvell 8787 Wi-Fi / Bluetooth chips) with 3.18.21, the built-in Wi-Fi and Bluetooth only work about half the time.

When starting hostapd, I frequently see timeout:

                “mwifiex_sdio mmc0:0001:1: cmd_wait_q terminated: 0” **

and a similar thing to get Bluetooth up: Some messages “BTCFG failed” (something like that) at power up. “hciconfig” shows hci0 DOWN, and:

                # hciconfig hci0 up

(wait about ten seconds here, everything BLOCKS…)

                “Can't init device hci0: Connection timed out (110)”

and hci0 is still DOWN (sometimes it says DOWN INITING or something like that) but it never comes up.

 

When it works it works well. But half of the time, no go: hostapd appears to be running – “systemctl status hostapd” reports its running -- but it’s not, and Bluetooth is down.

 

Rebooting / powering off and on doesn’t help anything; it just sort of randomly either works or not.

 

I have tried with three older Duovero boards (R3921 and R3922) and the same thing happens, so I don’t think it is hardware. If I change out the SD card back to the older 3.6 kernel then both Wi-Fi and Bluetooth work. (But then on the new “Y” boards, 3.6 doesn’t recognize the new TI built-in Wi-Fi / Bluetooth chip, so that’s out.)

 

Since it randomly works (or not), I’m wondering if maybe something just isn’t set up fully.

 

I looked at the *old way’s* ‘board-duovero.c’ and the *new way’s* omap4.dtsi files to see if there was some obvious difference; I discovered that neither of these were easy to read or comprehend (at least by me), and decided to ask the Gumstix experts.

 

I’m not even sure whether u-boot or the kernel sets up the pins anyway…

 

We want to update some units in the field to the newer “stable” release but can’t if it won’t be reliable.

 

Thanks for reading all the way through…

 

** - Should “mmc0:0001:1” be mmc5? Also not sure if it means anything but with hostapd running the “cmd_wait_q terminated” occurs almost exactly every ten minutes.

 

Brad Brancke

logo

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Older Duoveros (R3921 and 3922) running 3.18 kernel: Problem with built-in Wi-Fi and Bluetooth

Gumstix mailing list
I've been running 4.9 kernels with the older marvell wifi Duovero boards,
using them as APs in a test lab.

I am moving a lot of data through the Duoveros running fuzzing and some
and other security tests against some boards on the the Duovero's wifi.

I have not seen the mwifiex_sdio error you are reporting.

I am not using Bluetooth though.

I you are interested, you can grab the kernel config with a few wifi
patches I added mostly to reduce bogus messages here

For Yocto builds, [pyro] branch, it's the linux-stable_4.9.bb recipe here

  https://github.com/jumpnow/meta-duovero/tree/pyro/recipes-kernel/linux


For Buildroot, I am using the repo below, the [jumpnow] branch and the
jumpnow_duovero_defconfig

  https://github.com/jumpnow/buildroot

The kernel config and patches are the same as with Yocto and can be found
here

  https://github.com/jumpnow/buildroot/tree/jumpnow/board/jumpnow/duovero/linux/4.9





"General mailing list for gumstix users." <[hidden email]> said:

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
> The new Duovero Zephyr "Y" boards work well with the latest "stable" release
> (3.18.21-custom). I am watching the latest "morty" one build right now; with hopes
> that the problem I am having has already been resolved.
>
> Using our older Duovero boards (with the Marvell 8787 Wi-Fi / Bluetooth chips)
> with 3.18.21, the built-in Wi-Fi and Bluetooth only work about half the time.
> When starting hostapd, I frequently see timeout:
>                 "mwifiex_sdio mmc0:0001:1: cmd_wait_q terminated: 0" **
> and a similar thing to get Bluetooth up: Some messages "BTCFG failed" (something
> like that) at power up. "hciconfig" shows hci0 DOWN, and:
>                 # hciconfig hci0 up
> (wait about ten seconds here, everything BLOCKS...)
>                 "Can't init device hci0: Connection timed out (110)"
> and hci0 is still DOWN (sometimes it says DOWN INITING or something like that) but
> it never comes up.
>
> When it works it works well. But half of the time, no go: hostapd appears to be
> running - "systemctl status hostapd" reports its running -- but it's not, and
> Bluetooth is down.
>
> Rebooting / powering off and on doesn't help anything; it just sort of randomly
> either works or not.
>
> I have tried with three older Duovero boards (R3921 and R3922) and the same thing
> happens, so I don't think it is hardware. If I change out the SD card back to the
> older 3.6 kernel then both Wi-Fi and Bluetooth work. (But then on the new "Y"
> boards, 3.6 doesn't recognize the new TI built-in Wi-Fi / Bluetooth chip, so
> that's out.)
>
> Since it randomly works (or not), I'm wondering if maybe something just isn't set
> up fully.
>
> I looked at the *old way's* 'board-duovero.c' and the *new way's* omap4.dtsi files
> to see if there was some obvious difference; I discovered that neither of these
> were easy to read or comprehend (at least by me), and decided to ask the Gumstix
> experts.
>
> I'm not even sure whether u-boot or the kernel sets up the pins anyway...
>
> We want to update some units in the field to the newer "stable" release but can't
> if it won't be reliable.
>
> Thanks for reading all the way through...
>
> ** - Should "mmc0:0001:1" be mmc5? Also not sure if it means anything but with
> hostapd running the "cmd_wait_q terminated" occurs almost exactly every ten
> minutes.
>
> Brad Brancke
> [logo]
>
>



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Loading...