LinuxLists.cc - [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Michael,

Michael Buesch wrote:
> On Friday 09 February 2007 17:32, Larry Finger wrote:
>> The specifications for the bcm43xx driver have been modified. This patch
>> incorporates these changes in the code, which results in the BCM4311 and
>> BCM4312 working. The name of one of the PHY parameters, previously known
>> as "version", has been changed to "analog core version" .
>>
>> Signed-off-by: Larry Finger<[email protected]>
>> ---
>
>> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
>> struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>> struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>> u16 offset;
>> + u16 value;
>> + u8 old_channel;
>>
>> - if (phy->version == 1 &&
>> - radio->version == 0x2050) {
>
> Why do you delete the check to radio version.
> It's still there in latest specs:
> http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

As I have no real understanding of the differences between V3 and V4 firmware, I only follow the V3
specs at http://bcm-specs.sipsolutions.net. My usage of the V4 specs is to checking if they can
clean a point of confusion in the V3 spec. The radio version check is eliminated at the beginning of
the phy_initb5 routine in http://bcm-specs.sipsolutions.net/B5PHY. As there are radio version checks
later in the routine, I think it was meant to be removed here.

>> + if (phy->analog == 1)
>> bcm43xx_radio_write16(bcm, 0x007A,
>> bcm43xx_radio_read16(bcm, 0x007A)
>> | 0x0050);
>> - }
>> if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
>> (bcm->board_type != 0x0416)) {
>> + value = 0x2120;
>> for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
>> - bcm43xx_phy_write(bcm, offset,
>> - (bcm43xx_phy_read(bcm, offset) + 0x2020)
>> - & 0x3F3F);
>> + bcm43xx_phy_write(bcm, offset, value);
>> + value += 0x0202;
>> }
>
> I don't see how this matches specs.

See step 2 of http://bcm-specs.sipsolutions.net/B5PHY.

>> }
>> bcm43xx_phy_write(bcm, 0x0035,
>> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
>> bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
>> }
>>
>> - if (phy->version == 1 && radio->version == 0x2050) {
>
> Dito.

Ibid Step 7.

>> + if (phy->analog == 1) {
>> bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
>> bcm43xx_phy_write(bcm, 0x0021, 0x3763);
>> bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
>> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
>> bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
>> bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>>
>> - if (phy->version == 1 && radio->version == 0x2050)
>
> Dito.

Step 11.

>> + if (phy->analog == 1)
>> bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
>> else
>> bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>>
>> - if (phy->version == 0)
>> + if (phy->analog == 0)
>> bcm43xx_write16(bcm, 0x03E4, 0x3000);
>>
>> + old_channel = radio->channel;
>> /* Force to channel 7, even if not supported. */
>> bcm43xx_radio_selectchannel(bcm, 7, 0);
>>
>> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>>
>> bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>>
>> - bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
>> + bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>>
>> bcm43xx_phy_write(bcm, 0x0014, 0x0080);
>> bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
>> - bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
>> + bcm43xx_phy_write(bcm, 0x002A, 0x88A3);
>
> Well, this seems correct, but specs are still different. From where did you get this?

Steps 14 - 26 of http://bcm-specs.sipsolutions.net/B5PHY
>
>
> Well, I don't review the rest until you say to which specs you did the changes. ;)

As I said earlier, everything came from http://bcm-specs.sipsolutions.net.

Larry

2007-02-15 15:07:14

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> >
> > > It's likely that old cards still work with v4 firmware,
> >
> > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > instruction set in the microcode.
>
> Ok, I was not talking about _that_ old cards. ;)

Are there cards where they have new microcode instruction set but no v4
firmware?

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-09 18:48:18

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 19:21, Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 09 February 2007 23:22, Joseph Jezak wrote:
> >>> Well, I don't review the rest until you say to which specs you did the changes. ;)
> >> http://bcm-specs.sipsolutions.net/B5PHY
> >>
> >> Larry was working from the old specs, so when I updated it, I only
> >> updated the old specs. I'll fix the v4 specs soon.
> >
> > Ah, ok. I think we should decide on which specs carry most recent information.
> > I think v3 specs should be considered obsolete and new information/ fixes
> > should go into v4. It is already too confusing where to find newest information
> > to a certain thing.
> >
>
> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

Well, the difference between v3 and v4 is:
* The SHM API.
* v4 may include less BPHY stuff, as broadcom's v4 drivers don't include BHY anymore.

So I'd say for everything bug BPHY the v4 specs should be considered latest.

--
Greetings Michael.

2007-02-09 18:21:10

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Michael Buesch wrote:
> On Friday 09 February 2007 23:22, Joseph Jezak wrote:
>>> Well, I don't review the rest until you say to which specs you did the changes. ;)
>> http://bcm-specs.sipsolutions.net/B5PHY
>>
>> Larry was working from the old specs, so when I updated it, I only
>> updated the old specs. I'll fix the v4 specs soon.
>
> Ah, ok. I think we should decide on which specs carry most recent information.
> I think v3 specs should be considered obsolete and new information/ fixes
> should go into v4. It is already too confusing where to find newest information
> to a certain thing.
>

I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

Larry

2007-02-14 21:53:04

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Wednesday 14 February 2007 20:27, Johannes Berg wrote:
> On Wed, 2007-02-14 at 20:26 +0100, Johannes Berg wrote:
> > On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
> >
> > > I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> > > anymore, but the rest is functional.
> >
> > Oh good. Do they actually work right now?
>
> Heh, stupid question if you say they're functional :)
>
> Anyway, I'm not quite sure how we should keep those old code paths in
> there. Maybe having a different wireless driver for the older cores
> would be good, maybe split bcm43xx into three drivers, one for the
> PCI/SSB stuff and then two SSB drivers for old and new cores?

It's _really_ a pain to support both v3 and v4 fw in one driver.
I tried it, but it's really really hard to do. The API to the FW
is different in so many ways.
We would have to completely abstract the SharedMemory accesses.
That would mean a lot of additional code and functions (or we could
clutter the code with if{}else{} all over, which is even worse (IMO).

So, I would say we should have a seperate driver, probably also based
on d80211 for very old cards. But I don't really want to maintain
such a beast either. (I also don't have the required old HW).

--
Greetings Michael.

2007-02-15 16:53:42

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Thu, 2007-02-15 at 17:51 +0100, Martin Langer wrote:

> Yep. We have all kinds of firmware with the new instruction set. It's
> only ucode2 (old instruction set) that's missing. But the later ucode4
> which also uses the old instruction set is available in v4.
> OTOH, ucode13 isn't available in v3. We can't offer one firmware version
> for all card revisions. Both are limited to a specific range of
> revisions.
>
> v3 rev2...rev12
> v4 rev4...<=rev13

The upper limit doesn't really matter, afaict the effect of running a
rev9 instead of rev13 will just be a missing performance increase due to
bigger FIFOs not being used fully.

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-09 19:59:05

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

>> This is correct. Why do you think it's a specs bug?
>
> Because
> a) The old one made more sense to me.
> b) Write MMIO register 0x3? I mean. What is that?
> Could this be PHY or radio register 0x3?
>

Apologies. You are correct that this should be PHY Register 0x3,
not MMIO offset 0x3. I've corrected this in the specs.

-Joe

2007-02-11 13:24:25

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Fri, 2007-02-09 at 21:32 +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
>
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
>
> Just to make sure I'm understanding this correctly - does the v4
> firmware drop compatibility for older cards, or is it just that Broadcom
> dropped support in the driver at the same time as the firmware changed,
> and the new firmware will still also drive the old cards?

No, the older cards have a completely different MAC processor and
Broadcom hasn't bothered to create v4 firmware for it since they dropped
support for it along with creating new drivers (probably one decision
influenced the other, creating a v2 firmware is likely more work than a
v3+)

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-09 17:29:53

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

> dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x,
Revision %x\n",

You should change this too, the "Version" text should read "Analog"
instead.

-Joe

2007-02-09 22:17:56

by Matthew Garrett

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:

> My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> by that time, and that maintenance will only require following kernel API changes.

Just to make sure I'm understanding this correctly - does the v4
firmware drop compatibility for older cards, or is it just that Broadcom
dropped support in the driver at the same time as the firmware changed,
and the new firmware will still also drive the old cards?

--
Matthew Garrett | [email protected]

2007-02-15 16:51:32

by Martin Langer

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Thu, Feb 15, 2007 at 04:19:13PM +0100, Johannes Berg wrote:
> On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> > On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > > >
> > > > > > It's likely that old cards still work with v4 firmware,
> > > > >
> > > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > > instruction set in the microcode.
> > > >
> > > > Ok, I was not talking about _that_ old cards. ;)
> > >
> > > Are there cards where they have new microcode instruction set but no v4
> > > firmware?
> >
> > I don't know. I guessed so. Am I wrong? That would be good :)
>
> I wouldn't think so since we have rev5 v4 firmware and that should be
> the oldest post-rev4 right?

Yep. We have all kinds of firmware with the new instruction set. It's
only ucode2 (old instruction set) that's missing. But the later ucode4
which also uses the old instruction set is available in v4.
OTOH, ucode13 isn't available in v3. We can't offer one firmware version
for all card revisions. Both are limited to a specific range of
revisions.

v3 rev2...rev12
v4 rev4...<=rev13

Martin

2007-02-09 19:05:10

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.

That's also part of the problem. With the v4 driver, Broadcom
dropped support for a number of older BPHY devices (4301/4303 and
some 4306 revisions). Do we still want to support those? Should I
continue writing the specs for the uCode revision it's based on or
should I combine them?

-Joe

2007-02-10 06:02:40

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 22:32, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
>
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
>
> Just to make sure I'm understanding this correctly - does the v4
> firmware drop compatibility for older cards, or is it just that Broadcom
> dropped support in the driver at the same time as the firmware changed,
> and the new firmware will still also drive the old cards?

We don't know.

It's likely that old cards still work with v4 firmware, but we don't know and
it has to be tested.

Care to do so?

2007-02-09 19:55:32

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Michael Buesch wrote:
> On Friday 09 February 2007 20:05, Joseph Jezak wrote:
>>> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
>> That's also part of the problem. With the v4 driver, Broadcom
>> dropped support for a number of older BPHY devices (4301/4303 and
>> some 4306 revisions). Do we still want to support those? Should I
>> continue writing the specs for the uCode revision it's based on or
>> should I combine them?
>
> If it's easily possible, please try to combine the old stuff
> with the new v4 specs.
> I think it's basically only dropped if() branches, right?
>

Well, here's the problem. There are a few places where a value is
changed (different value written to a register). Does this mean
that the value is different due to the uCode changes (can't tell, no
documentation)? Is it applicable to all revisions (can't tell, some
revisions are not supported in this version)? If the revision
number range in a check changes is that because of a difference in
supported cards or a bug fix?

So, it's not as simple as just dropped if() branches. I can do my
best to combine them (I have done some of this already), but I can't
promise that it'll be accurate for all revisions or versions of the
chipset.

-Joe

2007-02-14 19:04:19

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Fri, 2007-02-09 at 14:55 -0500, Joseph Jezak wrote:

> Well, here's the problem. There are a few places where a value is
> changed (different value written to a register). Does this mean
> that the value is different due to the uCode changes (can't tell, no
> documentation)?

From what I've seen in the ucode that question isn't really too hard to
answer: as long as it's not in the shared memory or ucode register space
the ucode can't really have an influence.

> Is it applicable to all revisions (can't tell, some
> revisions are not supported in this version)?

Best bet would be to make it conditional right now and have someone test
for these cases with older hw.

> If the revision
> number range in a check changes is that because of a difference in
> supported cards or a bug fix?

Hmm. Same I guess, use the new check for new hw and the old check for
old hw, i.e. assume it's the former and not a bug fix (until tested
otherwise.)

I think our best bet is to treat the older hw the same as the older
driver does.

A bigger problem, IMO, is that we'd have to support all the older
microcode things which is a bit tricky since things in shm have moved a
lot... Maybe we should find a third maintainer who has access to a
couple of old cards :)

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-11 02:28:44

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

> It's likely that old cards still work with v4 firmware, but we don't know and
> it has to be tested.
>
> Care to do so?

I'm fairly sure the reason for dropping the old cards is that the
on-board memory which holds the firmware isn't large enough to hold
the newer firmware. I can't find my documentation for that at the
moment though. Feel free to test and I'll confirm it later if I can
find the info.

I'd suspect it doesn't work though since they provided a different
firmware (ucode2) in the past.

-Joe

2007-02-09 22:52:41

by Martin Langer

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Fri, Feb 09, 2007 at 09:32:39PM +0000, Matthew Garrett wrote:
> On Fri, Feb 09, 2007 at 01:26:25PM -0600, Larry Finger wrote:
>
> > My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
> > after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
> > by that time, and that maintenance will only require following kernel API changes.
>
> Just to make sure I'm understanding this correctly - does the v4
> firmware drop compatibility for older cards, or is it just that Broadcom
> dropped support in the driver at the same time as the firmware changed,
> and the new firmware will still also drive the old cards?

We can't extract bcm43xx_microcode2.fw from v4 drivers. You need this
file for old rev2+3 0x812 cores. So we don't know what firmware we
should load into those old cores. I think broadcom never developed a new
v4 style firmware for their old hardware.

Martin

2007-02-15 15:13:40

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > >
> > > > It's likely that old cards still work with v4 firmware,
> > >
> > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > instruction set in the microcode.
> >
> > Ok, I was not talking about _that_ old cards. ;)
>
> Are there cards where they have new microcode instruction set but no v4
> firmware?

I don't know. I guessed so. Am I wrong? That would be good :)

--
Greetings Michael.

2007-02-09 19:26:47

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 20:17, Joseph Jezak wrote:
> >
> > The specs are unclear at this point:
> > "Write the value to the offset"
> > Offset in which register type?
>
> PHY Register. I've clarified it in the specs, I think this was said
> before, I made it worse when I cleaned it up.
>
> >> // Initialization
> >> - if (phy->version == 0) {
> >> + if (phy->analog == 0) {
> >> bcm43xx_write16(bcm, 0x03E6, 0x0122);
> >> } else {
> >> - if (phy->version >= 2)
> >> - bcm43xx_write16(bcm, 0x03E6, 0x0040);
> >> + if (phy->analog >= 2)
> >> + bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> >> + & 0xFFBF) | 0x0040);
> >
> > I think here is a specs bug.
>
> This is correct. Why do you think it's a specs bug?

Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
Could this be PHY or radio register 0x3?

--
Greetings Michael.

2007-02-27 23:32:05

by Gavin McCullagh

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Hi,

On Sat, 10 Feb 2007, Matthew Garrett wrote:

> On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:
>
> > It's likely that old cards still work with v4 firmware, but we don't know and
> > it has to be tested.
> >
> > Care to do so?
>
> I'll check the revision of my 4306, but I think it's probably too new to
> be useful, unfortunately...

I have a fairly old 4306 at home which I was lent by my boss and I've been
struggling to get it working for the past week or two. What I find is that
loads of firmwares which I try with bcm43xx-fwcutter complain about the
firmware being old but then when I get a firmware which is not too old the
device registers but doesn't seem to work -- iwlist can't see any access
points and when I set the essid it doesn't associate with the AP.

Can I be helpful as a tester?

Gavin

2007-02-09 18:45:53

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
>
> Signed-off-by: Larry Finger<[email protected]>

> if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
> (bcm->board_type != 0x0416)) {
> + value = 0x2120;
> for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> - bcm43xx_phy_write(bcm, offset,
> - (bcm43xx_phy_read(bcm, offset) + 0x2020)
> - & 0x3F3F);
> + bcm43xx_phy_write(bcm, offset, value);

The specs are unclear at this point:
"Write the value to the offset"
Offset in which register type?

> @@ -933,6 +934,8 @@ static void bcm43xx_phy_initb6(struct bc
> bcm43xx_phy_read(bcm, 0x0802) | 0x0100);
> bcm43xx_phy_write(bcm, 0x042B,
> bcm43xx_phy_read(bcm, 0x042B) | 0x2000);
> + bcm43xx_phy_write(bcm, 0x5B, 0x0000);
> + bcm43xx_phy_write(bcm, 0x5C, 0x0000);
> }
>
> /* Force to channel 7, even if not supported. */

Backup and reset old_channel later here, too.
Also, look at this:

# If the current channel is 8 or greater
1. Set the channel to 1
# Otherwise
1. Set the channel to 13

> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> @@ -1393,11 +1393,12 @@ u16 bcm43xx_radio_init2050(struct bcm43x
> backup[12] = bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT);
>
> // Initialization
> - if (phy->version == 0) {
> + if (phy->analog == 0) {
> bcm43xx_write16(bcm, 0x03E6, 0x0122);
> } else {
> - if (phy->version >= 2)
> - bcm43xx_write16(bcm, 0x03E6, 0x0040);
> + if (phy->analog >= 2)
> + bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
> + & 0xFFBF) | 0x0040);

I think here is a specs bug.

> bcm43xx_write16(bcm, BCM43xx_MMIO_CHANNEL_EXT,
> (bcm43xx_read16(bcm, BCM43xx_MMIO_CHANNEL_EXT) | 0x2000));
> }

--
Greetings Michael.

2007-02-09 19:17:12

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

>
> The specs are unclear at this point:
> "Write the value to the offset"
> Offset in which register type?

PHY Register. I've clarified it in the specs, I think this was said
before, I made it worse when I cleaned it up.

>> // Initialization
>> - if (phy->version == 0) {
>> + if (phy->analog == 0) {
>> bcm43xx_write16(bcm, 0x03E6, 0x0122);
>> } else {
>> - if (phy->version >= 2)
>> - bcm43xx_write16(bcm, 0x03E6, 0x0040);
>> + if (phy->analog >= 2)
>> + bcm43xx_write16(bcm, 0x0003, (bcm43xx_read16(bcm, 0x0003)
>> + & 0xFFBF) | 0x0040);
>
> I think here is a specs bug.

This is correct. Why do you think it's a specs bug?

-Joe

2007-02-10 12:57:18

by Matthew Garrett

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Sat, Feb 10, 2007 at 06:55:50AM +0100, Michael Buesch wrote:

> We don't know.
>
> It's likely that old cards still work with v4 firmware, but we don't know and
> it has to be tested.
>
> Care to do so?

I'll check the revision of my 4306, but I think it's probably too new to
be useful, unfortunately...

--
Matthew Garrett | [email protected]

2007-02-09 19:26:32

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Joe,

Joseph Jezak wrote:

> That's also part of the problem. With the v4 driver, Broadcom dropped
> support for a number of older BPHY devices (4301/4303 and some 4306
> revisions). Do we still want to support those? Should I continue
> writing the specs for the uCode revision it's based on or should I
> combine them?

As my 4306 is a rev 1 and is likely a version dropped in the V4 driver, I have a special interest in
this question.

My plan is to continue to maintain bcm43xx-SoftMAC for at least the BPHY and 4306 revisions even
after d80211 becomes the in-kernel driver. Of course, I hope that we will have found the killer bugs
by that time, and that maintenance will only require following kernel API changes.

As the work will be yours, you should decide if you would rather maintain the V3 and V4 pages
separately, or denote the special requirements of each firmware flavor in a combined set of pages.

Larry

2007-02-14 19:28:40

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Wed, 2007-02-14 at 20:26 +0100, Johannes Berg wrote:
> On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
>
> > I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> > anymore, but the rest is functional.
>
> Oh good. Do they actually work right now?

Heh, stupid question if you say they're functional :)

Anyway, I'm not quite sure how we should keep those old code paths in
there. Maybe having a different wireless driver for the older cores
would be good, maybe split bcm43xx into three drivers, one for the
PCI/SSB stuff and then two SSB drivers for old and new cores?

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-09 17:29:59

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 23:22, Joseph Jezak wrote:
> > Well, I don't review the rest until you say to which specs you did the changes. ;)
>
> http://bcm-specs.sipsolutions.net/B5PHY
>
> Larry was working from the old specs, so when I updated it, I only
> updated the old specs. I'll fix the v4 specs soon.

Ah, ok. I think we should decide on which specs carry most recent information.
I think v3 specs should be considered obsolete and new information/ fixes
should go into v4. It is already too confusing where to find newest information
to a certain thing.

--
Greetings Michael.

2007-02-09 19:17:41

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 20:05, Joseph Jezak wrote:
> > I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
>
> That's also part of the problem. With the v4 driver, Broadcom
> dropped support for a number of older BPHY devices (4301/4303 and
> some 4306 revisions). Do we still want to support those? Should I
> continue writing the specs for the uCode revision it's based on or
> should I combine them?

If it's easily possible, please try to combine the old stuff
with the new v4 specs.
I think it's basically only dropped if() branches, right?

--
Greetings Michael.

2007-02-14 19:26:27

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:

> I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
> anymore, but the rest is functional.

Oh good. Do they actually work right now?

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-09 17:27:47

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

> Well, I don't review the rest until you say to which specs you did the changes. ;)

http://bcm-specs.sipsolutions.net/B5PHY

Larry was working from the old specs, so when I updated it, I only
updated the old specs. I'll fix the v4 specs soon.

-Joe

2007-02-15 15:19:18

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
> On Thursday 15 February 2007 16:07, Johannes Berg wrote:
> > On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
> > > On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
> > > > On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
> > > >
> > > > > It's likely that old cards still work with v4 firmware,
> > > >
> > > > No, it's absolutely impossible. Rev 2/4 cores have a totally different
> > > > instruction set in the microcode.
> > >
> > > Ok, I was not talking about _that_ old cards. ;)
> >
> > Are there cards where they have new microcode instruction set but no v4
> > firmware?
>
> I don't know. I guessed so. Am I wrong? That would be good :)

I wouldn't think so since we have rev5 v4 firmware and that should be
the oldest post-rev4 right?

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-14 19:04:23

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:

> It's likely that old cards still work with v4 firmware,

No, it's absolutely impossible. Rev 2/4 cores have a totally different
instruction set in the microcode.

johannes

Attachments:

signature.asc (190.00 B)
This is a digitally signed message part

2007-02-14 22:28:29

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Johannes Berg wrote:
> On Wed, 2007-02-14 at 13:13 -0600, Larry Finger wrote:
>
>> I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
>> anymore, but the rest is functional.
>
> Oh good. Do they actually work right now?
>
> johannes

With the patches I pulled yesterday, they work to 54Mbs. Performance is not as good as the 4311 or
4318 cards, but usable.

Larry

2007-02-09 20:30:50

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 20:55, Joseph Jezak wrote:
> Michael Buesch wrote:
> > On Friday 09 February 2007 20:05, Joseph Jezak wrote:
> >>> I'll agree to that as long as there is a clear indication of any differences between V3 and V4 firmware.
> >> That's also part of the problem. With the v4 driver, Broadcom
> >> dropped support for a number of older BPHY devices (4301/4303 and
> >> some 4306 revisions). Do we still want to support those? Should I
> >> continue writing the specs for the uCode revision it's based on or
> >> should I combine them?
> >
> > If it's easily possible, please try to combine the old stuff
> > with the new v4 specs.
> > I think it's basically only dropped if() branches, right?
> >
>
> Well, here's the problem. There are a few places where a value is
> changed (different value written to a register). Does this mean
> that the value is different due to the uCode changes (can't tell, no
> documentation)? Is it applicable to all revisions (can't tell, some
> revisions are not supported in this version)? If the revision
> number range in a check changes is that because of a difference in
> supported cards or a bug fix?
>
> So, it's not as simple as just dropped if() branches. I can do my
> best to combine them (I have done some of this already), but I can't
> promise that it'll be accurate for all revisions or versions of the
> chipset.

Ok, I see.
How many of these old devices exist and who has access to them?
If we want to combine stuff, we really must test it on these devices then.

--
Greetings Michael.

2007-02-09 17:11:51

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

On Friday 09 February 2007 17:32, Larry Finger wrote:
> The specifications for the bcm43xx driver have been modified. This patch
> incorporates these changes in the code, which results in the BCM4311 and
> BCM4312 working. The name of one of the PHY parameters, previously known
> as "version", has been changed to "analog core version" .
>
> Signed-off-by: Larry Finger<[email protected]>
> ---

> @@ -729,19 +729,19 @@ static void bcm43xx_phy_initb5(struct bc
> struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
> struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
> u16 offset;
> + u16 value;
> + u8 old_channel;
>
> - if (phy->version == 1 &&
> - radio->version == 0x2050) {

Why do you delete the check to radio version.
It's still there in latest specs:
http://bcm-v4.sipsolutions.net/802.11/PHY/Init/B5

> + if (phy->analog == 1)
> bcm43xx_radio_write16(bcm, 0x007A,
> bcm43xx_radio_read16(bcm, 0x007A)
> | 0x0050);
> - }
> if ((bcm->board_vendor != PCI_VENDOR_ID_BROADCOM) &&
> (bcm->board_type != 0x0416)) {
> + value = 0x2120;
> for (offset = 0x00A8 ; offset < 0x00C7; offset++) {
> - bcm43xx_phy_write(bcm, offset,
> - (bcm43xx_phy_read(bcm, offset) + 0x2020)
> - & 0x3F3F);
> + bcm43xx_phy_write(bcm, offset, value);
> + value += 0x0202;
> }

I don't see how this matches specs.

> }
> bcm43xx_phy_write(bcm, 0x0035,
> @@ -776,7 +776,7 @@ static void bcm43xx_phy_initb5(struct bc
> bcm43xx_phy_read(bcm, BCM43xx_PHY_RADIO_BITFIELD) | (1 << 11));
> }
>
> - if (phy->version == 1 && radio->version == 0x2050) {

Dito.

> + if (phy->analog == 1) {
> bcm43xx_phy_write(bcm, 0x0026, 0xCE00);
> bcm43xx_phy_write(bcm, 0x0021, 0x3763);
> bcm43xx_phy_write(bcm, 0x0022, 0x1BC3);
> @@ -787,14 +787,15 @@ static void bcm43xx_phy_initb5(struct bc
> bcm43xx_phy_write(bcm, 0x0030, 0x00C6);
> bcm43xx_write16(bcm, 0x03EC, 0x3F22);
>
> - if (phy->version == 1 && radio->version == 0x2050)

Dito.

> + if (phy->analog == 1)
> bcm43xx_phy_write(bcm, 0x0020, 0x3E1C);
> else
> bcm43xx_phy_write(bcm, 0x0020, 0x301C);
>
> - if (phy->version == 0)
> + if (phy->analog == 0)
> bcm43xx_write16(bcm, 0x03E4, 0x3000);
>
> + old_channel = radio->channel;
> /* Force to channel 7, even if not supported. */
> bcm43xx_radio_selectchannel(bcm, 7, 0);
>
> @@ -816,11 +817,11 @@ static void bcm43xx_phy_initb5(struct bc
>
> bcm43xx_radio_write16(bcm, 0x007A, bcm43xx_radio_read16(bcm, 0x007A) | 0x0007);
>
> - bcm43xx_radio_selectchannel(bcm, BCM43xx_RADIO_DEFAULT_CHANNEL_BG, 0);
> + bcm43xx_radio_selectchannel(bcm, old_channel, 0);
>
> bcm43xx_phy_write(bcm, 0x0014, 0x0080);
> bcm43xx_phy_write(bcm, 0x0032, 0x00CA);
> - bcm43xx_phy_write(bcm, 0x88A3, 0x002A);
> + bcm43xx_phy_write(bcm, 0x002A, 0x88A3);

Well, this seems correct, but specs are still different. From where did you get this?

Well, I don't review the rest until you say to which specs you did the changes. ;)

--
Greetings Michael.

2007-02-14 19:13:55

[permalink] [raw]

Subject: Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007

Johannes Berg wrote:
>> supported cards or a bug fix?
>
> Hmm. Same I guess, use the new check for new hw and the old check for
> old hw, i.e. assume it's the former and not a bug fix (until tested
> otherwise.)
>
> I think our best bet is to treat the older hw the same as the older
> driver does.
>
> A bigger problem, IMO, is that we'd have to support all the older
> microcode things which is a bit tricky since things in shm have moved a
> lot... Maybe we should find a third maintainer who has access to a
> couple of old cards :)

I've got a pair of BCM4306 rev 2 cards. One of them is certainly available. Its LEDS don't work
anymore, but the rest is functional.

Larry

2007-02-14 21:40:23