Hi,
I recently received a donated BCM43228 (14e4:4359) mini-PCIe card. At the
moment, neither b43 nor brcmsmac support it. Although, grepping the proprietary
driver wl shows that it would recognize that PCI ID, that driver does not load
as it requires routine lockdep_init_map(), which is exported only for GPL
modules. As a result, owners of this device can only use it with Linux if they
can find a suitable Windows driver for use with ndiswrapper. In my experience,
that means that 64-bit users are out of luck.
Reverse engineering this device to be able to drive it with b43 would involve a
lot of effort. If your group is planning on adding it to brcmsmac, then I would
not undertake this project. To the fullest extent that you can, please advise me
regarding this matter.
When getting your addresses from file MAINTAINERS, I noticed that it was not
updated for the name change from brcm80211 to brcmsmac. The current info is as
follows:
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
M:
M: Roland Vossen <[email protected]>
M: Arend van Spriel <[email protected]>
M: Franky (Zhenhui) Lin <[email protected]>
M: Kan Yan <[email protected]>
L: [email protected]
L: [email protected]
S: Supported
F: drivers/net/wireless/brcm80211/
Thanks,
Larry
2012/6/27 Arend van Spriel <[email protected]>:
>> Reverse engineering this device to be able to drive it with b43 would
>> involve a lot of effort. If your group is planning on adding it to
>> brcmsmac, then I would not undertake this project. To the fullest extent
>> that you can, please advise me regarding this matter.
>
> Our focus is currently on extending brcmfmac. We had requests for 43228
> support before, but did not start that task. Will inform internally what
> the plan is here and let you know to the fullest extent ;-)
Can you ask about BCM4331? It's probably the most desired code (HT
PHY) across embedded devices.
--
Rafał
On 06/25/2012 10:03 PM, Denis 'GNUtoo' Carikli wrote:
> On Mon, 2012-06-25 at 18:13 +0200, Hauke Mehrtens wrote:
>> Add support for more chips, including (near term) BCM43227, BCM43228,
>> and BCM4331. Support for additional new chips to follow.
> What about the BCM43231?
> There was some plans about it:
> http://lists.infradead.org/pipermail/b43-dev/2012-January/002297.html
>
> But the thread ends and then it seem that nothing was achieved.
>
> I've a BCM43231:
> Bus 001 Device 008: ID 0846:9020 NetGear, Inc. WNA3100(v1) Wireless-N
> 300 [Broadcom BCM43231]
>
> Are there some wireless kernels developers in Italy or in France that
> would accept a bcm43231 card in exchange of working on a driver?
>
> Denis.
I just found a driver for "Dongle BUS interface for USB, SDIO, SPI,
etc." which seams to also support the BCM43231 licensed under a
permissive license in the GPL source tar of the ASUS RT-AC66U. [0] I
haven't found the firmware for that specific device, but someone could
try to get that driver running with a normal Linux kernel. I am also
interested in that as I have a USB device in my router not supported by
brcmfmac.
Currently I do not have time for that, but I will probably have a closer
look into that driver soon.
Hauke
[0] asuswrt/release/src-rt-6.x/shared/dbus*
On 06/27/2012 03:37 AM, Arend van Spriel wrote:
> On 06/25/2012 05:41 PM, Larry Finger wrote:
>
> I noticed your email on the lockdep_init_map() function. Maybe the
> hybrid driver will be modified, but I leave that to Brett.
Obviously, the kernel will not be changed to make that routine available.
> My personal experience with ndiswrapper on 64-bit kernels is different,
> but I tend to consider ndiswrapper as a last resort. Most issues I had
> were between ndiswrapper and wpa_supplicant (when using dbus ipc).
>
>> Reverse engineering this device to be able to drive it with b43 would
>> involve a lot of effort. If your group is planning on adding it to
>> brcmsmac, then I would not undertake this project. To the fullest extent
>> that you can, please advise me regarding this matter.
>
> Our focus is currently on extending brcmfmac. We had requests for 43228
> support before, but did not start that task. Will inform internally what
> the plan is here and let you know to the fullest extent ;-)
Any help you can give will be appreciated.
>
> Under the folder drivers/net/wireless/brcm80211/ are both brcmfmac and
> brcmsmac (and shared module brcmutil). So maybe patch it like this:
>
> - BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
> + BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVERS
That will help, but perhaps you might make it
+ BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVERS (brcmsmac, brcmfmac)
This way, a search for brcmsmac or brcmfmac will succeed.
Larry
On 06/25/2012 05:41 PM, Larry Finger wrote:
> Hi,
>
> I recently received a donated BCM43228 (14e4:4359) mini-PCIe card. At
> the moment, neither b43 nor brcmsmac support it. Although, grepping the
> proprietary driver wl shows that it would recognize that PCI ID, that
> driver does not load as it requires routine lockdep_init_map(), which is
> exported only for GPL modules. As a result, owners of this device can
> only use it with Linux if they can find a suitable Windows driver for
> use with ndiswrapper. In my experience, that means that 64-bit users are
> out of luck.
I noticed your email on the lockdep_init_map() function. Maybe the
hybrid driver will be modified, but I leave that to Brett.
My personal experience with ndiswrapper on 64-bit kernels is different,
but I tend to consider ndiswrapper as a last resort. Most issues I had
were between ndiswrapper and wpa_supplicant (when using dbus ipc).
> Reverse engineering this device to be able to drive it with b43 would
> involve a lot of effort. If your group is planning on adding it to
> brcmsmac, then I would not undertake this project. To the fullest extent
> that you can, please advise me regarding this matter.
Our focus is currently on extending brcmfmac. We had requests for 43228
support before, but did not start that task. Will inform internally what
the plan is here and let you know to the fullest extent ;-)
> When getting your addresses from file MAINTAINERS, I noticed that it was
> not updated for the name change from brcm80211 to brcmsmac. The current
> info is as follows:
>
> BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
> M:
> M: Roland Vossen <[email protected]>
> M: Arend van Spriel <[email protected]>
> M: Franky (Zhenhui) Lin <[email protected]>
> M: Kan Yan <[email protected]>
> L: [email protected]
> L: [email protected]
> S: Supported
> F: drivers/net/wireless/brcm80211/
Under the folder drivers/net/wireless/brcm80211/ are both brcmfmac and
brcmsmac (and shared module brcmutil). So maybe patch it like this:
- BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
+ BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVERS
Gr. AvS
On 06/25/2012 11:36 PM, Hauke Mehrtens wrote:
>> I suspect 0846:9020 can be *not* a BCM43231. I discovered some other
>> > chipset on this USB dongle when hacking it with brcmfmac. If I
>> > remember correctly it was 4322. Sounds a little weird, as we already
>> > know softmac BCM4322 with N-PHY, I don't know if there is any relation
>> > between softmac 4322 and fullmac 4322.
The BCM43231 dongle is indeed bcm4322. Not sure whether the chip
revisions are different.
> I have two BCM4322 soldered on a board of a router (Linksys WRT610N V1)
> and connected via PCI to the main Chip (BCM4705/BCM4785). My BCM4322 has
> a ARM Cortex M3 core, a USB host core, a PCI and a PCIe core in addition
> to the "normal cores". My BCM4322 is running as a softmac device and is
> supported by b43 and ssb, 2.4 Ghz wifi is working.
>
> This chip is probably capable of running in softmac mode on a PCI or
> PCIe card or in fullmac mode in a USB dongle, at least that's my
> explanation for the ARM core on this device.
The chip has some redundant cores. Which these are indeed depends on the
type of host interface used. It is a trade-off between this and spin a
separate chip.
However, in case of USB it is not a fullmac driver model and not in
softmac driver model either. It has a different functional split of mac
functionality between host and firmware. This is also true for the
bcm43236 v2. Also this model has been abandoned for new devices.
This would need a cfg80211 driver duplicating mac80211 functionality or
wish the mac80211 offload features match the functional split nicely.
Internally we have looked at the mac80211 offloads and concluded it was
not. Hence we decided to only support softmac and fullmac driver models.
Gr. AvS
On 06/25/2012 11:25 PM, Rafał Miłecki wrote:
> 2012/6/25 Hauke Mehrtens <[email protected]>:
>> On 06/25/2012 10:03 PM, Denis 'GNUtoo' Carikli wrote:
>>> On Mon, 2012-06-25 at 18:13 +0200, Hauke Mehrtens wrote:
>>>> Add support for more chips, including (near term) BCM43227, BCM43228,
>>>> and BCM4331. Support for additional new chips to follow.
>>> What about the BCM43231?
>>> There was some plans about it:
>>> http://lists.infradead.org/pipermail/b43-dev/2012-January/002297.html
>>>
>>> But the thread ends and then it seem that nothing was achieved.
>>>
>>> I've a BCM43231:
>>> Bus 001 Device 008: ID 0846:9020 NetGear, Inc. WNA3100(v1) Wireless-N
>>> 300 [Broadcom BCM43231]
>>>
>>> Are there some wireless kernels developers in Italy or in France that
>>> would accept a bcm43231 card in exchange of working on a driver?
>>>
>>> Denis.
>>
>> I just found a driver for "Dongle BUS interface for USB, SDIO, SPI,
>> etc." which seams to also support the BCM43231 licensed under a
>> permissive license in the GPL source tar of the ASUS RT-AC66U. [0] I
>> haven't found the firmware for that specific device, but someone could
>> try to get that driver running with a normal Linux kernel. I am also
>> interested in that as I have a USB device in my router not supported by
>> brcmfmac.
>> Currently I do not have time for that, but I will probably have a closer
>> look into that driver soon.
>>
>> Hauke
>>
>> [0] asuswrt/release/src-rt-6.x/shared/dbus*
>
> I suspect 0846:9020 can be *not* a BCM43231. I discovered some other
> chipset on this USB dongle when hacking it with brcmfmac. If I
> remember correctly it was 4322. Sounds a little weird, as we already
> know softmac BCM4322 with N-PHY, I don't know if there is any relation
> between softmac 4322 and fullmac 4322.
I have two BCM4322 soldered on a board of a router (Linksys WRT610N V1)
and connected via PCI to the main Chip (BCM4705/BCM4785). My BCM4322 has
a ARM Cortex M3 core, a USB host core, a PCI and a PCIe core in addition
to the "normal cores". My BCM4322 is running as a softmac device and is
supported by b43 and ssb, 2.4 Ghz wifi is working.
This chip is probably capable of running in softmac mode on a PCI or
PCIe card or in fullmac mode in a USB dongle, at least that's my
explanation for the ARM core on this device.
Hauke
On Mon, 2012-06-25 at 18:13 +0200, Hauke Mehrtens wrote:
> Add support for more chips, including (near term) BCM43227, BCM43228,
> and BCM4331. Support for additional new chips to follow.
What about the BCM43231?
There was some plans about it:
http://lists.infradead.org/pipermail/b43-dev/2012-January/002297.html
But the thread ends and then it seem that nothing was achieved.
I've a BCM43231:
Bus 001 Device 008: ID 0846:9020 NetGear, Inc. WNA3100(v1) Wireless-N
300 [Broadcom BCM43231]
Are there some wireless kernels developers in Italy or in France that
would accept a bcm43231 card in exchange of working on a driver?
Denis.
2012/6/25 Hauke Mehrtens <[email protected]>:
> On 06/25/2012 10:03 PM, Denis 'GNUtoo' Carikli wrote:
>> On Mon, 2012-06-25 at 18:13 +0200, Hauke Mehrtens wrote:
>>> Add support for more chips, including (near term) BCM43227, BCM43228,
>>> and BCM4331. Support for additional new chips to follow.
>> What about the BCM43231?
>> There was some plans about it:
>> http://lists.infradead.org/pipermail/b43-dev/2012-January/002297.html
>>
>> But the thread ends and then it seem that nothing was achieved.
>>
>> I've a BCM43231:
>> Bus 001 Device 008: ID 0846:9020 NetGear, Inc. WNA3100(v1) Wireless-N
>> 300 [Broadcom BCM43231]
>>
>> Are there some wireless kernels developers in Italy or in France that
>> would accept a bcm43231 card in exchange of working on a driver?
>>
>> Denis.
>
> I just found a driver for "Dongle BUS interface for USB, SDIO, SPI,
> etc." which seams to also support the BCM43231 licensed under a
> permissive license in the GPL source tar of the ASUS RT-AC66U. [0] I
> haven't found the firmware for that specific device, but someone could
> try to get that driver running with a normal Linux kernel. I am also
> interested in that as I have a USB device in my router not supported by
> brcmfmac.
> Currently I do not have time for that, but I will probably have a closer
> look into that driver soon.
>
> Hauke
>
> [0] asuswrt/release/src-rt-6.x/shared/dbus*
I suspect 0846:9020 can be *not* a BCM43231. I discovered some other
chipset on this USB dongle when hacking it with brcmfmac. If I
remember correctly it was 4322. Sounds a little weird, as we already
know softmac BCM4322 with N-PHY, I don't know if there is any relation
between softmac 4322 and fullmac 4322.
--
Rafał
On 06/25/2012 05:41 PM, Larry Finger wrote:
> Hi,
>
> I recently received a donated BCM43228 (14e4:4359) mini-PCIe card. At
> the moment, neither b43 nor brcmsmac support it. Although, grepping the
> proprietary driver wl shows that it would recognize that PCI ID, that
> driver does not load as it requires routine lockdep_init_map(), which is
> exported only for GPL modules. As a result, owners of this device can
> only use it with Linux if they can find a suitable Windows driver for
> use with ndiswrapper. In my experience, that means that 64-bit users are
> out of luck.
>
> Reverse engineering this device to be able to drive it with b43 would
> involve a lot of effort. If your group is planning on adding it to
> brcmsmac, then I would not undertake this project. To the fullest extent
> that you can, please advise me regarding this matter.
The TODO list for brcmsmac at
http://linuxwireless.org/en/users/Drivers/brcm80211 contains the
following point since May 2011:
Add support for more chips, including (near term) BCM43227, BCM43228,
and BCM4331. Support for additional new chips to follow.
@Broadcom Are there any concrete, current plans for adding support for
these chips? Or would it be possible that you at least release the phy
code needed for these devices as is so that someone could integrate it
into brcmsmac or b43?
Hauke