Hello,
we have been testing the firmware for a week now and it seems stable.
I personally tested it also on a Linksys WRT54GL and it works both in
station and in AP modes. I collected the feedbacks that some of you
sent and it seems that the firmware now runs on these board:
- 4306, 4311, 4318, 4320
I was considering the suggestions you all gave me a few days ago and
other questions related to the possible integration of this firmware
into the kernel, and I came to these conclusions/questions (please
forgive me for this long message :-) )
- change the name of the initvals for the opensource firmware: this
seems a little bit complicated as now the decision about the initval-
files' names and the detection of the firmware type are respectively
based on the phy type and on the firmware date. This means that
initval-files' names can be determine as soon as the hardware type has
been probed, while the firmware needs to be started before the kernel
can determine if it is opensource or not: at this time, however, the
initvals have already been uploaded. What can we do?
- detection of the opensource firmware capabilities: are you really
sure we cannot use a shm location that the bcm proprietary firmware
uses for some other purpose? Once, in fact, the kernel has determined
that the firmware is opensource it can also use a given location in a
different manner than it would do for a proprietary firmware. However
this is not a problem at all :-) as we can use one location in the
"high" shm-memory area, let's say > 0xb00, just choose one.
- what to do with rts procedure: we can implement this feature easily
but I'm not sure about the value it can add to people (the majority of
users?) that use the bcm board in station mode. This is different for
those who run a bcm card in AP mode, but we can clearly discourage
them to run this firmware in AP mode if not sure about rts usage by
stations. However, we put this task in the todo list.
- tx header layout: the opensource firmware is now using the old
memory layout in the tx header (<351). Do you think switching to 410
format is mandatory now or we can concentrate on the other tasks?
- I would like to start considering N-phy on the firmware side. I have
a late 2008 MacBook Pro and I'm not sure if beginning this work on
this platform is a waste of time or not as Apple could have asked
Broadcom a customized chipset. Should I start or is it better if I buy
a N-phy pci board for my x86 box?
Thank you for your time.
Cheers,
-FG
On Friday 23 January 2009 19:01:00 Larry Finger wrote:
> The driver can certainly be coded to look for the open-source firmware
> names before trying to load vendor firmware. That way there will not
> be any confusion.
I already posted that, but in case you missed it:
http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
--
Greetings, Michael.
On Friday 23 January 2009 20:46:45 Francesco Gringoli wrote:
> -- Is using the Broadcom names for the firmware the best course of
> -- action? What if the opensource firmware files were named something
> -- like "os-ucode5.fw", etc. and b43 were coded to check for those files
> -- first? It would then fall back to the standard firmware if the
> -- opensource version is not found.
I answered to this question with this patch:
http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
I am currently testing an updated version of the patch and I'll push it upstream tomorrow.
--
Greetings, Michael.
Francesco Gringoli wrote:
> Damn... that would be a very hard writing.... We do not have any 4311/2
> board: at first glance there are more condition registers whose meaning
> we do not know. Very different hardware, didn't know. Thank you for the
> feedback.
>
> By the way: is that device inside an AP? If yes what? if not which brand
> has the board on? I can look around.
Mine is on a mini-PCIe card in a laptop. The part has an HP Part
#441090-001, but I expect there are Dell equivalents that are cheaper.
I don't know about an AP.
Larry
On Friday 23 January 2009 19:50:37 Dan Williams wrote:
> On Fri, 2009-01-23 at 19:08 +0100, Michael Buesch wrote:
> > On Friday 23 January 2009 19:01:00 Larry Finger wrote:
> > > The driver can certainly be coded to look for the open-source firmware
> > > names before trying to load vendor firmware. That way there will not
> > > be any confusion.
> >
> > I already posted that, but in case you missed it:
> > http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
>
> Preferring the proprietary firmware over the open firmware (for now)
> seems like the best approach at this time. Many people will be quite
> happy with the open firmware that we can actually ship in distros, and
> those that aren't can do the fwcutter stuff and get their own
> proprietary firmware. If for some reason the open firmware isn't
> working, use fwcutter and get the proprietary firmware, which you would
> have had to do before anyway. And those people with chips that aren't
> supported by the proprietary firmware yet still have to use the
> fwcutter, which they would have had to do anyway. Win all around.
Exactly. This is why I implemented it that way.
--
Greetings, Michael.
On Jan 23, 2009, at 8:37 PM, Michael Buesch wrote:
> On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote:
>> On Jan 23, 2009, at 7:01 PM, Larry Finger wrote:
>>
>>> Francesco Gringoli wrote:
>>>> Hello,
>>>>
>>>> we have been testing the firmware for a week now and it seems
>>>> stable. I
>>>> personally tested it also on a Linksys WRT54GL and it works both in
>>>> station and in AP modes. I collected the feedbacks that some of you
>>>> sent
>>>> and it seems that the firmware now runs on these board:
>>>>
>>>> - 4306, 4311, 4318, 4320
>>>
>>> As a point of clarification, I think this is restricted to the
>>> 4311/1
>>> as the 4311/2 uses ucode13, not ucode5. If you need a tester for an
>>> open-source version of the 13 firmware, I'm available.
>> Damn... that would be a very hard writing.... We do not have any
>> 4311/2 board: at first glance there are more condition registers
>> whose
>> meaning we do not know. Very different hardware, didn't know. Thank
>> you for the feedback.
>
> Well, if you didn't notice it already, there are a zillion different
> flavors
> of the broadcom wireless chip out there. So if you buy a random
> device, you're almost
> guaranteed that you don't have that flavor already. ;)
Ehm... I begin to notice now... we were so engaged in understanding
the tx state machine that we lost this _huge_ detail(!). They
(Broadcom) should have plenty of engineers to design so many different
chipsets.
Cheers,
-FG
On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
> > Nothing. Why do we need to have different names?
> Well, I was only considering a question raised by John, we can surely
> maintain these names.
I guess I missed that. What was the question?
Note that proprietary and open firmwares are in separate directories, so
I don't see why we should rename them.
Renaming firmware is a huge pain. We did it several times in the past and
I really want to avoid it. It creates a major confusion for users for some months.
> >> - detection of the opensource firmware capabilities: are you really
> >> sure we cannot use a shm location that the bcm proprietary firmware
> >> uses for some other purpose?
> >
> > Yes, well. You're not intermixing an earlier discussion into this,
> > where
> > you didn't indicate opensource capabilities to the kernel.
> > If you indicate OS capabilities, you can use whatever offset you
> > want, of course.
> Excellent. We will modify the firmware accordingly and encode the
> options.
Thanks. Would be nice if you could also do the corresponding driver patch.
> >> - what to do with rts procedure: we can implement this feature easily
> >> but I'm not sure about the value it can add to people (the majority
> >> of
> >> users?) that use the bcm board in station mode. This is different for
> >> those who run a bcm card in AP mode, but we can clearly discourage
> >> them to run this firmware in AP mode if not sure about rts usage by
> >> stations. However, we put this task in the todo list.
> >
> > RTS/CTS is not specific to AP mode. It's used on any station in the
> > BSS.
> > See IEEE 802.11 specs.
> Yes, in fact we put this task in the todo list.
Thanks.
> >> - tx header layout: the opensource firmware is now using the old
> >> memory layout in the tx header (<351). Do you think switching to 410
> >> format is mandatory now or we can concentrate on the other tasks?
> >
> > Yes, the old format is deprecated and will be removed soon.
> Ok, first task in the todo list!
Well, doesn't need to the the first one. Just note that support for this is
scheduled to be removed in summer 2008. So if any problems show up (broadcom
releases yet another API, for example), I will immediately remove it.
> Ok, thanks for the hint. I will check,
There are a few things we're not yet sure about.
For example the operand for the GPR number got an additional bit.
But we're not sure if the real number of GPRs also was doubled in the hardware.
There are a few FIXMEs in the code for this...
I think this simply has to be tested by trial and error.
--
Greetings, Michael.
On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote:
> Hello,
>
> we have been testing the firmware for a week now and it seems stable.
> I personally tested it also on a Linksys WRT54GL and it works both in
> station and in AP modes. I collected the feedbacks that some of you
> sent and it seems that the firmware now runs on these board:
>
> - 4306, 4311, 4318, 4320
I don't think it has enough testing, yet.
> I was considering the suggestions you all gave me a few days ago and
> other questions related to the possible integration of this firmware
> into the kernel, and I came to these conclusions/questions (please
> forgive me for this long message :-) )
I don't think we want to have the firmware in the kernel.
Instead distributions should simply ship the firmware in a package.
That's not our business.
> - change the name of the initvals for the opensource firmware: this
Why?
> seems a little bit complicated as now the decision about the initval-
> files' names and the detection of the firmware type are respectively
> based on the phy type and on the firmware date. This means that
> initval-files' names can be determine as soon as the hardware type has
> been probed, while the firmware needs to be started before the kernel
> can determine if it is opensource or not: at this time, however, the
> initvals have already been uploaded. What can we do?
Nothing. Why do we need to have different names?
> - detection of the opensource firmware capabilities: are you really
> sure we cannot use a shm location that the bcm proprietary firmware
> uses for some other purpose?
Yes, well. You're not intermixing an earlier discussion into this, where
you didn't indicate opensource capabilities to the kernel.
If you indicate OS capabilities, you can use whatever offset you want, of course.
> - what to do with rts procedure: we can implement this feature easily
> but I'm not sure about the value it can add to people (the majority of
> users?) that use the bcm board in station mode. This is different for
> those who run a bcm card in AP mode, but we can clearly discourage
> them to run this firmware in AP mode if not sure about rts usage by
> stations. However, we put this task in the todo list.
RTS/CTS is not specific to AP mode. It's used on any station in the BSS.
See IEEE 802.11 specs.
> - tx header layout: the opensource firmware is now using the old
> memory layout in the tx header (<351). Do you think switching to 410
> format is mandatory now or we can concentrate on the other tasks?
Yes, the old format is deprecated and will be removed soon.
> - I would like to start considering N-phy on the firmware side. I have
> a late 2008 MacBook Pro and I'm not sure if beginning this work on
> this platform is a waste of time or not as Apple could have asked
> Broadcom a customized chipset. Should I start or is it better if I buy
> a N-phy pci board for my x86 box?
A little bit of b43-asm work is still needed for this core.
There are a few FIXMEs in the code. Not sure, maybe there's more to do.
I didn't try that, yet.
Before you start, you'll have to verify whether the assembler works correctly.
Same for the disassembler.
--
Greetings, Michael.
On Fri, 2009-01-23 at 18:36 +0100, Francesco Gringoli wrote:
> Hello,
>
> we have been testing the firmware for a week now and it seems stable.
> I personally tested it also on a Linksys WRT54GL and it works both in
> station and in AP modes.
Did you try pushing it hard? i.e. doing a nice big bulk transfer
through it? Did it reach decent speeds without pegging the CPU with
softirqs?
Can you give details on which kernel(s) and how you built/configured the
router firmware(s)?
b.
On Jan 23, 2009, at 7:01 PM, Larry Finger wrote:
> Francesco Gringoli wrote:
>> Hello,
>>
>> we have been testing the firmware for a week now and it seems
>> stable. I
>> personally tested it also on a Linksys WRT54GL and it works both in
>> station and in AP modes. I collected the feedbacks that some of you
>> sent
>> and it seems that the firmware now runs on these board:
>>
>> - 4306, 4311, 4318, 4320
>
> As a point of clarification, I think this is restricted to the 4311/1
> as the 4311/2 uses ucode13, not ucode5. If you need a tester for an
> open-source version of the 13 firmware, I'm available.
Damn... that would be a very hard writing.... We do not have any
4311/2 board: at first glance there are more condition registers whose
meaning we do not know. Very different hardware, didn't know. Thank
you for the feedback.
By the way: is that device inside an AP? If yes what? if not which
brand has the board on? I can look around.
Cheers,
-FG
Francesco Gringoli wrote:
> Hello,
>
> we have been testing the firmware for a week now and it seems stable. I
> personally tested it also on a Linksys WRT54GL and it works both in
> station and in AP modes. I collected the feedbacks that some of you sent
> and it seems that the firmware now runs on these board:
>
> - 4306, 4311, 4318, 4320
As a point of clarification, I think this is restricted to the 4311/1
as the 4311/2 uses ucode13, not ucode5. If you need a tester for an
open-source version of the 13 firmware, I'm available.
> I was considering the suggestions you all gave me a few days ago and
> other questions related to the possible integration of this firmware
> into the kernel, and I came to these conclusions/questions (please
> forgive me for this long message :-) )
>
> - change the name of the initvals for the opensource firmware: this
> seems a little bit complicated as now the decision about the
> initval-files' names and the detection of the firmware type are
> respectively based on the phy type and on the firmware date. This means
> that initval-files' names can be determine as soon as the hardware type
> has been probed, while the firmware needs to be started before the
> kernel can determine if it is opensource or not: at this time, however,
> the initvals have already been uploaded. What can we do?
The driver can certainly be coded to look for the open-source firmware
names before trying to load vendor firmware. That way there will not
be any confusion.
> - detection of the opensource firmware capabilities: are you really sure
> we cannot use a shm location that the bcm proprietary firmware uses for
> some other purpose? Once, in fact, the kernel has determined that the
> firmware is opensource it can also use a given location in a different
> manner than it would do for a proprietary firmware. However this is not
> a problem at all :-) as we can use one location in the "high" shm-memory
> area, let's say > 0xb00, just choose one.
I think it best to choose an unused location.
Larry
On Fri, 2009-01-23 at 19:08 +0100, Michael Buesch wrote:
> On Friday 23 January 2009 19:01:00 Larry Finger wrote:
> > The driver can certainly be coded to look for the open-source firmware
> > names before trying to load vendor firmware. That way there will not
> > be any confusion.
>
> I already posted that, but in case you missed it:
> http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
Preferring the proprietary firmware over the open firmware (for now)
seems like the best approach at this time. Many people will be quite
happy with the open firmware that we can actually ship in distros, and
those that aren't can do the fwcutter stuff and get their own
proprietary firmware. If for some reason the open firmware isn't
working, use fwcutter and get the proprietary firmware, which you would
have had to do before anyway. And those people with chips that aren't
supported by the proprietary firmware yet still have to use the
fwcutter, which they would have had to do anyway. Win all around.
If in the future there's a set of chips that the open firmware is known
to work exceptionally well on, it could be preferred over the
proprietary firmware at that point.
Dan
On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote:
> On Jan 23, 2009, at 7:01 PM, Larry Finger wrote:
>
> > Francesco Gringoli wrote:
> >> Hello,
> >>
> >> we have been testing the firmware for a week now and it seems
> >> stable. I
> >> personally tested it also on a Linksys WRT54GL and it works both in
> >> station and in AP modes. I collected the feedbacks that some of you
> >> sent
> >> and it seems that the firmware now runs on these board:
> >>
> >> - 4306, 4311, 4318, 4320
> >
> > As a point of clarification, I think this is restricted to the 4311/1
> > as the 4311/2 uses ucode13, not ucode5. If you need a tester for an
> > open-source version of the 13 firmware, I'm available.
> Damn... that would be a very hard writing.... We do not have any
> 4311/2 board: at first glance there are more condition registers whose
> meaning we do not know. Very different hardware, didn't know. Thank
> you for the feedback.
Well, if you didn't notice it already, there are a zillion different flavors
of the broadcom wireless chip out there. So if you buy a random device, you're almost
guaranteed that you don't have that flavor already. ;)
Another thing is: You simply can _not_ distinguish the devices by the 43xx number in practice.
There are too many devices with the same 43xx number, but different internal designs.
The safest solution for the firmware is to tell by the wireless core revision whether it works or not.
(However, that still leaves a few traps for different PHY and radio revisions, as the firmware also
accesses PHY and radio).
--
Greetings, Michael.
On Jan 23, 2009, at 8:33 PM, Michael Buesch wrote:
> On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
>>> Nothing. Why do we need to have different names?
>> Well, I was only considering a question raised by John, we can surely
>> maintain these names.
>
> I guess I missed that. What was the question?
> Note that proprietary and open firmwares are in separate
> directories, so
> I don't see why we should rename them.
> Renaming firmware is a huge pain. We did it several times in the
> past and
> I really want to avoid it. It creates a major confusion for users
> for some months.
Sorry sorry sorry and sorry again... it was a Larry question, not
John's... pardon me
-- Is using the Broadcom names for the firmware the best course of
-- action? What if the opensource firmware files were named something
-- like "os-ucode5.fw", etc. and b43 were coded to check for those files
-- first? It would then fall back to the standard firmware if the
-- opensource version is not found.
However, it's not a problem maintaining these names.
>>>> - detection of the opensource firmware capabilities: are you really
>>>> sure we cannot use a shm location that the bcm proprietary firmware
>>>> uses for some other purpose?
>>>
>>> Yes, well. You're not intermixing an earlier discussion into this,
>>> where
>>> you didn't indicate opensource capabilities to the kernel.
>>> If you indicate OS capabilities, you can use whatever offset you
>>> want, of course.
>> Excellent. We will modify the firmware accordingly and encode the
>> options.
>
> Thanks. Would be nice if you could also do the corresponding driver
> patch.
Ok, it should be simple.
>>>> - tx header layout: the opensource firmware is now using the old
>>>> memory layout in the tx header (<351). Do you think switching to
>>>> 410
>>>> format is mandatory now or we can concentrate on the other tasks?
>>>
>>> Yes, the old format is deprecated and will be removed soon.
>> Ok, first task in the todo list!
>
> Well, doesn't need to the the first one. Just note that support for
> this is
> scheduled to be removed in summer 2008. So if any problems show up
> (broadcom
> releases yet another API, for example), I will immediately remove it.
Well, it's the first because it's the easiest :-)
>> Ok, thanks for the hint. I will check,
>
> There are a few things we're not yet sure about.
> For example the operand for the GPR number got an additional bit.
> But we're not sure if the real number of GPRs also was doubled in
> the hardware.
> There are a few FIXMEs in the code for this...
> I think this simply has to be tested by trial and error.
Thanks, I will surely check this.
Cheers,
-FG
>
>
> --
> Greetings, Michael.
-------
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
On Jan 23, 2009, at 7:02 PM, Michael Buesch wrote:
> On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote:
>> Hello,
>>
>> we have been testing the firmware for a week now and it seems stable.
>> I personally tested it also on a Linksys WRT54GL and it works both in
>> station and in AP modes. I collected the feedbacks that some of you
>> sent and it seems that the firmware now runs on these board:
>>
>> - 4306, 4311, 4318, 4320
>
> I don't think it has enough testing, yet.
Sure, it seems to be stable on _our_ boards but I can't tell if it
shows the same behavior on other hardware revisions.
>
>
>> I was considering the suggestions you all gave me a few days ago and
>> other questions related to the possible integration of this firmware
>> into the kernel, and I came to these conclusions/questions (please
>> forgive me for this long message :-) )
>
> I don't think we want to have the firmware in the kernel.
> Instead distributions should simply ship the firmware in a package.
> That's not our business.
I agree with you, distributions could easily package the firmware and
distribute it to users when it will be stable, I was just wondering
about.
>> - change the name of the initvals for the opensource firmware: this
>
> Why?
>
>> [cut]
>> initvals have already been uploaded. What can we do?
>
> Nothing. Why do we need to have different names?
Well, I was only considering a question raised by John, we can surely
maintain these names.
>> - detection of the opensource firmware capabilities: are you really
>> sure we cannot use a shm location that the bcm proprietary firmware
>> uses for some other purpose?
>
> Yes, well. You're not intermixing an earlier discussion into this,
> where
> you didn't indicate opensource capabilities to the kernel.
> If you indicate OS capabilities, you can use whatever offset you
> want, of course.
Excellent. We will modify the firmware accordingly and encode the
options.
>> - what to do with rts procedure: we can implement this feature easily
>> but I'm not sure about the value it can add to people (the majority
>> of
>> users?) that use the bcm board in station mode. This is different for
>> those who run a bcm card in AP mode, but we can clearly discourage
>> them to run this firmware in AP mode if not sure about rts usage by
>> stations. However, we put this task in the todo list.
>
> RTS/CTS is not specific to AP mode. It's used on any station in the
> BSS.
> See IEEE 802.11 specs.
Yes, in fact we put this task in the todo list.
>> - tx header layout: the opensource firmware is now using the old
>> memory layout in the tx header (<351). Do you think switching to 410
>> format is mandatory now or we can concentrate on the other tasks?
>
> Yes, the old format is deprecated and will be removed soon.
Ok, first task in the todo list!
>> - I would like to start considering N-phy on the firmware side. I
>> have
>> a late 2008 MacBook Pro and I'm not sure if beginning this work on
>> this platform is a waste of time or not as Apple could have asked
>> Broadcom a customized chipset. Should I start or is it better if I
>> buy
>> a N-phy pci board for my x86 box?
>
> A little bit of b43-asm work is still needed for this core.
> There are a few FIXMEs in the code. Not sure, maybe there's more to
> do.
> I didn't try that, yet.
> Before you start, you'll have to verify whether the assembler works
> correctly.
> Same for the disassembler.
Ok, thanks for the hint. I will check,
Cheers,
-FG
>
>
> --
> Greetings, Michael.
-------
Francesco Gringoli, PhD - Assistant Professor
Dept. of Electrical Engineering for Automation
University of Brescia
via Branze, 38
25123 Brescia
ITALY
Ph: ++39.030.3715843
FAX: ++39.030.380014
WWW: http://www.ing.unibs.it/~gringoli
On Jan 23, 2009, at 6:44 PM, Brian J. Murrell wrote:
> On Fri, 2009-01-23 at 18:36 +0100, Francesco Gringoli wrote:
>> Hello,
>>
>> we have been testing the firmware for a week now and it seems stable.
>> I personally tested it also on a Linksys WRT54GL and it works both in
>> station and in AP modes.
>
> Did you try pushing it hard? i.e. doing a nice big bulk transfer
> through it? Did it reach decent speeds without pegging the CPU with
> softirqs?
>
> Can you give details on which kernel(s) and how you built/configured
> the
> router firmware(s)?
Well, I just tested a 500Mbytes bulk transfer and I got a mean
throughput of about 5.5Mbit/s, it was a simple infinite wget loop so
we can have some slowness due to TCP. However no errors were logged to
syslog and the AP is still there, it didn't complain about anything.
I built kamikaze yesterday image (r14144), kernel 2.6.25.17, I used
the AP as a station joined to another AP without encryption.
By the way, we did thousands of tests with x86 and we came to the
conclusion that there is no performance (throughput) difference if
compared to the standard proprietary firmware.
Cheers,
-FG