Hi Arend,
I watch the linux-sunxi list where we're trying to support a certain
family of ARM chips and the boards they're on with open source,
community maintained kernels. They're at the cheaper end of the
spectrum so they usually end up with chipsets which are bought for
their price point and Android compatibility, not their ease of use by
people doing "generic" Linux.
On Fri, Dec 6, 2013 at 2:27 AM, Olliver Schinagl
<[email protected]> wrote:
> On 05-12-13 14:25, Neal Peacock wrote:
>>
>>
>> On Dec 5, 2013 4:02 AM, "Olliver Schinagl" <[email protected]
>> <mailto:oliver%[email protected]>> wrote:
>> >
>> > Hey Benn,
>> >
>> > it appears as if the bluetooth module requires specific firmware to
>> operate, it's likly the FM module requires it too?
>> >
>> > Can you confirm this or wether the firmware for the wifi module also
>> contains the BT and FM firmwares?
>> >
>> Which WiFi chip is this for?
>
> Wifi is mostly handled by extracting it from the broadcom drivers I belive
> via a script, but BT we are in the dark for.
So, the AMPAK AP6210 Wifi+BT combo device contains one of:
1. BCM43362 / BCM20710
2. BCM4330 / BCM40183
3. BCM4329 / BCM40181
Depending on who you talk to. I can only find one reference for
options #1 and #3, so I suspect it's the BCM4330 based chipset,
however I don't have one of these I can crack open so I'm not sure.
Firstly, are there any plans to support the BCM43362 chipset with the
brcmfmac driver in the near future?
Secondly, is there an upstream driver for the bluetooth parts of these
chipsets, and if so, do we need firmware and where can we get it from?
If there isn't, are there any plans to add support for them?
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
Hi,
On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <[email protected]> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>> brcmfmac driver in the near future?
>>>>>
>>>>> Hi Julian,
>>>>>
>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>> Just have to go after a firmware image to be sure.
>>>>
>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>
>>> No cubietruck here. I googled the term last week because it came up and
>>> found embeddedcomputer.nl selling it.
>>>
>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>> nice if we could also get the wifi and bluetooth to work here.
>
> I got the chip to respond to probing. It is BCM43362 for sure.
>
> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
> 0xa962
> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
> 0x02d0
>
> Vendor ID is Broadcom. Device ID is 43362.
> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
> if this is normal or not.
Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
brcmfmac driver. I only tested managed mode. Monitor mode does not work.
You can use firmware from CubieTech images.
Things missing:
1. output clock is using default 32KHz from 24M / 750.
need to find some place to put clk_set_rate call.
2. BCM43362 out-of-band interrupts not supported.
OOB interrupt in brcmfmac is set using platform data.
Need to put this is board code, or add device tree support.
Core ID and addresses were found using bcmdhd driver debug output.
Arend might want to take a look at the patch:
https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
Working tree:
https://github.com/wens/linux/tree/wip/sunxi-next-wifi
Comments welcome :)
ChenYu
>
> Bluetooth still isn't responding.
Bluetooth still not working. :(
Has anyone had any luck with this?
>
>>>> I'm certainly willing to give some patches for this a try. Do you
>>>> have an example of what the dts file for a board with broadcom sdio
>>>> wifi looks like ?
>>>
>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>> the cubietruck uses AP6210 module and the dts really depends on how
>>> things are wired up with it. Apart from the SDIO lines it may have an
>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>> host and interrupt line.
>>
>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>> to the driver. Last, it takes a clock output out of the A20 for the
>> low power 32k clock. Not sure if this is mandatory?
>>
>> I've read the schematics more than a few times. I can get a dts out
>> tomorrow. I was planning on doing the clock output and rfkill part
>> first.
>
> Here's my tree, in case anyone wants to play around. It will be rebased
> a lot.
>
> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> The DT is not finished yet. External interrupts and low power clock are
> still missing. Can anyone provide an example for useing the PIO EINT
> interrupt pins?
>
>
> Cheers,
>
> ChenYu
On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <[email protected]> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>> brcmfmac driver in the near future?
>>>>>>
>>>>>> Hi Julian,
>>>>>>
>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>> Just have to go after a firmware image to be sure.
>>>>>
>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>
>>>> No cubietruck here. I googled the term last week because it came up and
>>>> found embeddedcomputer.nl selling it.
>>>>
>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I got the chip to respond to probing. It is BCM43362 for sure.
>>
>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>> 0xa962
>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>> 0x02d0
>>
>> Vendor ID is Broadcom. Device ID is 43362.
>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>> if this is normal or not.
There might be three devices/functions. The last digit of the device
indicates the SDIO function number. Function 1 allows access to F1
registers in the SDIO core of the device and F2 is for WLAN
functionality. F3 could be providing BT functionality, but I am not
familiar with that part.
> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
> You can use firmware from CubieTech images.
brcmfmac does not support monitor mode. It does support AP mode and P2P
modes.
> Things missing:
>
> 1. output clock is using default 32KHz from 24M / 750.
> need to find some place to put clk_set_rate call.
What clock is this? You mean there is a clock output driven by the
AP6210 module or Cubieboard provides it to the module.
> 2. BCM43362 out-of-band interrupts not supported.
> OOB interrupt in brcmfmac is set using platform data.
> Need to put this is board code, or add device tree support.
It would be good to add device tree support so the driver can first look
for device tree data and have platform data and in-band as backup mechanism.
> Core ID and addresses were found using bcmdhd driver debug output.
> Arend might want to take a look at the patch:
>
> https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
I have different addresses from the chip documentation, but my test spin
went poorly. So much for hardware documentation. I will give these
values a try. In my patch there is also bcm43362 specific SDIO drive
strength programming (see attachment). The patch won't apply as my tree
is a bit different due to some rework in the SDIO part of brcmfmac. So
you probably need to pick the missing part from it.
> Working tree:
>
> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> Comments welcome :)
No comment, but: Nice work!
Gr. AvS
>>
>> Bluetooth still isn't responding.
>
> Bluetooth still not working. :(
> Has anyone had any luck with this?
>
>>
>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>> wifi looks like ?
>>>>
>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>> host and interrupt line.
>>>
>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>> to the driver. Last, it takes a clock output out of the A20 for the
>>> low power 32k clock. Not sure if this is mandatory?
>>>
>>> I've read the schematics more than a few times. I can get a dts out
>>> tomorrow. I was planning on doing the clock output and rfkill part
>>> first.
>>
>> Here's my tree, in case anyone wants to play around. It will be rebased
>> a lot.
>>
>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>
>> The DT is not finished yet. External interrupts and low power clock are
>> still missing. Can anyone provide an example for useing the PIO EINT
>> interrupt pins?
>>
>>
>> Cheers,
>>
>> ChenYu
On 12/05/2013 10:46 PM, Julian Calaby wrote:
> Firstly, are there any plans to support the BCM43362 chipset with the
> brcmfmac driver in the near future?
Hi Julian,
I am working on a patch to support this chip. It is looking promising.
Just have to go after a firmware image to be sure.
Gr. AvS
Hi,
On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <[email protected]> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>> brcmfmac driver in the near future?
>>>>>>
>>>>>> Hi Julian,
>>>>>>
>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>> Just have to go after a firmware image to be sure.
>>>>>
>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>
>>>> No cubietruck here. I googled the term last week because it came up and
>>>> found embeddedcomputer.nl selling it.
>>>>
>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I got the chip to respond to probing. It is BCM43362 for sure.
>>
>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>> 0xa962
>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>> 0x02d0
>>
>> Vendor ID is Broadcom. Device ID is 43362.
>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>> if this is normal or not.
>
> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
> You can use firmware from CubieTech images.
>
> Things missing:
>
> 1. output clock is using default 32KHz from 24M / 750.
> need to find some place to put clk_set_rate call.
>
> 2. BCM43362 out-of-band interrupts not supported.
> OOB interrupt in brcmfmac is set using platform data.
> Need to put this is board code, or add device tree support.
>
> Core ID and addresses were found using bcmdhd driver debug output.
> Arend might want to take a look at the patch:
>
> https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>
> Working tree:
>
> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> Comments welcome :)
Awesome! So now we have this working in upstream before we have it working with
3.4 kernels (at-least I've never managed to get it to work with 3.4 kernels).
Very nice Christmas present, thanks :)
I'll give this a spin and add it to the sunxi-devel branch.
Regards,
Hans
Hi,
On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel <[email protected]> wrote:
> On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <[email protected]> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>>> brcmfmac driver in the near future?
>>>>>>>
>>>>>>> Hi Julian,
>>>>>>>
>>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>>> Just have to go after a firmware image to be sure.
>>>>>>
>>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>>
>>>>> No cubietruck here. I googled the term last week because it came up and
>>>>> found embeddedcomputer.nl selling it.
>>>>>
>>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>>> nice if we could also get the wifi and bluetooth to work here.
>>>
>>> I got the chip to respond to probing. It is BCM43362 for sure.
>>>
>>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>> 0xa962
>>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>> 0x02d0
>>>
>>> Vendor ID is Broadcom. Device ID is 43362.
>>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>>> if this is normal or not.
>
> There might be three devices/functions. The last digit of the device
> indicates the SDIO function number. Function 1 allows access to F1
> registers in the SDIO core of the device and F2 is for WLAN
> functionality. F3 could be providing BT functionality, but I am not
> familiar with that part.
>
>> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
>> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
>> You can use firmware from CubieTech images.
>
> brcmfmac does not support monitor mode. It does support AP mode and P2P
> modes.
>
>> Things missing:
>>
>> 1. output clock is using default 32KHz from 24M / 750.
>> need to find some place to put clk_set_rate call.
>
> What clock is this? You mean there is a clock output driven by the
> AP6210 module or Cubieboard provides it to the module.
Cubieboard provides it to the module.
BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz
clock as low power clock. They can also use internal oscillator for
this, so it is optional. But according to BCM20710 datasheet, this
external clock is required to auto-detect the frequency of the main
oscillator if it's not the default 20MHz. On the CubieTruck, it is
26 MHz. For just WiFi, I think we don't need it.
>> 2. BCM43362 out-of-band interrupts not supported.
>> OOB interrupt in brcmfmac is set using platform data.
>> Need to put this is board code, or add device tree support.
>
> It would be good to add device tree support so the driver can first look
> for device tree data and have platform data and in-band as backup mechanism.
I'm not sure how to add support. Add a child node to the SD/MMC
controller, perhaps? I thought SDIO devices were like USB, in
that the system scans the bus and detects them.
>> Core ID and addresses were found using bcmdhd driver debug output.
>> Arend might want to take a look at the patch:
>>
>> https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>
> I have different addresses from the chip documentation, but my test spin
> went poorly. So much for hardware documentation. I will give these
> values a try. In my patch there is also bcm43362 specific SDIO drive
> strength programming (see attachment). The patch won't apply as my tree
> is a bit different due to some rework in the SDIO part of brcmfmac. So
> you probably need to pick the missing part from it.
Maybe it's a remarked chip? (is that possible?)
The firmware CubieTech has is for a BCM40181 though.
Added the drive strength programming by hand. Changed the table variable
name to match the others. Pushed on to my tree. Beware there are some
hacks trying to get BT to work. :p
>
>> Working tree:
>>
>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>
>> Comments welcome :)
>
> No comment, but: Nice work!
Thanks. BTW, who should submit the patch? :)
ChenYu
>
> Gr. AvS
>
>>>
>>> Bluetooth still isn't responding.
>>
>> Bluetooth still not working. :(
>> Has anyone had any luck with this?
>>
>>>
>>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>>> wifi looks like ?
>>>>>
>>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>>> host and interrupt line.
>>>>
>>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>>> to the driver. Last, it takes a clock output out of the A20 for the
>>>> low power 32k clock. Not sure if this is mandatory?
>>>>
>>>> I've read the schematics more than a few times. I can get a dts out
>>>> tomorrow. I was planning on doing the clock output and rfkill part
>>>> first.
>>>
>>> Here's my tree, in case anyone wants to play around. It will be rebased
>>> a lot.
>>>
>>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>
>>> The DT is not finished yet. External interrupts and low power clock are
>>> still missing. Can anyone provide an example for useing the PIO EINT
>>> interrupt pins?
>>>
>>>
>>> Cheers,
>>>
>>> ChenYu
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
Hi,
On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>> brcmfmac driver in the near future?
>>>
>>> Hi Julian,
>>>
>>> I am working on a patch to support this chip. It is looking promising.
>>> Just have to go after a firmware image to be sure.
>>
>> Cool. Do you have a cubietruck? With my latest wip tree:
>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>
> No cubietruck here. I googled the term last week because it came up and
> found embeddedcomputer.nl selling it.
>
>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I'm certainly willing to give some patches for this a try. Do you
>> have an example of what the dts file for a board with broadcom sdio
>> wifi looks like ?
>
> I am still struggling with dts changes for a Pandaboard. As I understood
> the cubietruck uses AP6210 module and the dts really depends on how
> things are wired up with it. Apart from the SDIO lines it may have an
> additional GPIO output to power the module and GPIO inputs to wakeup the
> host and interrupt line.
Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
to the driver. Last, it takes a clock output out of the A20 for the
low power 32k clock. Not sure if this is mandatory?
I've read the schematics more than a few times. I can get a dts out
tomorrow. I was planning on doing the clock output and rfkill part
first.
Regards,
ChenYu
>
>> Regards,
>>
>> Hans
>>
>>
>> p.s.
>>
>> Your last name seems Dutch, are you Dutch, and if so, are you
>> located in the Netherlands?
>
> Geboren en getogen. We hebben idd een Broadcom vestiging in Nederland.
>
> Gr. AvS
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
Hi,
On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>> brcmfmac driver in the near future?
>>>>
>>>> Hi Julian,
>>>>
>>>> I am working on a patch to support this chip. It is looking promising.
>>>> Just have to go after a firmware image to be sure.
>>>
>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>
>> No cubietruck here. I googled the term last week because it came up and
>> found embeddedcomputer.nl selling it.
>>
>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>> nice if we could also get the wifi and bluetooth to work here.
I got the chip to respond to probing. It is BCM43362 for sure.
root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
0xa962
root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
0x02d0
Vendor ID is Broadcom. Device ID is 43362.
But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
if this is normal or not.
Bluetooth still isn't responding.
>>> I'm certainly willing to give some patches for this a try. Do you
>>> have an example of what the dts file for a board with broadcom sdio
>>> wifi looks like ?
>>
>> I am still struggling with dts changes for a Pandaboard. As I understood
>> the cubietruck uses AP6210 module and the dts really depends on how
>> things are wired up with it. Apart from the SDIO lines it may have an
>> additional GPIO output to power the module and GPIO inputs to wakeup the
>> host and interrupt line.
>
> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
> to the driver. Last, it takes a clock output out of the A20 for the
> low power 32k clock. Not sure if this is mandatory?
>
> I've read the schematics more than a few times. I can get a dts out
> tomorrow. I was planning on doing the clock output and rfkill part
> first.
Here's my tree, in case anyone wants to play around. It will be rebased
a lot.
https://github.com/wens/linux/tree/wip/sunxi-next-wifi
The DT is not finished yet. External interrupts and low power clock are
still missing. Can anyone provide an example for useing the PIO EINT
interrupt pins?
Cheers,
ChenYu
On 12/18/2013 02:12 PM, Hans de Goede wrote:
> Hi,
>
> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>> brcmfmac driver in the near future?
>>
>> Hi Julian,
>>
>> I am working on a patch to support this chip. It is looking promising.
>> Just have to go after a firmware image to be sure.
>
> Cool. Do you have a cubietruck? With my latest wip tree:
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
No cubietruck here. I googled the term last week because it came up and
found embeddedcomputer.nl selling it.
> We've mmc/sdio controller support on top of 3.13-rc4, it would be
> nice if we could also get the wifi and bluetooth to work here.
>
> I'm certainly willing to give some patches for this a try. Do you
> have an example of what the dts file for a board with broadcom sdio
> wifi looks like ?
I am still struggling with dts changes for a Pandaboard. As I understood
the cubietruck uses AP6210 module and the dts really depends on how
things are wired up with it. Apart from the SDIO lines it may have an
additional GPIO output to power the module and GPIO inputs to wakeup the
host and interrupt line.
> Regards,
>
> Hans
>
>
> p.s.
>
> Your last name seems Dutch, are you Dutch, and if so, are you
> located in the Netherlands?
Geboren en getogen. We hebben idd een Broadcom vestiging in Nederland.
Gr. AvS
On 12/05/2013 10:46 PM, Julian Calaby wrote:
> Hi Arend,
>
> I watch the linux-sunxi list where we're trying to support a certain
> family of ARM chips and the boards they're on with open source,
> community maintained kernels. They're at the cheaper end of the
> spectrum so they usually end up with chipsets which are bought for
> their price point and Android compatibility, not their ease of use by
> people doing "generic" Linux.
>
> On Fri, Dec 6, 2013 at 2:27 AM, Olliver Schinagl
> <[email protected]> wrote:
>> On 05-12-13 14:25, Neal Peacock wrote:
>>>
>>>
>>> On Dec 5, 2013 4:02 AM, "Olliver Schinagl" <[email protected]
>>> <mailto:oliver%[email protected]>> wrote:
>>> >
>>> > Hey Benn,
>>> >
>>> > it appears as if the bluetooth module requires specific firmware to
>>> operate, it's likly the FM module requires it too?
>>> >
>>> > Can you confirm this or wether the firmware for the wifi module also
>>> contains the BT and FM firmwares?
>>> >
>>> Which WiFi chip is this for?
>>
>> Wifi is mostly handled by extracting it from the broadcom drivers I belive
>> via a script, but BT we are in the dark for.
>
> So, the AMPAK AP6210 Wifi+BT combo device contains one of:
> 1. BCM43362 / BCM20710
> 2. BCM4330 / BCM40183
> 3. BCM4329 / BCM40181
>
> Depending on who you talk to. I can only find one reference for
> options #1 and #3, so I suspect it's the BCM4330 based chipset,
> however I don't have one of these I can crack open so I'm not sure.
All these options are SDIO, right?
> Firstly, are there any plans to support the BCM43362 chipset with the
> brcmfmac driver in the near future?
We had someone from the community asking about that earlier and it
looked trivial to add it. I will get back on this.
> Secondly, is there an upstream driver for the bluetooth parts of these
> chipsets, and if so, do we need firmware and where can we get it from?
> If there isn't, are there any plans to add support for them?
The BT part is done by another group within broadcom so I have no idea
about their plans. I suspect they can be supported by generic btsdio
driver, but I may be totally mistaken.
Gr. AvS
Hi,
On 12/18/2013 11:31 AM, Arend van Spriel wrote:
> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>> Firstly, are there any plans to support the BCM43362 chipset with the
>> brcmfmac driver in the near future?
>
> Hi Julian,
>
> I am working on a patch to support this chip. It is looking promising.
> Just have to go after a firmware image to be sure.
Cool. Do you have a cubietruck? With my latest wip tree:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
We've mmc/sdio controller support on top of 3.13-rc4, it would be
nice if we could also get the wifi and bluetooth to work here.
I'm certainly willing to give some patches for this a try. Do you
have an example of what the dts file for a board with broadcom sdio
wifi looks like ?
Regards,
Hans
p.s.
Your last name seems Dutch, are you Dutch, and if so, are you
located in the Netherlands?
Hi,
On Fri, Jan 3, 2014 at 12:52 AM, Michal Suchanek <[email protected]> wrote:
> Hello,
>
> On 19 December 2013 11:12, Chen-Yu Tsai <[email protected]> wrote:
[snip]
>> Bluetooth still isn't responding.
>>
>
> Well, bluetooth is supposed to be attached to an UART, not SDIO.
> That's what the datasheets of the chip I found looked like.
Correct. CubieTruck schematics indicate it's connected to UART2.
> Not sure how firmware is supposed to fit in in this case but this
> would not be the first serial BT chip requiring firmware, would it?
Broadcom has a utility called brcm_patchram_plus that loads the
firmware. However I can't get my chip to respond to its first
reset command.
ChenYu
On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel <[email protected]> wrote:
>> On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>>>> brcmfmac driver in the near future?
>>>>>>>>
>>>>>>>> Hi Julian,
>>>>>>>>
>>>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>>>> Just have to go after a firmware image to be sure.
>>>>>>>
>>>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>>>
>>>>>> No cubietruck here. I googled the term last week because it came up and
>>>>>> found embeddedcomputer.nl selling it.
>>>>>>
>>>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>>>> nice if we could also get the wifi and bluetooth to work here.
>>>>
>>>> I got the chip to respond to probing. It is BCM43362 for sure.
>>>>
>>>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>>> 0xa962
>>>> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>>> 0x02d0
>>>>
>>>> Vendor ID is Broadcom. Device ID is 43362.
>>>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>>>> if this is normal or not.
>>
>> There might be three devices/functions. The last digit of the device
>> indicates the SDIO function number. Function 1 allows access to F1
>> registers in the SDIO core of the device and F2 is for WLAN
>> functionality. F3 could be providing BT functionality, but I am not
>> familiar with that part.
>>
>>> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
>>> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
>>> You can use firmware from CubieTech images.
>>
>> brcmfmac does not support monitor mode. It does support AP mode and P2P
>> modes.
>>
>>> Things missing:
>>>
>>> 1. output clock is using default 32KHz from 24M / 750.
>>> need to find some place to put clk_set_rate call.
>>
>> What clock is this? You mean there is a clock output driven by the
>> AP6210 module or Cubieboard provides it to the module.
>
> Cubieboard provides it to the module.
>
> BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz
> clock as low power clock. They can also use internal oscillator for
> this, so it is optional. But according to BCM20710 datasheet, this
> external clock is required to auto-detect the frequency of the main
> oscillator if it's not the default 20MHz. On the CubieTruck, it is
> 26 MHz. For just WiFi, I think we don't need it.
>
>>> 2. BCM43362 out-of-band interrupts not supported.
>>> OOB interrupt in brcmfmac is set using platform data.
>>> Need to put this is board code, or add device tree support.
>>
>> It would be good to add device tree support so the driver can first look
>> for device tree data and have platform data and in-band as backup mechanism.
>
> I'm not sure how to add support. Add a child node to the SD/MMC
> controller, perhaps? I thought SDIO devices were like USB, in
> that the system scans the bus and detects them.
>
>>> Core ID and addresses were found using bcmdhd driver debug output.
>>> Arend might want to take a look at the patch:
>>>
>>> https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>>
>> I have different addresses from the chip documentation, but my test spin
>> went poorly. So much for hardware documentation. I will give these
>> values a try. In my patch there is also bcm43362 specific SDIO drive
>> strength programming (see attachment). The patch won't apply as my tree
>> is a bit different due to some rework in the SDIO part of brcmfmac. So
>> you probably need to pick the missing part from it.
>
> Maybe it's a remarked chip? (is that possible?)
> The firmware CubieTech has is for a BCM40181 though.
>
> Added the drive strength programming by hand. Changed the table variable
> name to match the others. Pushed on to my tree. Beware there are some
> hacks trying to get BT to work. :p
>
>>
>>> Working tree:
>>>
>>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>
>>> Comments welcome :)
>>
>> No comment, but: Nice work!
>
> Thanks. BTW, who should submit the patch? :)
Hi Chen-Yu,
I confirmed the patch is working with a revision 0 of the device. What
chip revision does it give in your log (need to load brcmfmac with
module parameter debug=4).
Regards,
Arend
>>
>>>>
>>>> Bluetooth still isn't responding.
>>>
>>> Bluetooth still not working. :(
>>> Has anyone had any luck with this?
>>>
>>>>
>>>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>>>> wifi looks like ?
>>>>>>
>>>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>>>> host and interrupt line.
>>>>>
>>>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>>>> to the driver. Last, it takes a clock output out of the A20 for the
>>>>> low power 32k clock. Not sure if this is mandatory?
>>>>>
>>>>> I've read the schematics more than a few times. I can get a dts out
>>>>> tomorrow. I was planning on doing the clock output and rfkill part
>>>>> first.
>>>>
>>>> Here's my tree, in case anyone wants to play around. It will be rebased
>>>> a lot.
>>>>
>>>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>
>>>> The DT is not finished yet. External interrupts and low power clock are
>>>> still missing. Can anyone provide an example for useing the PIO EINT
>>>> interrupt pins?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ChenYu
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 01/08/2014 10:23 AM, Chen-Yu Tsai wrote:
> On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <[email protected]> wrote:
>> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>>>>> Working tree:
>>>>>>>
>>>>>>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>>>>
>>>>>>> Comments welcome :)
>>>>>
>>>>> No comment, but: Nice work!
>>> Thanks. BTW, who should submit the patch? :)
>>
>> Hi Chen-Yu
>>
>> I will submit the patch today.
>
> Great!
>
> I added device tree support for brcmfmac SDIO devices,
> to be able to specify external out-of-band interrupts.
> Unfortunately it's not working. I get the following output:
>
> brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
> brcmfmac: brcmf_fil_cmd_data: Failed err=-110
> brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
> brcmfmac: brcmf_bus_start: failed: -110
> brcmfmac: brcmf_sdbrcm_probe: dongle is not responding
This is typeical behaviour when interrupt is not picked up.
> brcmfmac: brcmf_sdio_probe: device attach failed
> brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
>
> Should we add device tree support for the brcmf platform driver,
> so we can enable power, clocks, etc. before the SDIO driver is probed?
How does the device-tree change for oob interrupt look like.
> Not sure if this is the right way. Maxime mentioned on IRC that some
> mmc host drivers take a vmmc regulator property.
>
> Currently I am using rfkill-gpio to do this. But brcmfmac also
> registers an rfkill of its own.
Not sure what you mean here. The only thing I am aware of is that
cfg80211 registers brcmfmac as wifi transmitter in the rfkill framework,
which is unrelated to gpio's.
> Also, I have bluetooth working. Turns out it was a wrong pinctrl
> setting in my dt. For those who want to try:
>
> Get and compile brcm_patchram_plus from
> http://code.google.com/p/broadcom-bluetooth/
>
> Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
> and hciattach /dev/ttyS1
>
> If brcm_patchram_plus hangs, you may need to reset the controller
> by blocking then unblocking the bluetooth rfkill switch.
>
> I pushed all my work out already. Here's the link again:
>
> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
I will take a look.
Gr. AvS
On 01/24/2014 05:34 PM, Hans de Goede wrote:
> Hi,
>
> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> I've been working on updating sunxi-devel to include more
>>> recent versions if your gmac patches, as well as adding support
>>> for the wifi + bluetooth found on the cubietruck.
>>>
>>> Here is my current work on this:
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>
>>> It is close to working, but unfortunately it does not work,
>>> here is what I get in dmesg when I modprove the module:
>>>
>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>
>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>> a look.
>
> I've captured a log with these flags until the first "Scanning already"
> message, you can find it here:
Hi Hans,
The log looks confusing.
[ 543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
[ 543.512840] brcmfmac: brcmf_fweh_event_worker version 2 flags 0
status 0 reason 0
[ 543.512849] brcmutil: event payload, len=12
[ 543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
....m...4...
[ 543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
[ 543.512880] brcmfmac: brcmf_notify_escan_complete Enter
[ 543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
scan: Done
[ 543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
[ 543.512919] brcmutil: data
[ 543.512928] 00000000: 01 00 00 00
....
[ 543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
[ 543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
[ 543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter
The trace messages above indicate completion of regular scan and after
that the code does:
if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");
[ 543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
n_match_sets:0 n_ssids:0
[ 543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
already: status (1)
So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
That makes no sense to me or test_and_clear_bit() does something else
than I expect. Either way the scheduled scan request would be rejected
because it has 0 match_sets and ssids. Maybe this is intended to
indicate any AP is to be reported. Will look in cfg80211 whether that is
the case.
Regards,
Arend
On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <[email protected]> wrote:
> [snip]
>> Hi Chen-Yu,
>>
>> I confirmed the patch is working with a revision 0 of the device. What
>> chip revision does it give in your log (need to load brcmfmac with
>> module parameter debug=4).
>
> Mine is revision 1. Managed mode confirmed working.
Which firmware did you use. Can you provide 'hexdump -C' output
(especially the last part).
Gr. AvS
> Logs:
> brcmfmac: F1 signature read @0x18000000=0x1591a962
> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
> rev/type=10/0x829
>
>
> ChenYu
>
Hi,
On 01/26/2014 01:58 PM, Arend van Spriel wrote:
> On 01/26/2014 11:23 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/26/2014 09:53 AM, Arend van Spriel wrote:
>>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've been working on updating sunxi-devel to include more
>>>>>> recent versions if your gmac patches, as well as adding support
>>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>>
>>>>>> Here is my current work on this:
>>>>>>
>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>>
>>>>>> It is close to working, but unfortunately it does not work,
>>>>>> here is what I get in dmesg when I modprove the module:
>>>>>>
>>>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>>> wl0:
>>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>
>>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>>> have
>>>>> a look.
>>>>
>>>> I've captured a log with these flags until the first "Scanning already"
>>>> message, you can find it here:
>>>
>>> Bedankt, Hans
>>>
>>> Looking at the log it looks more or less ok. wpa_supplicant (assume you
>>> use that) first does three regular scans which end with no APs found.
>>> Not sure why that happens unless you are in a shielded room :-) After
>>> those scans wpa_supplicant tries to tell the device to do a so-called
>>> scheduled scan. Basically, it is a scan offload. However, the driver
>>> still thinks there is a regular scan ongoing. This needs to be
>>> investigated more.
>>
>> Thanks for looking into this. I've nothing scheduled this entire Sunday
>> except working on hobby projects. If there is anything I can do to help,
>> you can find me in #linux-sunxi on freenode irc. My nick is hansg.
>>
>> I would really like to get this working, so feel free to poke me to run
>> any tests / debug log gathering exercises you think will be helpful.
>
> I did a quick diff between your brcmfmac folder and mine. I am curious
> what your results are after the merge window. There has been a lot of
> rework in SDIO part of brcmfmac driver.
Ok, I plan to rebase my tree on 3.14-rc1 when it is released. I'll run
some more tests then and let you know how things go.
Regards,
Hans
On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>> >> Working tree:
>>> >>
>>> >> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>> >>
>>> >> Comments welcome :)
>> >
>> > No comment, but: Nice work!
> Thanks. BTW, who should submit the patch? :)
Hi Chen-Yu
I will submit the patch today.
Regards,
Arend
On Wed, Jan 8, 2014 at 5:33 PM, Arend van Spriel <[email protected]> wrote:
> On 01/08/2014 10:23 AM, Chen-Yu Tsai wrote:
>> On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <[email protected]> wrote:
>>> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>>>>>> Working tree:
>>>>>>>>
>>>>>>>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>>>>>
>>>>>>>> Comments welcome :)
>>>>>>
>>>>>> No comment, but: Nice work!
>>>> Thanks. BTW, who should submit the patch? :)
>>>
>>> Hi Chen-Yu
>>>
>>> I will submit the patch today.
>>
>> Great!
>>
>> I added device tree support for brcmfmac SDIO devices,
>> to be able to specify external out-of-band interrupts.
>> Unfortunately it's not working. I get the following output:
>>
>> brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-110
>> brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
>> brcmfmac: brcmf_bus_start: failed: -110
>> brcmfmac: brcmf_sdbrcm_probe: dongle is not responding
>
> This is typeical behaviour when interrupt is not picked up.
Maxime said the pinctrl irq chip driver wasn't tested,
so not picking up an interrupt isn't a big surprise.
>> brcmfmac: brcmf_sdio_probe: device attach failed
>> brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
>>
>> Should we add device tree support for the brcmf platform driver,
>> so we can enable power, clocks, etc. before the SDIO driver is probed?
>
> How does the device-tree change for oob interrupt look like.
See https://github.com/wens/linux/blob/wip/sunxi-next-wifi/arch/arm/boot/dts/sun7i-a20-cubietruck.dts#L38
The platform driver device node would be something like:
/{
brcmf {
compatible = "broadcom,brcmf";
vbat-supply = <&wifi_pwr_regulator>;
/* maybe other regulators */
clocks = <&wifi_main>, <&wifi_lpo>;
clock-names = "main", "lpo";
reset-gpio = <&gpio A B C>;
};
};
>> Not sure if this is the right way. Maxime mentioned on IRC that some
>> mmc host drivers take a vmmc regulator property.
>>
>> Currently I am using rfkill-gpio to do this. But brcmfmac also
>> registers an rfkill of its own.
>
> Not sure what you mean here. The only thing I am aware of is that
> cfg80211 registers brcmfmac as wifi transmitter in the rfkill framework,
> which is unrelated to gpio's.
They are unrelated, but overlapping I suppose.
https://github.com/wens/linux/blob/wip/sunxi-next-wifi/arch/arm/boot/dts/sun7i-a20-cubietruck.dts#L220
Here I register a wifi rfkill that switches the brcmfmac device on or off.
If it is off the device disappears from the system. Not sure if the kernel
would detect it when we turn it back on.
IMO the rfkill framework by design should only turn off the RF part of the
device, not the controller altogether.
Feedback on this or other patches in my tree is much appreciated.
Thanks
ChenYu
>> Also, I have bluetooth working. Turns out it was a wrong pinctrl
>> setting in my dt. For those who want to try:
>>
>> Get and compile brcm_patchram_plus from
>> http://code.google.com/p/broadcom-bluetooth/
>>
>> Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
>> and hciattach /dev/ttyS1
>>
>> If brcm_patchram_plus hangs, you may need to reset the controller
>> by blocking then unblocking the bluetooth rfkill switch.
>>
>> I pushed all my work out already. Here's the link again:
>>
>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> I will take a look.
>
> Gr. AvS
Hi,
On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-)
Actually it seems that wifi reception in my room, combined with the low
yield of the chip antenna on the cubietruck is actually so bad that
it is possible for the list to show up empty.
I've verified this with the android image on the cubietruck, and after
moving the cubietruck around a bit to get better reception I now have
things working :)
I do wonder about the brcmf_fil_cmd_data errors though, IMHO those should
be avoided if possible.
Regards,
Hans
On 01/26/2014 11:23 AM, Hans de Goede wrote:
> Hi,
>
> On 01/26/2014 09:53 AM, Arend van Spriel wrote:
>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> I've been working on updating sunxi-devel to include more
>>>>> recent versions if your gmac patches, as well as adding support
>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>
>>>>> Here is my current work on this:
>>>>>
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>
>>>>> It is close to working, but unfortunately it does not work,
>>>>> here is what I get in dmesg when I modprove the module:
>>>>>
>>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>> wl0:
>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>
>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>> have
>>>> a look.
>>>
>>> I've captured a log with these flags until the first "Scanning already"
>>> message, you can find it here:
>>
>> Bedankt, Hans
>>
>> Looking at the log it looks more or less ok. wpa_supplicant (assume you
>> use that) first does three regular scans which end with no APs found.
>> Not sure why that happens unless you are in a shielded room :-) After
>> those scans wpa_supplicant tries to tell the device to do a so-called
>> scheduled scan. Basically, it is a scan offload. However, the driver
>> still thinks there is a regular scan ongoing. This needs to be
>> investigated more.
>
> Thanks for looking into this. I've nothing scheduled this entire Sunday
> except working on hobby projects. If there is anything I can do to help,
> you can find me in #linux-sunxi on freenode irc. My nick is hansg.
>
> I would really like to get this working, so feel free to poke me to run
> any tests / debug log gathering exercises you think will be helpful.
I did a quick diff between your brcmfmac folder and mine. I am curious
what your results are after the merge window. There has been a lot of
rework in SDIO part of brcmfmac driver.
Regards,
Arend
On 01/24/2014 05:34 PM, Hans de Goede wrote:
> Hi,
>
> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> I've been working on updating sunxi-devel to include more
>>> recent versions if your gmac patches, as well as adding support
>>> for the wifi + bluetooth found on the cubietruck.
>>>
>>> Here is my current work on this:
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>
>>> It is close to working, but unfortunately it does not work,
>>> here is what I get in dmesg when I modprove the module:
>>>
>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>
>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>> a look.
>
> I've captured a log with these flags until the first "Scanning already"
> message, you can find it here:
Bedankt, Hans
Looking at the log it looks more or less ok. wpa_supplicant (assume you
use that) first does three regular scans which end with no APs found.
Not sure why that happens unless you are in a shielded room :-) After
those scans wpa_supplicant tries to tell the device to do a so-called
scheduled scan. Basically, it is a scan offload. However, the driver
still thinks there is a regular scan ongoing. This needs to be
investigated more. I tried to get your repo from github, but got:
error: The requested URL returned error: 403 Forbidden while accessing
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel/info/refs
fatal: HTTP request failed
Gr. AvS
> http://people.fedoraproject.org/~jwrdegoede/log2
>
> Thanks for looking into this.
>
> Regards,
>
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
On 19 December 2013 11:12, Chen-Yu Tsai <[email protected]> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <[email protected]> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <[email protected]> wrote:
>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>> brcmfmac driver in the near future?
>>>>>
>>>>> Hi Julian,
>>>>>
>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>> Just have to go after a firmware image to be sure.
>>>>
>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>
>>> No cubietruck here. I googled the term last week because it came up and
>>> found embeddedcomputer.nl selling it.
>>>
>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>> nice if we could also get the wifi and bluetooth to work here.
>
> I got the chip to respond to probing. It is BCM43362 for sure.
>
> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
> 0xa962
> root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
> 0x02d0
>
> Vendor ID is Broadcom. Device ID is 43362.
> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
> if this is normal or not.
>
> Bluetooth still isn't responding.
>
Well, bluetooth is supposed to be attached to an UART, not SDIO.
That's what the datasheets of the chip I found looked like.
Not sure how firmware is supposed to fit in in this case but this
would not be the first serial BT chip requiring firmware, would it?
Thanks
Michal
Hi,
On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <[email protected]> wrote:
[snip]
> Hi Chen-Yu,
>
> I confirmed the patch is working with a revision 0 of the device. What
> chip revision does it give in your log (need to load brcmfmac with
> module parameter debug=4).
Mine is revision 1. Managed mode confirmed working.
Logs:
brcmfmac: F1 signature read @0x18000000=0x1591a962
brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
rev/type=10/0x829
ChenYu
Hi,
On 01/26/2014 12:04 PM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Hi Hans,
>
> The log looks confusing.
>
> [ 543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
> ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
> [ 543.512840] brcmfmac: brcmf_fweh_event_worker version 2 flags 0
> status 0 reason 0
> [ 543.512849] brcmutil: event payload, len=12
> [ 543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
> ....m...4...
> [ 543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
> [ 543.512880] brcmfmac: brcmf_notify_escan_complete Enter
> [ 543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
> scan: Done
> [ 543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
> [ 543.512919] brcmutil: data
> [ 543.512928] 00000000: 01 00 00 00
> ....
> [ 543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
> [ 543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
> [ 543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter
>
> The trace messages above indicate completion of regular scan and after
> that the code does:
>
> if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
> brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");
>
> [ 543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
> n_match_sets:0 n_ssids:0
> [ 543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
>
> So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
> That makes no sense to me or test_and_clear_bit() does something else
> than I expect.
Once I've successfully associated these messages go away, so it is
possible that this is a bug which has been around for a while, but people
normally never see because the code path is not entered.
Or could it be that this bug gets triggered by the regular scan turning
up with 0 access points, maybe that causes it to enter a path where it
does not clear the bit in question ?
Regards,
Hans
Hi,
On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-)
One last update, although everything works now, after some more testing
I'm also seeing these messages:
[ 262.533803] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4)
[ 262.540078] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5)
[ 1059.641594] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4)
[ 1059.647872] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5)
[ 1061.563182] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 1068.564755] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 1075.389881] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1075.396192] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[ 1078.172085] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1078.178394] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[ 1079.194131] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1079.200428] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
etc.
Regards,
Hans
Regards,
Hans
On 01/26/2014 01:09 PM, Hans de Goede wrote:
> Hi,
>
> On 01/26/2014 12:04 PM, Arend van Spriel wrote:
>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> I've been working on updating sunxi-devel to include more
>>>>> recent versions if your gmac patches, as well as adding support
>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>
>>>>> Here is my current work on this:
>>>>>
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>
>>>>> It is close to working, but unfortunately it does not work,
>>>>> here is what I get in dmesg when I modprove the module:
>>>>>
>>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>> wl0:
>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>
>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>> have
>>>> a look.
>>>
>>> I've captured a log with these flags until the first "Scanning already"
>>> message, you can find it here:
>>
>> Hi Hans,
>>
>> The log looks confusing.
>>
>> [ 543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
>> ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
>> [ 543.512840] brcmfmac: brcmf_fweh_event_worker version 2 flags 0
>> status 0 reason 0
>> [ 543.512849] brcmutil: event payload, len=12
>> [ 543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
>> ....m...4...
>> [ 543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
>> [ 543.512880] brcmfmac: brcmf_notify_escan_complete Enter
>> [ 543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
>> scan: Done
>> [ 543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
>> [ 543.512919] brcmutil: data
>> [ 543.512928] 00000000: 01 00 00 00
>> ....
>> [ 543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
>> [ 543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
>> [ 543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter
>>
>> The trace messages above indicate completion of regular scan and after
>> that the code does:
>>
>> if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
>> brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");
>>
>> [ 543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
>> n_match_sets:0 n_ssids:0
>> [ 543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>>
>> So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
>> That makes no sense to me or test_and_clear_bit() does something else
>> than I expect.
>
> Once I've successfully associated these messages go away, so it is
> possible that this is a bug which has been around for a while, but people
> normally never see because the code path is not entered.
>
> Or could it be that this bug gets triggered by the regular scan turning
> up with 0 access points, maybe that causes it to enter a path where it
> does not clear the bit in question ?
I think that is partly true or some trace messages were missing, but I
think the trigger is the 0 APs. Thanks for letting me know.
Regards,
Arend
On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> still thinks there is a regular scan ongoing. This needs to be
> investigated more. I tried to get your repo from github, but got:
>
> error: The requested URL returned error: 403 Forbidden while accessing
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel/info/refs
> fatal: HTTP request failed
Never mind. Was using the wrong URL.
Gr. AvS
On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <[email protected]> wrote:
> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>> >> Working tree:
>>>> >>
>>>> >> https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>> >>
>>>> >> Comments welcome :)
>>> >
>>> > No comment, but: Nice work!
>> Thanks. BTW, who should submit the patch? :)
>
> Hi Chen-Yu
>
> I will submit the patch today.
Great!
I added device tree support for brcmfmac SDIO devices,
to be able to specify external out-of-band interrupts.
Unfortunately it's not working. I get the following output:
brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
brcmfmac: brcmf_fil_cmd_data: Failed err=-110
brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
brcmfmac: brcmf_bus_start: failed: -110
brcmfmac: brcmf_sdbrcm_probe: dongle is not responding
brcmfmac: brcmf_sdio_probe: device attach failed
brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
Should we add device tree support for the brcmf platform driver,
so we can enable power, clocks, etc. before the SDIO driver is probed?
Not sure if this is the right way. Maxime mentioned on IRC that some
mmc host drivers take a vmmc regulator property.
Currently I am using rfkill-gpio to do this. But brcmfmac also
registers an rfkill of its own.
Also, I have bluetooth working. Turns out it was a wrong pinctrl
setting in my dt. For those who want to try:
Get and compile brcm_patchram_plus from
http://code.google.com/p/broadcom-bluetooth/
Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
and hciattach /dev/ttyS1
If brcm_patchram_plus hangs, you may need to reset the controller
by blocking then unblocking the bluetooth rfkill switch.
I pushed all my work out already. Here's the link again:
https://github.com/wens/linux/tree/wip/sunxi-next-wifi
Cheers
ChenYu
Hi,
I've been working on updating sunxi-devel to include more
recent versions if your gmac patches, as well as adding support
for the wifi + bluetooth found on the cubietruck.
Here is my current work on this:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
It is close to working, but unfortunately it does not work,
here is what I get in dmesg when I modprove the module:
[ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
[ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
[ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
[ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
[ 100.322508] usbcore: registered new interface driver brcmfmac
[ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
...
This is using the firmware + nvram found here:
http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/
Wens' can you give my tree a try? And which version of the firmware +
nvram are you using ?
Thanks & Regards,
Hans
Hi,
On Fri, Jan 3, 2014 at 5:03 AM, Arend van Spriel <[email protected]> wrote:
> On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <[email protected]> wrote:
>> [snip]
>>> Hi Chen-Yu,
>>>
>>> I confirmed the patch is working with a revision 0 of the device. What
>>> chip revision does it give in your log (need to load brcmfmac with
>>> module parameter debug=4).
>>
>> Mine is revision 1. Managed mode confirmed working.
>
> Which firmware did you use. Can you provide 'hexdump -C' output
> (especially the last part).
>
I used fw_bcm40181a2.bin.
MD5 sum: ce95e81aa95f9dc1a32fb8acf691dbd8 fw_bcm40181a2.bin
Here's the last part of the dump.
root@cubietruck:/lib/firmware/brcm# hexdump -C brcmfmac43362-sdio.bin | tail
00035920 01 bd 32 08 01 00 34 33 33 36 32 61 32 2d 72 6f |..2...43362a2-ro|
00035930 6d 6c 2f 73 64 69 6f 2d 67 2d 70 6e 6f 2d 70 6b |ml/sdio-g-pno-pk|
00035940 74 66 69 6c 74 65 72 2d 6b 65 65 70 61 6c 69 76 |tfilter-keepaliv|
00035950 65 2d 77 61 70 69 2d 77 6d 65 2d 70 32 70 20 56 |e-wapi-wme-p2p V|
00035960 65 72 73 69 6f 6e 3a 20 35 2e 39 30 2e 31 39 35 |ersion: 5.90.195|
00035970 2e 38 39 20 43 52 43 3a 20 62 64 31 65 33 65 35 |.89 CRC: bd1e3e5|
00035980 61 20 44 61 74 65 3a 20 4d 6f 6e 20 32 30 31 33 |a Date: Mon 2013|
00035990 2d 30 34 2d 32 32 20 31 37 3a 32 34 3a 34 34 20 |-04-22 17:24:44 |
000359a0 43 53 54 7d 00 |CST}.|
000359a5
ChenYu
> Gr. AvS
>
>> Logs:
>> brcmfmac: F1 signature read @0x18000000=0x1591a962
>> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
>> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
>> rev/type=10/0x829
>>
>>
>> ChenYu
>>
>
Hi,
On 01/24/2014 11:25 AM, Arend van Spriel wrote:
> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>> Hi,
>>
>> I've been working on updating sunxi-devel to include more
>> recent versions if your gmac patches, as well as adding support
>> for the wifi + bluetooth found on the cubietruck.
>>
>> Here is my current work on this:
>>
>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>
>> It is close to working, but unfortunately it does not work,
>> here is what I get in dmesg when I modprove the module:
>>
>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>
> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
> a look.
I've captured a log with these flags until the first "Scanning already"
message, you can find it here:
http://people.fedoraproject.org/~jwrdegoede/log2
Thanks for looking into this.
Regards,
Hans
On 01/23/2014 11:39 PM, Hans de Goede wrote:
> Hi,
>
> I've been working on updating sunxi-devel to include more
> recent versions if your gmac patches, as well as adding support
> for the wifi + bluetooth found on the cubietruck.
>
> Here is my current work on this:
>
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>
> It is close to working, but unfortunately it does not work,
> here is what I get in dmesg when I modprove the module:
>
> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> [ 100.322508] usbcore: registered new interface driver brcmfmac
> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
a look.
Regards,
Arend
Hi,
On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [ 99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [ 100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [ 100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [ 100.322508] usbcore: registered new interface driver brcmfmac
>>>> [ 160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [ 256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-) After
> those scans wpa_supplicant tries to tell the device to do a so-called
> scheduled scan. Basically, it is a scan offload. However, the driver
> still thinks there is a regular scan ongoing. This needs to be
> investigated more.
Thanks for looking into this. I've nothing scheduled this entire Sunday
except working on hobby projects. If there is anything I can do to help,
you can find me in #linux-sunxi on freenode irc. My nick is hansg.
I would really like to get this working, so feel free to poke me to run
any tests / debug log gathering exercises you think will be helpful.
Regards,
Hans