integration of opensource firmware with b43 kernel driver

integration of opensource firmware with b43 kernel driver

[Francesco Gringoli]

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

Re: integration of opensource firmware with b43 kernel driver

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: integration of opensource firmware with b43 kernel driver

[Francesco 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

Re: integration of opensource firmware with b43 kernel driver

[Larry Finger]

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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.

Re: integration of opensource firmware with b43 kernel driver

[Dan Williams]

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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.

Re: integration of opensource firmware with b43 kernel driver

[Francesco Gringoli]

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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.

Re: integration of opensource firmware with b43 kernel driver

[Francesco Gringoli]

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

Re: integration of opensource firmware with b43 kernel driver

[Larry Finger]

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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.

Re: integration of opensource firmware with b43 kernel driver

[Francesco 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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.

Re: integration of opensource firmware with b43 kernel driver

[Francesco Gringoli]

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

Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch]

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.