BCM4321 support

BCM4321 support

[Octavian Voicu]

Hello,

I just replaced my WLAN card on my Dell laptop. The old one, a BCM4311
that came with the laptop, stopped working at some point -- I was
getting?FOUND UNSUPPORTED PHY?(Analog 0, Type 0, Revision 0).

The new one is a BCM4321 pcmcia mini-card. It looks identical to [1]
(I bought it 2nd hand though): BCM94321MCP3 P3, REV 0A, ver 6.7 r.

I got it to work after upgrading to a newer kernel / b43 driver
(3.0.3-030003-generic from .deb), but there are a few problems:


1) All networks show as having maximum link quality. Signal level is
always 0 dBm.

I have many wifi networks around, and most don't have a strong signal.
Also, there is no noise level in the iwconfig output:
? ? ? ? ? Link Quality=70/70 ?Signal level=0 dBm

Same goes for iwlist scan. I also tried the Linux STA driver, which
correctly shows the link quality (including a Noise level), but for
some reason it cannot connect authenticate to my WPA access point
(didn't try without encryption).

How can I fix this?

I also see some invalid misc packets. Any concerns about that?


2) I understand this chip should also support 802.11n, but it doesn't
look like b43 supports it:

wlan0     IEEE 802.11bg  ESSID:"swn"

This AP doesn't support 802.11n, but the Linux STA driver would also
show the n suffix.

Can I use 802.11n with b43?


3) Tried latest firmware (version 666.2) from [2], but it didn't work.
It was loaded successfully, but iwlist scan wouldn't show any
networks.

After that I switched to 508.1084, as recommended on that page, and it
works as described above. My system is Ubuntu 11.04 (natty) which has
an older firmware, so I extracted those manually using latest
fwcutter.

Which firmware do you recommend?


I attached a file with more info about my system, and dmesg logs after
inserting the module.
I have some kernel dev experience, and I'm willing to help improve the
driver, but I need a few pointers on what's broken or not implemented,
and on the way to approach it (reverse engineer the STA driver? any
other tools?).

Thanks,
Octavian


[1]?http://www.pchub.com/uph/laptop/279-31135-1906/HP-Common-Item-HP--Wireless-LAN-Card.html
[2] http://wireless.kernel.org/en/users/Drivers/b43
-------------- next part --------------
octav at cake:~$ uname -a
Linux cake 3.0.3-030003-generic #201108180913 SMP Thu Aug 18 09:15:59 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
octav at cake:~$ lspci -vnn
... 

0c:00.0 Network controller [0280]: Broadcom Corporation BCM4321 802.11a/b/g/n [14e4:4328] (rev 03)
        Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n Wireless LAN Controller [103c:1367]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
        Memory at f0000000 (64-bit, prefetchable) [size=1M]
        Capabilities: <access denied>
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

octav at cake:~$ sudo modprobe -v b43 verbose=2
insmod /lib/modules/3.0.3-030003-generic/kernel/drivers/net/wireless/b43/b43.ko verbose=2
octav at cake:~$ dmesg 
[ 2199.346395] b43-phy1: Broadcom 4321 WLAN found (core revision 12)
[ 2199.500263] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500268] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500271] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500274] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500276] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500279] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500282] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500284] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500292] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500295] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500303] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500306] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500308] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500311] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500314] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500317] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500319] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500322] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500324] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500327] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500330] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500333] cfg80211: 2402000 KHz - 2472000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500335] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500338] cfg80211: 2457000 KHz - 2482000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500340] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500343] cfg80211: 2457000 KHz - 2482000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500346] cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width channel with regulatory rule:
[ 2199.500349] cfg80211: 2474000 KHz - 2494000 KHz @  KHz), (300 mBi, 2000 mBm)
[ 2199.500492] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 2199.501905] Registered led device: b43-phy1::tx
[ 2199.501933] Registered led device: b43-phy1::rx
[ 2199.501956] Registered led device: b43-phy1::radio
[ 2199.501978] Broadcom 43xx driver loaded [ Features: PNL, Firmware-ID: FW13 ]
[ 2199.760263] b43-phy1: Loading firmware version 508.1084 (2009-01-14 01:32:01)
[ 2199.964454] ADDRCONF(NETDEV_UP): wlan0: link is not ready
octav at cake:~$ sudo iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:"swn"                                                                                                                                             
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1B:11:A5:13:9A   
          Bit Rate=18 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70  Signal level=0 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:46   Missed beacon:0

BCM4321 support

[Octavian Voicu]

Some extra debug output from inserting the module with verbose=3:

[ 4887.725591] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 4887.820235] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 4887.820268] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
0x2055, Revision 4
[ 4887.886958] Broadcom 43xx driver loaded [ Features: PNL, Firmware-ID: FW13 ]
[ 4888.170254] b43-phy0: Loading firmware version 508.1084 (2009-01-14 01:32:01)
[ 4888.330209] b43-phy0 debug: Chip initialized
[ 4888.330470] b43-phy0 debug: 64-bit DMA initialized
[ 4888.330544] b43-phy0 debug: QoS enabled
[ 4888.371215] b43-phy0 debug: Wireless interface started
[ 4888.371258] b43-phy0 debug: Adding Interface type 2

Octavian

BCM4321 support

[Rafał Miłecki]

2011/8/24 Octavian Voicu <octavian.voicu@gmail.com>:
> I just replaced my WLAN card on my Dell laptop. The old one, a BCM4311
> that came with the laptop, stopped working at some point -- I was
> getting?FOUND UNSUPPORTED PHY?(Analog 0, Type 0, Revision 0).

It seems the card or the slot died. As new card works in the slot, I
believe it's card that died.


> The new one is a BCM4321 pcmcia mini-card. It looks identical to [1]
> (I bought it 2nd hand though): BCM94321MCP3 P3, REV 0A, ver 6.7 r.

What I can see on the photo is mini PCIe card. I didn't hear about any
recent Broadcom card using PCMCIA slot.


> I got it to work after upgrading to a newer kernel / b43 driver
> (3.0.3-030003-generic from .deb), but there are a few problems:
>
>
> 1) All networks show as having maximum link quality. Signal level is
> always 0 dBm.
>
> I have many wifi networks around, and most don't have a strong signal.
> Also, there is no noise level in the iwconfig output:
> ? ? ? ? ? Link Quality=70/70 ?Signal level=0 dBm
>
> Same goes for iwlist scan. I also tried the Linux STA driver, which
> correctly shows the link quality (including a Noise level), but for
> some reason it cannot connect authenticate to my WPA access point
> (didn't try without encryption).
>
> How can I fix this?

Take a look at xmit.c and find the place:
if ((chanstat & B43_RX_CHAN_PHYTYPE) == B43_PHYTYPE_N) {
//		s8 rssi = max(rxhdr->power0, rxhdr->power1);
	//TODO: Find out what the rssi value is (dBm or percentage?)
	//      and also find out what the maximum possible value is.
	//      Fill status.ssi and status.signal fields.
} else {

You need to fix that part, read signal info from RX header.


> I also see some invalid misc packets. Any concerns about that?

I didn't hear about that, what exactly is that?


> 2) I understand this chip should also support 802.11n, but it doesn't
> look like b43 supports it:
>
> wlan0 ? ? IEEE 802.11bg ?ESSID:"swn"
>
> This AP doesn't support 802.11n, but the Linux STA driver would also
> show the n suffix.
>
> Can I use 802.11n with b43?

Not yet, sorry. I'll focus on 802.11n after adding basic support for
new Broadcom cards.


> 3) Tried latest firmware (version 666.2) from [2], but it didn't work.
> It was loaded successfully, but iwlist scan wouldn't show any
> networks.
>
> After that I switched to 508.1084, as recommended on that page, and it
> works as described above. My system is Ubuntu 11.04 (natty) which has
> an older firmware, so I extracted those manually using latest
> fwcutter.
>
> Which firmware do you recommend?

We don't know changelog of the firmware, hopefully using the newest is
always the best idea. To use firmware 598 or newer you need to use
very latest wireless tree. I suggest sticking to firmware older than
598 for now (like 508).


> I attached a file with more info about my system, and dmesg logs after
> inserting the module.
> I have some kernel dev experience, and I'm willing to help improve the
> driver, but I need a few pointers on what's broken or not implemented,
> and on the way to approach it (reverse engineer the STA driver? any
> other tools?).

For reading signal info from RX header you can compare b43 with brcmsmac.

I didn't play with 802.11n yet.

If you like, you can try enabling 5 GHz channels support in b43 and
check if this is working. I didn't have opportunity to try this.

-- 
Rafa?

BCM4321 support

[Octavian Voicu]

2011/8/24 Rafa? Mi?ecki <zajec5@gmail.com>:
> 2011/8/24 Octavian Voicu <octavian.voicu@gmail.com>:
>> The new one is a BCM4321 pcmcia mini-card. It looks identical to [1]
>> (I bought it 2nd hand though): BCM94321MCP3 P3, REV 0A, ver 6.7 r.
>
> What I can see on the photo is mini PCIe card. I didn't hear about any
> recent Broadcom card using PCMCIA slot.

You're right, my bad, I meant PCIe.

>> I got it to work after upgrading to a newer kernel / b43 driver
>> (3.0.3-030003-generic from .deb), but there are a few problems:
>>
>>
>> 1) All networks show as having maximum link quality. Signal level is
>> always 0 dBm.
>>
>> I have many wifi networks around, and most don't have a strong signal.
>> Also, there is no noise level in the iwconfig output:
>> ? ? ? ? ? Link Quality=70/70 ?Signal level=0 dBm
>>
>> Same goes for iwlist scan. I also tried the Linux STA driver, which
>> correctly shows the link quality (including a Noise level), but for
>> some reason it cannot connect authenticate to my WPA access point
>> (didn't try without encryption).
>>
>> How can I fix this?
>
> Take a look at xmit.c and find the place:
> if ((chanstat & B43_RX_CHAN_PHYTYPE) == B43_PHYTYPE_N) {
> // ? ? ? ? ? ? ?s8 rssi = max(rxhdr->power0, rxhdr->power1);
> ? ? ? ?//TODO: Find out what the rssi value is (dBm or percentage?)
> ? ? ? ?// ? ? ?and also find out what the maximum possible value is.
> ? ? ? ?// ? ? ?Fill status.ssi and status.signal fields.
> } else {
>
> You need to fix that part, read signal info from RX header.

Thanks, I'll take a look.

>> I also see some invalid misc packets. Any concerns about that?
>
> I didn't hear about that, what exactly is that?

It's from the iwconfig output:

wlan0     IEEE 802.11bg  ESSID:"swn"
...
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:53   Missed beacon:0

iwconfig man page says:
       Invalid misc
              Other packets lost in relation with specific wireless operations.

>> Can I use 802.11n with b43?
>
> Not yet, sorry. I'll focus on 802.11n after adding basic support for
> new Broadcom cards.

Fair enough. I don't have an 802.11n AP at the moment anyway.

>> Which firmware do you recommend?
>
> We don't know changelog of the firmware, hopefully using the newest is
> always the best idea. To use firmware 598 or newer you need to use
> very latest wireless tree. I suggest sticking to firmware older than
> 598 for now (like 508).

I switched to 508.154 and seems to be working.

Where is the latest wireless tree? Is it just Linus' vanilla linux.git
tree, or do you have a b43 dev tree?

About sending patches, when I'll have something meaningful, do I send
it to LKML, or here for review?

Octavian

BCM4321 support

[Rafał Miłecki]

W dniu 24 sierpnia 2011 20:32 u?ytkownik Octavian Voicu
<octavian.voicu@gmail.com> napisa?:
> 2011/8/24 Rafa? Mi?ecki <zajec5@gmail.com>:
>> 2011/8/24 Octavian Voicu <octavian.voicu@gmail.com>:
>>> I also see some invalid misc packets. Any concerns about that?
>>
>> I didn't hear about that, what exactly is that?
>
> It's from the iwconfig output:
>
> wlan0 ? ? IEEE 802.11bg ?ESSID:"swn"
> ...
> ? ? ? ? ?Rx invalid nwid:0 ?Rx invalid crypt:0 ?Rx invalid frag:0
> ? ? ? ? ?Tx excessive retries:0 ?Invalid misc:53 ? Missed beacon:0
>
> iwconfig man page says:
> ? ? ? Invalid misc
> ? ? ? ? ? ? ?Other packets lost in relation with specific wireless operations.

Thanks, I'll add this to my (long) TODO list. You can take a look at
this if you have some free time, it'll be welcome.


> Where is the latest wireless tree? Is it just Linus' vanilla linux.git
> tree, or do you have a b43 dev tree?

I send my patches to the John and linux-wireless ML.
For the most of the time wireless-testing was the tree getting all the
recent patches. Since about a month it seems John started taking
patches into wireless-next (unless it's urgent fix for "just"
wireless). After some time it seems John is merging wireless-next into
wireless-testing.
We are considering creating git tree for b43 development.


> About sending patches, when I'll have something meaningful, do I send
> it to LKML, or here for review?

I prefer to use both: b43-dev and linux-wireless. Using just LKML is
not enough, I think noone will take patches from that.

I don't have anything against sending patches also directly to John,
he always nicely gives ppl few days for reviewing (and NACKing ;) ).
But if you really prefer, you can just send patches to b43-dev and
wait until someone (me?) take them and repost to John.

-- 
Rafa?

BCM4321 support

[Octavian Voicu]

2011/8/24 Rafa? Mi?ecki <zajec5@gmail.com>:
> 2011/8/24 Octavian Voicu <octavian.voicu@gmail.com>:
>> I just replaced my WLAN card on my Dell laptop. The old one, a BCM4311
>> that came with the laptop, stopped working at some point -- I was
>> getting?FOUND UNSUPPORTED PHY?(Analog 0, Type 0, Revision 0).
>
> It seems the card or the slot died. As new card works in the slot, I
> believe it's card that died.

Something strange is happening.

Initially when I first tried the new BCM4321 PCIe card, it would show
no MAC address. I would have to set a MAC manually using `ifconfig hw
ether ...`, and only after that I could bring the interface up. It
still didn't see any networks.

The lspci -vnn would show it like this:
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11a Wireless LAN Controller [14e4:4321] (rev 03)
        Subsystem: Broadcom Corporation BCM4306 802.11a Wireless LAN
Controller [14e4:4321]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
        Memory at <ignored> (64-bit, prefetchable)
        Capabilities: [40] Power Management version 2
        Capabilities: [58] Vendor Specific Information: Len=78 <?>
        Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [d0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-00-00
        Capabilities: [16c] Power Budgeting <?>
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

Then I upgraded the drivers and it magically started to work, or so I
thought. It would see its MAC address and, at the same time, lspci
-vnn showed it correctly, like this:
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4321
802.11a/b/g/n [14e4:4328] (rev 03)
        Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n
Wireless LAN Controller [103c:1367]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
        Memory at f0000000 (64-bit, prefetchable) [size=1M]

After working for a day or so and forgetting about it, I check it
again and I see it's not working anymore. It reverted to the old 4321
device id shown by lspci, and no MAC. Note that the initial lspci
output I've given is generated now, as I didn't have any dump from
then. I'm positive about the device id, not so much about the rest,
but I'm assuming it was as it is now.

I'm starting to think the driver upgrades weren't responsible for
"fixing" the card. It looks similar with the pattern I had with the
old card: didn't work, then one day magically started to work, next
reboot stopped working again for good.

Currently, inserting b43 with verbose=3, setting the MAC, and bringing
up the interface gives this in dmesg:

[  130.112440] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[  130.210099] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[  130.210135] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
0x2055, Revision 4
[  130.298741] Broadcom 43xx driver loaded [ Features: PMNLS,
Firmware-ID: FW13 ]
[  185.230221] b43-phy0: Loading firmware version 508.1084 (2009-01-14 01:32:01)
[  185.253435] b43-phy0 ERROR: radio post init timeout
[  185.370162] b43-phy0 debug: Chip initialized
[  185.370408] b43-phy0 debug: 64-bit DMA initialized
[  185.370487] b43-phy0 debug: QoS enabled
[  185.411224] b43-phy0 debug: Wireless interface started
[  185.411264] b43-phy0 debug: Adding Interface type 2

Notice the line "ERROR: radio post init timeout". Don't remember
seeing this error before (but didn't use verbose either). Also, notice
how lspci shows that the second chunk of memory is ignored:
    Memory at <ignored> (64-bit, prefetchable)
while when it was working it would show this:
    Memory at f0000000 (64-bit, prefetchable) [size=1M]

I also tried switching the PCIe mini-card slot (I have 3 of them;
tried them all with no change).

Questions:

1) Is this a hardware problem (with the slot and/or the wlan card itself)?

Don't have other wlan PCIe mini-cards to test. How can I diagnose the problem?

Can all the mini-card slots be busted? (never used the other two, they
are for WPAN and WWAN)

Should it matter that I'm using a different WLAN card than the
original one? The laptop also has a "Wi-Fi Catcher" feature,
integrated with the rfkill button (there is a 3rd state of the button
that blinks a LED if there are wifi networks around), which stopped
working at some point (probably when my original card got busted). It
never worked with the new card.

2) Could it be software related?

How can the system consistently misread the PCI device id?

What's the deal with the second memory chunk? Is it where the MAC is
stored, and why is the driver ignoring it now?


I realize there's a lot of data here, and even more questions, so any
help is appreciated :)

Thanks,
Octavian

BCM4321 support

[Gábor Stefanik]

2011/8/27 Octavian Voicu <octavian.voicu@gmail.com>:
> 2011/8/24 Rafa? Mi?ecki <zajec5@gmail.com>:
>> 2011/8/24 Octavian Voicu <octavian.voicu@gmail.com>:
>>> I just replaced my WLAN card on my Dell laptop. The old one, a BCM4311
>>> that came with the laptop, stopped working at some point -- I was
>>> getting?FOUND UNSUPPORTED PHY?(Analog 0, Type 0, Revision 0).
>>
>> It seems the card or the slot died. As new card works in the slot, I
>> believe it's card that died.
>
> Something strange is happening.
>
> Initially when I first tried the new BCM4321 PCIe card, it would show
> no MAC address. I would have to set a MAC manually using `ifconfig hw
> ether ...`, and only after that I could bring the interface up. It
> still didn't see any networks.
>
> The lspci -vnn would show it like this:
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4306
> 802.11a Wireless LAN Controller [14e4:4321] (rev 03)
> ? ? ? ?Subsystem: Broadcom Corporation BCM4306 802.11a Wireless LAN
> Controller [14e4:4321]
> ? ? ? ?Flags: bus master, fast devsel, latency 0, IRQ 17
> ? ? ? ?Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
> ? ? ? ?Memory at <ignored> (64-bit, prefetchable)
> ? ? ? ?Capabilities: [40] Power Management version 2
> ? ? ? ?Capabilities: [58] Vendor Specific Information: Len=78 <?>
> ? ? ? ?Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+
> ? ? ? ?Capabilities: [d0] Express Endpoint, MSI 00
> ? ? ? ?Capabilities: [100] Advanced Error Reporting
> ? ? ? ?Capabilities: [13c] Virtual Channel
> ? ? ? ?Capabilities: [160] Device Serial Number 00-00-00-ff-ff-00-00-00
> ? ? ? ?Capabilities: [16c] Power Budgeting <?>
> ? ? ? ?Kernel driver in use: b43-pci-bridge
> ? ? ? ?Kernel modules: ssb
>
> Then I upgraded the drivers and it magically started to work, or so I
> thought. It would see its MAC address and, at the same time, lspci
> -vnn showed it correctly, like this:
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4321
> 802.11a/b/g/n [14e4:4328] (rev 03)
> ? ? ? ?Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n
> Wireless LAN Controller [103c:1367]
> ? ? ? ?Flags: bus master, fast devsel, latency 0, IRQ 17
> ? ? ? ?Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
> ? ? ? ?Memory at f0000000 (64-bit, prefetchable) [size=1M]
>
> After working for a day or so and forgetting about it, I check it
> again and I see it's not working anymore. It reverted to the old 4321
> device id shown by lspci, and no MAC. Note that the initial lspci
> output I've given is generated now, as I didn't have any dump from
> then. I'm positive about the device id, not so much about the rest,
> but I'm assuming it was as it is now.
>
> I'm starting to think the driver upgrades weren't responsible for
> "fixing" the card. It looks similar with the pattern I had with the
> old card: didn't work, then one day magically started to work, next
> reboot stopped working again for good.
>
> Currently, inserting b43 with verbose=3, setting the MAC, and bringing
> up the interface gives this in dmesg:
>
> [ ?130.112440] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
> [ ?130.210099] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
> [ ?130.210135] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
> 0x2055, Revision 4
> [ ?130.298741] Broadcom 43xx driver loaded [ Features: PMNLS,
> Firmware-ID: FW13 ]
> [ ?185.230221] b43-phy0: Loading firmware version 508.1084 (2009-01-14 01:32:01)
> [ ?185.253435] b43-phy0 ERROR: radio post init timeout
> [ ?185.370162] b43-phy0 debug: Chip initialized
> [ ?185.370408] b43-phy0 debug: 64-bit DMA initialized
> [ ?185.370487] b43-phy0 debug: QoS enabled
> [ ?185.411224] b43-phy0 debug: Wireless interface started
> [ ?185.411264] b43-phy0 debug: Adding Interface type 2
>
> Notice the line "ERROR: radio post init timeout". Don't remember
> seeing this error before (but didn't use verbose either). Also, notice
> how lspci shows that the second chunk of memory is ignored:
> ? ?Memory at <ignored> (64-bit, prefetchable)
> while when it was working it would show this:
> ? ?Memory at f0000000 (64-bit, prefetchable) [size=1M]
>
> I also tried switching the PCIe mini-card slot (I have 3 of them;
> tried them all with no change).
>
> Questions:
>
> 1) Is this a hardware problem (with the slot and/or the wlan card itself)?
>
> Don't have other wlan PCIe mini-cards to test. How can I diagnose the problem?
>
> Can all the mini-card slots be busted? (never used the other two, they
> are for WPAN and WWAN)
>
> Should it matter that I'm using a different WLAN card than the
> original one? The laptop also has a "Wi-Fi Catcher" feature,
> integrated with the rfkill button (there is a 3rd state of the button
> that blinks a LED if there are wifi networks around), which stopped
> working at some point (probably when my original card got busted). It
> never worked with the new card.
>
> 2) Could it be software related?
>
> How can the system consistently misread the PCI device id?

I think the device ID is stored in the SPROM. Perhaps your card's
SPROM is busted.

>
> What's the deal with the second memory chunk? Is it where the MAC is
> stored, and why is the driver ignoring it now?
>
>
> I realize there's a lot of data here, and even more questions, so any
> help is appreciated :)
>
> Thanks,
> Octavian
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

BCM4321 support

[Octavian Voicu]

On Sat, Aug 27, 2011 at 9:13 PM, G?bor Stefanik <netrolller.3d@gmail.com> wrote:
> I think the device ID is stored in the SPROM. Perhaps your card's
> SPROM is busted.

It seems that you were right, my SPROM is busted:
ssb: WARNING: Using fallback SPROM failed (err -2)
ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
ssb: Unsupported SPROM revision 0 detected. Will extract v1

I also dumped /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/ssb_sprom
and it's just zeroes (as in 0x30, not nulls).

Larry, I CC-ed you because I noticed in an earlier message on the lwn
mailing list that you own (or used to own) the exact model of BCM4321
as the one I have now:

0c:00.0 Network controller [0280]: Broadcom Corporation BCM4321
802.11a/b/g/n [14e4:4328] (rev 03)
        Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n
Wireless LAN Controller [103c:1367]

Can anybody with a BCM4321 send me a full SPROM dump from their card
(preferably a HP BCM4321, but I guess any would do)? I want to hack
something up and try fix my card.

Thanks in advance,
Octavian

BCM4321 support

[Larry Finger]

On 08/28/2011 11:59 AM, Octavian Voicu wrote:
>
> Larry, I CC-ed you because I noticed in an earlier message on the lwn
> mailing list that you own (or used to own) the exact model of BCM4321
> as the one I have now:
>
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4321
> 802.11a/b/g/n [14e4:4328] (rev 03)
>          Subsystem: Hewlett-Packard Company BCM4321 802.11a/b/g/n
> Wireless LAN Controller [103c:1367]
>
> Can anybody with a BCM4321 send me a full SPROM dump from their card
> (preferably a HP BCM4321, but I guess any would do)? I want to hack
> something up and try fix my card.

Octavian,

I do have a BCM4321 (14e4:4328) that works with the latest b43. I'm using 
508.154 firmware.

Performance is not great, but it is adequate. The TX and RX rates (Mbps) for 3 
common netperf tests are as follows:

TCP_MAERTS TX Test:   7.68  7.75  7.76  8.42  7.12  6.69  6.61  6.65  7.99  7.15
TCP_MAERTS RX Test:   9.50 12.15 10.70  8.78 11.55 11.32 11.97  9.71  6.00  9.17
Results: TX: max  8.42, min  6.61. Mean  7.38(0.60)
          RX: max 12.15, min  6.00. Mean 10.09(1.78)

TCP_STREAM TX Test:   9.72  9.18  6.54  9.49  9.56  9.02  9.31  9.16  9.49 10.55
TCP_STREAM RX Test:   4.39  5.68  2.91  7.76  7.07  7.65  6.92  7.50  7.48  7.59
Results: TX: max 10.55, min  6.54. Mean  9.20(0.98)
          RX: max  7.76, min  2.91. Mean  6.50(1.57)

TCP_SENDFILE TX Test: 13.54 14.21 11.01 6.74 11.55 10.25  9.99  9.87 11.30 12.38
TCP_SENDFILE RX Test:  7.06  7.03  7.03 7.06  6.90  7.10  7.15  6.84  7.07  6.84
Results: TX: max 14.21, min  6.74. Mean 11.08(2.00)
          RX: max  7.15, min  6.84. Mean  7.01(0.10)

The netperf server for TX and transmitter for the RX tests is attached to my 
AP/router/switch via a 100 Mbps wired connection.

Pertinent data from the dmesg output:

finger at larrylap:~/DRAWxtl/source/DRAWxtl56> dmesg | egrep "ssb|b43"
[   11.963272] b43-pci-bridge 0000:06:00.0: PCI INT A -> Link[LK1E] -> GSI 21 
(level, low) -> IRQ 21
[   11.963298] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
[   11.980208] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x13, vendor 0x4243)
[   11.980218] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0C, vendor 0x4243)
[   11.980226] ssb: Core 2 found: PCI-E (cc 0x820, rev 0x04, vendor 0x4243)
[   11.980234] ssb: Core 3 found: PCI (cc 0x804, rev 0x0D, vendor 0x4243)
[   11.980242] ssb: Core 4 found: USB 1.1 Host (cc 0x817, rev 0x04, vendor 0x4243)
[   12.000412] ssb: chipcommon status is 0x0
[   12.000423] ssb: SPROM offset is 0x1000
[   12.008930] ssb: SPROM revision 5 detected.
[   12.053346] ssb: Sonics Silicon Backplane found on PCI device 0000:06:00.0
[   12.984431] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[   13.028157] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[   13.028183] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
[   13.111428] Registered led device: b43-phy0::tx
[   13.111989] Registered led device: b43-phy0::rx
[   13.112585] Registered led device: b43-phy0::radio
[   33.504075] b43-phy0: Loading firmware version 508.154 (2009-08-18 00:58:22)
[   33.580329] b43-phy0 debug: Chip initialized
[   33.587483] b43-phy0 debug: 64-bit DMA initialized
[   33.587531] b43-phy0 debug: QoS enabled
[   33.615158] b43-phy0 debug: Wireless interface started
[   33.615222] b43-phy0 debug: Adding Interface type 2
[   82.275258] b43-phy0 debug: Using hardware based encryption for keyidx: 0, 
mac: c0:3f:0e:be:2b:44
[  137.618259] b43-phy0 ERROR: PHY transmission error
[  138.915048] b43-phy0 ERROR: PHY transmission error
[  141.608912] b43-phy0 ERROR: PHY transmission error
[  141.883784] b43-phy0 ERROR: PHY transmission error
[  143.127781] b43-phy0 ERROR: PHY transmission error
[  143.766625] b43-phy0 ERROR: PHY transmission error

SPROM contents:

0128000066133C100800BE1D0087C42B642A6429642CE73CFF297FC7FFFFFFFF28430080020000000110001800000000FFFFFFFFFFFFFFFF0000FFFFFFFFFFFF72536700535501000000014A0000140000001A006573D0940000FFFF03030202FFFF30285B5B29245B5B2D1C5B5B39365B5B44383838FF83FFFFFFFFFFFFFFFF443E9BFE8A14DFFA00003C3E3C3CABFE201254FB0000ACFE5A1320FB0000B9FEEC1163FB0000FFFFFFFFFFFFFFFF443EA4FEA4130DFB00003C3E3C3CA6FE95123FFB000094FE031252FB0000AAFEFF1228FB0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF05A6

My MAC address is 00:1A:73:65:94:D0. You should have the MAC for your device 
written on the label. In any case, do not use the same one as in my device.

Larrt

BCM4321 support

[Octavian Voicu]

On Mon, Aug 29, 2011 at 12:43 AM, Larry Finger
<Larry.Finger@lwfinger.net> wrote:
> SPROM contents:
...
> My MAC address is 00:1A:73:65:94:D0. You should have the MAC for your device
> written on the label. In any case, do not use the same one as in my device.

Thanks! Yes, I used my own MAC address.

I was kind of lazy and didn't want to recompile the whole kernel, so I
went through a lot of trouble to compile just the modules I needed
(ssb, cfg80211, mac80211, b44, b43 -- I also need b44 for my ethernet
card and my current b44 didn't like a newer ssb). After a lot of
fumbling around and learning the hard way how tricky modversions can
get, finally managed to get it to work.

Bottom line... with a completely busted SPROM (reading it returns all
zeroes, writing it doesn't change one single bit), and a patched
ssb.ko (that would check if SPROM contents was all zeroes and patch it
up with the hard coded data if it was), card works perfectly now!

Interesting question: does the card's firmware use any of the values
in the SPROM, or are they just for the drivers to read? If the
firmware uses them, and my card works, would it mean that only the
interface to the SPROM is kind of busted, but the memory itself is OK
and can be read by the firmware? That would be a bit strange.

Gonna try writing a module to override SPROM on the fly using
ssb_arch_register_fallback_sprom, so that I don't have to patch and
recompile ssb when doing a kernel upgrade. If anyone thinks that would
be useful, I can post the source here when I'm done. It would have the
added benefit that it would permit testing a SPROM configuration
without actually writing anything, and risk bricking the device -- of
course, if the firmware uses anything from the SPROM, it wouldn't have
access to the modifications, so not sure how useful that would be.

And another side question: do you usually run the wireless-next kernel
when doing driver development and recompile the whole thing every time
you change something? Or rebuild just the targets/modules you're
interested in, and the whole kernel when changing data structures used
outside the module?

Octavian

BCM4321 support

[Larry Finger]

On 08/29/2011 08:08 AM, Octavian Voicu wrote:

> Bottom line... with a completely busted SPROM (reading it returns all
> zeroes, writing it doesn't change one single bit), and a patched
> ssb.ko (that would check if SPROM contents was all zeroes and patch it
> up with the hard coded data if it was), card works perfectly now!
>
> Interesting question: does the card's firmware use any of the values
> in the SPROM, or are they just for the drivers to read? If the
> firmware uses them, and my card works, would it mean that only the
> interface to the SPROM is kind of busted, but the memory itself is OK
> and can be read by the firmware? That would be a bit strange.

The firmware has its own private memory and it shares some memory with the host 
CPU, but it does not have access to the SPROM.

> Gonna try writing a module to override SPROM on the fly using
> ssb_arch_register_fallback_sprom, so that I don't have to patch and
> recompile ssb when doing a kernel upgrade. If anyone thinks that would
> be useful, I can post the source here when I'm done. It would have the
> added benefit that it would permit testing a SPROM configuration
> without actually writing anything, and risk bricking the device -- of
> course, if the firmware uses anything from the SPROM, it wouldn't have
> access to the modifications, so not sure how useful that would be.

Most of the code you need is already there. Use the SPROM fallback mechanism. 
You will need to call the ssb_arch_register_fallback_sprom() routine to specify 
the routine that loads an alternative SPROM contents. This mechanism will work 
to compensate for your broken hardware.

> And another side question: do you usually run the wireless-next kernel
> when doing driver development and recompile the whole thing every time
> you change something? Or rebuild just the targets/modules you're
> interested in, and the whole kernel when changing data structures used
> outside the module?

Fiddling around with modules to get them to load is too much work. I always use 
the wireless-testing kernel. Whenever changes are made. I use 'make -jX' to 
rebuild, where X is the number of cpu's + 1. It only does what is necessary. As 
I use openSUSE, this is followed by 'sudo make install_modules' and if bzImage 
was rebuilt, this is followed by 'sudo make install'. The latter command also 
updates the GRUB menu if the new kernel is not already in the list. If your 
distro is Debian-based, those simple commands may not work, but someone on the 
list will tell us how the do it. I don't think that long process of building a 
".deb" file is needed.

Larry

BCM4321 support

[Nicolas de Pesloüan]

Le 29/08/2011 18:36, Larry Finger a ?crit :

> If your distro is Debian-based, those simple commands may not work, but someone on the list will
> tell us how the do it. I don't think that long process of building a ".deb" file is needed.

The clean way is make deb-pkg from the root of the kernel tree. It will build whatever need to be 
build (normal build), then build several .deb files you can install using dpkg -i. The normal build 
takes "normal build time", but building the .deb files takes several minutes. I don't consider this 
a problem, but...

The fastest way is to simply make, then copy the changed modules into /lib/modules/..., but from a 
debian point of view, it is very dirty.

HTH.

	Nicolas.

BCM4321 support

[Octavian Voicu]

On Mon, Aug 29, 2011 at 7:36 PM, Larry Finger <Larry.Finger@lwfinger.net>wrote:

> The firmware has its own private memory and it shares some memory with the
> host CPU, but it does not have access to the SPROM.
>

Good to know, thanks for the explanation!


> Most of the code you need is already there. Use the SPROM fallback
> mechanism. You will need to call the ssb_arch_register_fallback_**sprom()
> routine to specify the routine that loads an alternative SPROM contents.
> This mechanism will work to compensate for your broken hardware.
>

Yeah, something along those lines. Hopefully I can make it use sprom_extract
to fill in the internal structures. It's gonna be quite tricky, voodoo black
magic :)

And another side question: do you usually run the wireless-next kernel
>> when doing driver development and recompile the whole thing every time
>> you change something? Or rebuild just the targets/modules you're
>> interested in, and the whole kernel when changing data structures used
>> outside the module?
>>
>
> Fiddling around with modules to get them to load is too much work. I always
> use the wireless-testing kernel. Whenever changes are made. I use 'make -jX'
> to rebuild, where X is the number of cpu's + 1. It only does what is
> necessary. As I use openSUSE, this is followed by 'sudo make
> install_modules' and if bzImage was rebuilt, this is followed by 'sudo make
> install'. The latter command also updates the GRUB menu if the new kernel is
> not already in the list. If your distro is Debian-based, those simple
> commands may not work, but someone on the list will tell us how the do it. I
> don't think that long process of building a ".deb" file is needed.
>

I found that it works to just do: make -C /lib/modules/`uname -r`/build
M=`pwd` drivers/net/wireless/b43/b43.ko
but I do have to be careful and build the modules in order of their
dependencies, otherwise the dependent module will have wrong versions of the
symbols it needs and it won't work.

On Tue, Aug 30, 2011 at 12:42 AM, Nicolas de Peslo?an <
nicolas.2p.debian@free.fr> wrote:

> The clean way is make deb-pkg from the root of the kernel tree. It will
> build whatever need to be build (normal build), then build several .deb
> files you can install using dpkg -i. The normal build takes "normal build
> time", but building the .deb files takes several minutes. I don't consider
> this a problem, but...
>
> The fastest way is to simply make, then copy the changed modules into
> /lib/modules/..., but from a debian point of view, it is very dirty.
>

Yeah, I guess I prefer the very quick and dirty way. I added them to
/lib/modules/.../updates/ and ran depmod. Good enough for me. As long as I
don't dig too deep in b43 I probably won't need to do full kernel builds.

My biggest concern right now is that the modules I build cannot be rmmod-ed
after being inserted. This happens with any custom built modules, including
the dkms built ones (eg. nvidia).

What happens is that after inserting them they show with a huge ref number
in lsmod, and there is a dependency on [permanent], which I understand
appears when the module doesn't have a registered exit function -- which it
should have, because CONFIG_MODULE_UNLOAD is y. Precompiled modules from
.debs work fine.

It's the same problem as described here [1]. Any thoughts on this? Is it an
ubuntu thing? I'm guessing that if I recompile the kernel problem might get
fixed, but do the Ubuntu guys have some special patch that prevents
unloading custom built modules?

$ lsmod | egrep 'ssb|b4|802'
ssb_sprom_override     12467  3343385879 [permanent]
b43                   332274  842478592 [permanent]
mac80211              301993  937372790 b43,[permanent]
cfg80211              197510  1895908598 b43,mac80211,[permanent]
b44                    35793  2191473215 [permanent]
ssb                    51848  4218871345 b43,b44,[permanent]
...
nvidia              11905275  0 [permanent]

rmmod and modprobe -r  (even with --force) fail.

Just imagine having to do a restart after each test of the module...

Octavian

[1] http://kerneltrap.org/node/16886
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110830/66e8b0be/attachment.html>

BCM4321 support

[Michael Büsch]

On Mon, 29 Aug 2011 11:36:20 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> The firmware has its own private memory and it shares some memory with the host 
> CPU

The firmware does not share any memory with the host CPU. The memory is called
"shared memory", but that is a misnomer. The host CPU accesses that memory
by memory mapped I/O. Firmware can do DMA only indirectly through the
TX and RX engines.

-- 
Greetings, Michael.

BCM4321 support

[Nicolas de Pesloüan]

Le 30/08/2011 01:33, Octavian Voicu a ?crit :

<snip>

> On Tue, Aug 30, 2011 at 12:42 AM, Nicolas de Peslo?an <nicolas.2p.debian@free.fr
> <mailto:nicolas.2p.debian@free.fr>> wrote:
>
>     The clean way is make deb-pkg from the root of the kernel tree. It will build whatever need to
>     be build (normal build), then build several .deb files you can install using dpkg -i. The normal
>     build takes "normal build time", but building the .deb files takes several minutes. I don't
>     consider this a problem, but...
>
>     The fastest way is to simply make, then copy the changed modules into /lib/modules/..., but from
>     a debian point of view, it is very dirty.
>
>
> Yeah, I guess I prefer the very quick and dirty way. I added them to /lib/modules/.../updates/ and
> ran depmod. Good enough for me. As long as I don't dig too deep in b43 I probably won't need to do
> full kernel builds.
>
> My biggest concern right now is that the modules I build cannot be rmmod-ed after being inserted.
> This happens with any custom built modules, including the dkms built ones (eg. nvidia).

I really suggest you once try building the whole kernel with deb-pkg, then touch a single file in 
b43, then rebuild. The overhead of producing .deb files is not null, but not big enough to stop me 
from rebuilding on every try. And I assume it would solve this module unload issue.

	Nicolas.