[b43] opensource firmware

[b43] opensource firmware

[Lorenzo Nava]

Hello everybody,

we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf 
. Currently only binary version is available: don't worry, we will  
publish source code as soon as possible!! This first version is a  
"test version": please try it and let us know if everythink is ok...

Today we have also tested a new firmware version that works with WPA2- 
personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested  
on 4306 and 4318 PCI device). If anybody was interested please try new  
firmware with encryption and let us know if it works correctly, thanks!

Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf

Cheers

Lorenzo Nava
Francesco Gringoli

Re: [b43] opensource firmware

[John W. Linville]

On Wed, Jan 14, 2009 at 04:30:47PM +0100, Lorenzo Nava wrote:
> Hello everybody,
> 
> we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf 
> . Currently only binary version is available: don't worry, we will  
> publish source code as soon as possible!! This first version is a  
> "test version": please try it and let us know if everythink is ok...
> 
> Today we have also tested a new firmware version that works with WPA2- 
> personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested  
> on 4306 and 4318 PCI device). If anybody was interested please try new  
> firmware with encryption and let us know if it works correctly, thanks!
> 
> Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf

Awesome...awesome...awesome!!!

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [b43] opensource firmware

[Buran Ayuthia]

My 4311 rev 01 card still works with the new initvals and firmware
using WPA2-personal (both TKIP and CCMP) and without encyrption.  I am
still loading the module using modprobe b43 qos=0.

Buran Ayuthia

On Wed, Jan 14, 2009 at 9:30 AM, Lorenzo Nava <navalorenx@gmail.com> wrote:
> Hello everybody,
>
> we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf
> . Currently only binary version is available: don't worry, we will
> publish source code as soon as possible!! This first version is a
> "test version": please try it and let us know if everythink is ok...
>
> Today we have also tested a new firmware version that works with WPA2-
> personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested
> on 4306 and 4318 PCI device). If anybody was interested please try new
> firmware with encryption and let us know if it works correctly, thanks!
>
> Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
>
> Cheers
>
> Lorenzo Nava
> Francesco Gringoli
>
>
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>

Re: [b43] opensource firmware

[Lorenzo Nava]

Great!

Thank you very much for the help... qos=0 parameter was still needed,  
so it is correct.

cheers

Lorenzo Nava.

On Jan 14, 2009, at 4:57 PM, Buran Ayuthia wrote:

> My 4311 rev 01 card still works with the new initvals and firmware
> using WPA2-personal (both TKIP and CCMP) and without encyrption.  I am
> still loading the module using modprobe b43 qos=0.
>
> Buran Ayuthia
>
> On Wed, Jan 14, 2009 at 9:30 AM, Lorenzo Nava <navalorenx@gmail.com>  
> wrote:
>> Hello everybody,
>>
>> we completed the 1st version of initvals. They are available at http://www.ing.unibs.it/openfwwf
>> . Currently only binary version is available: don't worry, we will
>> publish source code as soon as possible!! This first version is a
>> "test version": please try it and let us know if everythink is ok...
>>
>> Today we have also tested a new firmware version that works with  
>> WPA2-
>> personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested
>> on 4306 and 4318 PCI device). If anybody was interested please try  
>> new
>> firmware with encryption and let us know if it works correctly,  
>> thanks!
>>
>> Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
>>
>> Cheers
>>
>> Lorenzo Nava
>> Francesco Gringoli
>>
>>
>> _______________________________________________
>> Bcm43xx-dev mailing list
>> Bcm43xx-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>

Re: [b43] opensource firmware

[Larry Finger]

Lorenzo Nava wrote:

> Today we have also tested a new firmware version that works with
> WPA2-personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS)
> (tested on 4306 and 4318 PCI device). If anybody was interested please
> try new firmware with encryption and let us know if it works correctly,
> thanks!

On my BCM4318 (Linksys WPC54G, Ver 3) in a Cardbus format in a
WPA2-personal encrypted network with AES algorithm, it nearly worked.
With your firmware, it can scan and authenticate. It even gets an
DHCP-supplied IP address; however, I get no data through the link. In
addition, I see lots of PHY TRANSMISSION ERRORS. When I disable
hardware encryption (nohwcrypt=1), then it works.

Great job.

Larry

Re: [b43] opensource firmware

[Michael Buesch]

On Wednesday 14 January 2009 18:43:27 Larry Finger wrote:
> Lorenzo Nava wrote:
> 
> > Today we have also tested a new firmware version that works with
> > WPA2-personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS)
> > (tested on 4306 and 4318 PCI device). If anybody was interested please
> > try new firmware with encryption and let us know if it works correctly,
> > thanks!
> 
> On my BCM4318 (Linksys WPC54G, Ver 3) in a Cardbus format in a
> WPA2-personal encrypted network with AES algorithm, it nearly worked.
> With your firmware, it can scan and authenticate. It even gets an
> DHCP-supplied IP address; however, I get no data through the link. In
> addition, I see lots of PHY TRANSMISSION ERRORS. When I disable
> hardware encryption (nohwcrypt=1), then it works.

Support for hardware crypto would require to reverse engineer the PCM firmware, first.
So we can't support hw-crypto, except on new devices that don't have a PCM anymore.
But these are not rev5 cores :)

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Lorenzo Nava]

2009/1/14 Larry Finger <Larry.Finger@lwfinger.net>:
> Lorenzo Nava wrote:
>
>> Today we have also tested a new firmware version that works with
>> WPA2-personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS)
>> (tested on 4306 and 4318 PCI device). If anybody was interested please
>> try new firmware with encryption and let us know if it works correctly,
>> thanks!
>
> On my BCM4318 (Linksys WPC54G, Ver 3) in a Cardbus format in a
> WPA2-personal encrypted network with AES algorithm, it nearly worked.
> With your firmware, it can scan and authenticate. It even gets an
> DHCP-supplied IP address; however, I get no data through the link. In
> addition, I see lots of PHY TRANSMISSION ERRORS. When I disable
> hardware encryption (nohwcrypt=1), then it works.

Yes, you're right. Actually there are 2 ways to make firmware works:

1) Disable hw crypto with module parameter
2) Remove pcm5.fw from your /lib/firmware/b43 directory

When I run the firmware I never include pcm5.fw file. The only
initvals really necessary are b0g0bsinitvals.fw and b0g0bsinitvals.fw.

cheers

Lorenzo
>
> Great job.
>
> Larry
>

Re: [b43] opensource firmware

[gavron]

Lorenzo Nava wrote:
> Yes, you're right. Actually there are 2 ways to make firmware works:
> 1) Disable hw crypto with module parameter
> 2) Remove pcm5.fw from your /lib/firmware/b43 directory
>
> When I run the firmware I never include pcm5.fw file. The only
> initvals really necessary are b0g0bsinitvals.fw and b0g0bsinitvals.fw.
>   
Pardon me, but those filenames are identical and contain no numbers.  
Did those get stripped off somewhere?
> cheers
>
> Lorenzo
>   
Larry Finger had written:
>> Great job.
>>
>> Larry
>>
>>     
Absolutely!!!!!!!! 

Ehud

-- 
Legal Disclaimer that you are now contractually bound to under all laws with no recourse:
http://attrition.org/security/rants/z/disclaimers.html

Re: [b43] opensource firmware

[Lorenzo Nava]

> Pardon me, but those filenames are identical and contain no numbers.  Did
> those get stripped off somewhere?
>>

I did a mistake. The correct name are b0g0bsinitvals5.fw and
b0g0initvals5.fw for revision 5.

Sorry

Cheers

Lorenzo

Re: [b43] opensource firmware

[Johannes Berg]

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


> Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf

I suggest that before this is packaged, we change it so b43 can
recognise it and automatically disable qos and hwcrypto.

johannes

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

Re: [b43] opensource firmware

[John W. Linville]

On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote:
> 
> > Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
> 
> I suggest that before this is packaged, we change it so b43 can
> recognise it and automatically disable qos and hwcrypto.

That's a good idea.  Is that simply a driver patch?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [b43] opensource firmware

[Johannes Berg]

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

On Wed, 2009-01-14 at 16:09 -0500, John W. Linville wrote:
> On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote:
> > 
> > > Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
> > 
> > I suggest that before this is packaged, we change it so b43 can
> > recognise it and automatically disable qos and hwcrypto.
> 
> That's a good idea.  Is that simply a driver patch?

Should be fairly simple, yeah.

johannes

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

Re: [b43] opensource firmware

[Kyle McMartin]

On Wed, Jan 14, 2009 at 10:20:50PM +0100, Johannes Berg wrote:
> On Wed, 2009-01-14 at 16:09 -0500, John W. Linville wrote:
> > On Wed, Jan 14, 2009 at 09:45:22PM +0100, Johannes Berg wrote:
> > > 
> > > > Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
> > > 
> > > I suggest that before this is packaged, we change it so b43 can
> > > recognise it and automatically disable qos and hwcrypto.
> > 
> > That's a good idea.  Is that simply a driver patch?
> 
> Should be fairly simple, yeah.
> 

Testing a patch now, I'll fire it off to the list when I've made
sure it works alright. (Damn, my cardbus b43 card appears to have bought
the farm recently. Oh well. I'll figure something out)

regards, Kyle

Re: [b43] opensource firmware

[Michael Buesch]

On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
> 
> > Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
> 
> I suggest that before this is packaged, we change it so b43 can
> recognise it and automatically disable qos and hwcrypto.

Yes, please introduce a feature-bitfield at some location in SHM that's unused
by the proprietary firmware. This bitfields would contain a bit for QoS and
a bit for hwcrypto.
Also change your firmware so the driver detects it as open-source firmware.
I think that's done by writing 0xFFFF to the date/time field in SHM. I don't
quite remember, but it's something like that.
Note that this might mean that the firmware watchdog in the driver will trigger,
as that's enabled by the open-source-firmware-flag. We might want to temporarly
disable the watchdog in the driver for the time being.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Michael Buesch]

On Thursday 15 January 2009 16:37:57 Michael Buesch wrote:
> On Wednesday 14 January 2009 21:45:22 Johannes Berg wrote:
> > 
> > > Initvals and new firmware version can be found at http://www.ing.unibs.it/openfwwf
> > 
> > I suggest that before this is packaged, we change it so b43 can
> > recognise it and automatically disable qos and hwcrypto.
> 
> Yes, please introduce a feature-bitfield at some location in SHM that's unused
> by the proprietary firmware. This bitfields would contain a bit for QoS and
> a bit for hwcrypto.
> Also change your firmware so the driver detects it as open-source firmware.
> I think that's done by writing 0xFFFF to the date/time field in SHM. I don't
> quite remember, but it's something like that.
> Note that this might mean that the firmware watchdog in the driver will trigger,
> as that's enabled by the open-source-firmware-flag. We might want to temporarly
> disable the watchdog in the driver for the time being.
> 

Ah and also note that hwcrypto is already automagically disabled, if the driver
detects an opensource-firmware.
To make the driver detect the firmware as opensource, write 0xFFFF to SHM_UCODEDATE

You need to disable the watchdog in b43_periodic_every15sec(), if you don't implement
the watchdog mechanism in your firmware. But it's pretty easy to implement.
It just has to write 0 to some register in the MAC loop. Of course, the register has
to be unused in the rest of the code.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Larry Finger]

Michael Buesch wrote:
> Yes, please introduce a feature-bitfield at some location in SHM that's unused
> by the proprietary firmware. This bitfields would contain a bit for QoS and
> a bit for hwcrypto.
> Also change your firmware so the driver detects it as open-source firmware.
> I think that's done by writing 0xFFFF to the date/time field in SHM. I don't
> quite remember, but it's something like that.
> Note that this might mean that the firmware watchdog in the driver will trigger,
> as that's enabled by the open-source-firmware-flag. We might want to temporarly
> disable the watchdog in the driver for the time being.

I like the idea of encoding the capabilities in the firmware as it
would be a self-documenting method as the firmware evolves.

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.

Larry

Re: [b43] opensource firmware

[Michael Buesch]

On Thursday 15 January 2009 16:59:11 Larry Finger wrote:
> Michael Buesch wrote:
> > Yes, please introduce a feature-bitfield at some location in SHM that's unused
> > by the proprietary firmware. This bitfields would contain a bit for QoS and
> > a bit for hwcrypto.
> > Also change your firmware so the driver detects it as open-source firmware.
> > I think that's done by writing 0xFFFF to the date/time field in SHM. I don't
> > quite remember, but it's something like that.
> > Note that this might mean that the firmware watchdog in the driver will trigger,
> > as that's enabled by the open-source-firmware-flag. We might want to temporarly
> > disable the watchdog in the driver for the time being.
> 
> I like the idea of encoding the capabilities in the firmware as it
> would be a self-documenting method as the firmware evolves.
> 
> 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.

Already implemented here:
http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
I just need to fix a leak in an error path before pushing that upstream.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Kyle McMartin]

On Thu, Jan 15, 2009 at 05:09:49PM +0100, Michael Buesch wrote:
> Already implemented here:
> http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
> I just need to fix a leak in an error path before pushing that upstream.
> 

Groovy, I had cooked a similar patch for Fedora but haven't gotten
around to packaging up the fw yet. Will sub in yours.

cheers, Kyle

Re: [b43] opensource firmware

[Michael Buesch]

On Friday 16 January 2009 00:17:43 Kyle McMartin wrote:
> On Thu, Jan 15, 2009 at 05:09:49PM +0100, Michael Buesch wrote:
> > Already implemented here:
> > http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch
> > I just need to fix a leak in an error path before pushing that upstream.
> > 
> 
> Groovy, I had cooked a similar patch for Fedora but haven't gotten
> around to packaging up the fw yet. Will sub in yours.

I think we can actually push my patch upstream. The remaining FIXME is not relevant
for the common case and it only matters in rare circumstances (I think A-PHY only, which
isn't implemented anyway). So we can fix it later.
The patch should work properly as-is for G/N/LP-PHY.

It probably needs a rediff against a current b43, however.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Francesco Gringoli]

On Jan 15, 2009, at 4:59 PM, Larry Finger wrote:

> Michael Buesch wrote:
>> Yes, please introduce a feature-bitfield at some location in SHM  
>> that's unused
>> by the proprietary firmware. This bitfields would contain a bit for  
>> QoS and
>> a bit for hwcrypto.
>> Also change your firmware so the driver detects it as open-source  
>> firmware.
>> I think that's done by writing 0xFFFF to the date/time field in  
>> SHM. I don't
>> quite remember, but it's something like that.
>> Note that this might mean that the firmware watchdog in the driver  
>> will trigger,
>> as that's enabled by the open-source-firmware-flag. We might want  
>> to temporarly
>> disable the watchdog in the driver for the time being.
>
> I like the idea of encoding the capabilities in the firmware as it
> would be a self-documenting method as the firmware evolves.
>
> 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.
>
> Larry
It could be interesting to also not separate the initvalues in two  
different files, everything could be coded in a single file. Never  
understood why original init values are split in two files.

Michael: SHM(0x0014) (16bit) is not used by the open source firmware,  
I know the b43 reads core revision from SHM(0x0016). Normally  
SHM(0x0014) is set to zero. We can put fw capabilities here (0x0014),  
e.g.:

- bit 0: [0 state that encryption should be handled by b43]
- bit 1: [0 state that qos is not supported]

We can prepare a firmware image with such feature + watchdog. Posting  
ASAP with new initvals (less values).

A question: is the standard kernel aware that date set to FFFF  
indicates an opensource firmware or some define should be activated on  
compilation?

Cheers,
-FG

Re: [b43] opensource firmware

[Michael Buesch]

On Friday 16 January 2009 00:01:41 Francesco Gringoli wrote:
> On Jan 15, 2009, at 4:59 PM, Larry Finger wrote:
> 
> > Michael Buesch wrote:
> >> Yes, please introduce a feature-bitfield at some location in SHM  
> >> that's unused
> >> by the proprietary firmware. This bitfields would contain a bit for  
> >> QoS and
> >> a bit for hwcrypto.
> >> Also change your firmware so the driver detects it as open-source  
> >> firmware.
> >> I think that's done by writing 0xFFFF to the date/time field in  
> >> SHM. I don't
> >> quite remember, but it's something like that.
> >> Note that this might mean that the firmware watchdog in the driver  
> >> will trigger,
> >> as that's enabled by the open-source-firmware-flag. We might want  
> >> to temporarly
> >> disable the watchdog in the driver for the time being.
> >
> > I like the idea of encoding the capabilities in the firmware as it
> > would be a self-documenting method as the firmware evolves.
> >
> > 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.
> >
> > Larry
> It could be interesting to also not separate the initvalues in two  
> different files, everything could be coded in a single file. Never  
> understood why original init values are split in two files.

The normal initvalues have to be uploaded at init and the bandswitch init
values have to be uploaded on bandswitch. That's a different thing.
We currently implement bandswitch by re-initing, but that doesn't matter. We could
easily change that in future.
So don't put the initvals into one file.

> Michael: SHM(0x0014) (16bit) is not used by the open source firmware,  

Eh no. You need to find an offset that's not used by the PROPRIETARY firmware.

> A question: is the standard kernel aware that date set to FFFF  
> indicates an opensource firmware 

Yes.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Francesco Gringoli]

Hello everyone,

we just made available a new opensource firmware version, download at http://www.ing.unibs.it/openfwwf

New features:
- initvals source code added, initvals files are encoded by make process
- firmware is now recognized as opensource, though still as version  
351 (old format). Firmware's date switched to FFFF
- watchdog implemented

Tested with kernel 2.6.29-rc2-wl.

Cheers,
-FG

Re: [b43] opensource firmware

[Michael Buesch]

On Wednesday 21 January 2009 18:29:40 Francesco Gringoli wrote:
> Hello everyone,
> 
> we just made available a new opensource firmware version, download at http://www.ing.unibs.it/openfwwf
> 
> New features:
> - initvals source code added, initvals files are encoded by make process
> - firmware is now recognized as opensource, though still as version  
> 351 (old format). Firmware's date switched to FFFF
> - watchdog implemented

Note that the debug-IRQ feature is now also available to you.
It enables you to panic, dump SHM, dump regs and print a marker message
from within the firmware. See my openfw repository and handle_irq_ucode_debug() in b43 for details.
Note that the debug-IRQ is synchronous, so it will disturb MAC functionality.
But you only want to use it for debugging anyway. And for debugging it is _very_ convenient
to be able to issue printks and memory dumps from within the firmware code.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Rafał Miłecki]

2009/1/14 Lorenzo Nava <navalorenx@gmail.com>:
> we completed the 1st version of initvals. They are available at http:=
//www.ing.unibs.it/openfwwf
> . Currently only binary version is available: don't worry, we will
> publish source code as soon as possible!! This first version is a
> "test version": please try it and let us know if everythink is ok...
>
> Today we have also tested a new firmware version that works with WPA2=
-
> personal (both TKIP and CCMP) and WPA2-enterprise (EAP-TTLS) (tested
> on 4306 and 4318 PCI device). If anybody was interested please try ne=
w
> firmware with encryption and let us know if it works correctly, thank=
s!
>
> Initvals and new firmware version can be found at http://www.ing.unib=
s.it/openfwwf

I belive you still need testing?

I used openfwwf-5.0.tar.gz and initvals.tar.gz for my bcm4318 card  in
Acer Aspire 5024 (qos=3D0). Scanning works fine, connecting to WPA
Personal network also. I can't check speed performance as I don't have
antenna connected to my card (notebook lid just gone... I belive
"Acer" explains that situation to you?). As for stability it's great.
I downloaded 100MB, left notebook for 24h and then downloaded another
50MB.

So to sum up: I don't feel any difference between opensource and
broardcom's firmware.

--=20
Rafa=C5=82 Mi=C5=82ecki
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: [b43] opensource firmware

[Michael Buesch]

----------  Forwarded Message  ----------

Subject: opensource firmware
Date: Friday 09 January 2009
From: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
To: bcm43xx-dev@lists.berlios.de

Hello folks,

we have been involved in the past few months in testing modifications  
to the standard 802.11 MAC for research purposes. During this time we  
did some tests with Broadcom 802.11b/g boards and we wrote down a  
simple 802.11 compliant firmware that we used as a starting point for  
the modified MAC algorithms.

Although the base firmware is not fully 802.11 compliant, e.g., it  
does not support RTS/CTS procedure or QoS, we believe that someone  
could be interested in testing it. The firmware does not require the  
kernel to be modified and it uses the same shared memory layout and  
global registers usage of the original stuff from broadcom to ease  
loading by the b43 driver (and ease our writing...). We wrote it to  
make the b43 driver recognize it as Broadcom version 5 firmware: it  
still uses the original initval files of that version of the  
Broadcom's firmware, we do not include them as usual users have to  
extract these files following the b43 installation instructions.

Lorenzo and I tested this firmware only on 4306 and 4318 hardware (pci  
and minipci, pc-card based architectures seem to have problems), and  
we did simple tests on the integrated board of a Linksys WRT54GL, so  
we are quite sure it runs on 4306, 4318 and 4320 cards. We did all the  
works on kernel 2.6.27-rc5-wl.

The firmware along with the instructions to build it from the assembly  
code using the tools developed by the b43 community can be found here

	http://www.ing.unibs.it/openfwwf

In the firmware website you can find more information about the fw  
algorithm, its interaction with Broadcom hardware and other  
information that we discovered as we were writing it.

We would like to underline that this work would have not been possible  
without the instruments already developed by the b43 community  
(assembler/disassembler), hardware specifications (sipsolution's  
website), the opensource test firmware written by Michael Buesch and  
useful talks with those guys (b43 developers), which we deeply  
acknowledge. As we used several definition files written by Michael  
for its firmware and we have prepared a source tar file that includes  
them, we kindly ask Michael if this could be a problem.

Finally we stress that this is a TEST firmware and some stuff needs to  
be fixed (e.g. RTS/CTS and QoS), we have been using it as a starting  
point to implement other MAC algorithms for research purposes: if  
someone is interested in this kind of work and would like to share  
ideas also on research topics, please let us know.

Cheers,
Francesco Gringoli
Lorenzo Nava
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


-------------------------------------------------------

-- 
Greetings, Michael.

Re: Fwd: [b43] opensource firmware

[Michael Buesch]

I'd like to start merging this into the "firmware" directory
of the mainline kernel.

On Friday 09 January 2009 11:29:22 Michael Buesch wrote:
> 
> ----------  Forwarded Message  ----------
> 
> Subject: opensource firmware
> Date: Friday 09 January 2009
> From: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
> To: bcm43xx-dev@lists.berlios.de
> 
> Hello folks,
> 
> we have been involved in the past few months in testing modifications  
> to the standard 802.11 MAC for research purposes. During this time we  
> did some tests with Broadcom 802.11b/g boards and we wrote down a  
> simple 802.11 compliant firmware that we used as a starting point for  
> the modified MAC algorithms.
> 
> Although the base firmware is not fully 802.11 compliant, e.g., it  
> does not support RTS/CTS procedure or QoS, we believe that someone  
> could be interested in testing it. The firmware does not require the  
> kernel to be modified and it uses the same shared memory layout and  
> global registers usage of the original stuff from broadcom to ease  
> loading by the b43 driver (and ease our writing...). We wrote it to  
> make the b43 driver recognize it as Broadcom version 5 firmware: it  
> still uses the original initval files of that version of the  
> Broadcom's firmware, we do not include them as usual users have to  
> extract these files following the b43 installation instructions.
> 
> Lorenzo and I tested this firmware only on 4306 and 4318 hardware (pci  
> and minipci, pc-card based architectures seem to have problems), and  
> we did simple tests on the integrated board of a Linksys WRT54GL, so  
> we are quite sure it runs on 4306, 4318 and 4320 cards. We did all the  
> works on kernel 2.6.27-rc5-wl.
> 
> The firmware along with the instructions to build it from the assembly  
> code using the tools developed by the b43 community can be found here
> 
> 	http://www.ing.unibs.it/openfwwf
> 
> In the firmware website you can find more information about the fw  
> algorithm, its interaction with Broadcom hardware and other  
> information that we discovered as we were writing it.
> 
> We would like to underline that this work would have not been possible  
> without the instruments already developed by the b43 community  
> (assembler/disassembler), hardware specifications (sipsolution's  
> website), the opensource test firmware written by Michael Buesch and  
> useful talks with those guys (b43 developers), which we deeply  
> acknowledge. As we used several definition files written by Michael  
> for its firmware and we have prepared a source tar file that includes  
> them, we kindly ask Michael if this could be a problem.
> 
> Finally we stress that this is a TEST firmware and some stuff needs to  
> be fixed (e.g. RTS/CTS and QoS), we have been using it as a starting  
> point to implement other MAC algorithms for research purposes: if  
> someone is interested in this kind of work and would like to share  
> ideas also on research topics, please let us know.
> 
> Cheers,
> Francesco Gringoli
> Lorenzo Nava
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> 
> 
> -------------------------------------------------------
> 



-- 
Greetings, Michael.

Re: Fwd: [b43] opensource firmware

[Michael Buesch]

On Friday 09 January 2009 11:49:28 Michael Buesch wrote:
> I'd like to start merging this into the "firmware" directory
> of the mainline kernel.

Ok, the code doesn't work on my 4306 hardware.
So I think I'll not merge it into the kernel right away, but first merge
it into my b43-openfw git repository, that already partially works on my hardware.
That also gives the code an extra review.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Francesco Gringoli]

Damn! Our 4306 was a mini-pci card mounted on an adapter on a PCI bus.  
Remember to disable qos (qos=0 on module load). Could we have  
different initvals files? Our count

3e5442067f1c945e6180777728a2ea08  b0g0bsinitvals5.fw
f85142421a4a1bcb9dd52c513c1ea558  b0g0initvals5.fw

Finally, what kernel version are you using? We were out of sync since  
late october (stopped ad 2.6.27-rc5-wl)

Cheers,
-FG

On Jan 9, 2009, at 11:58 AM, Michael Buesch wrote:

> On Friday 09 January 2009 11:49:28 Michael Buesch wrote:
>> I'd like to start merging this into the "firmware" directory
>> of the mainline kernel.
>
> Ok, the code doesn't work on my 4306 hardware.
> So I think I'll not merge it into the kernel right away, but first  
> merge
> it into my b43-openfw git repository, that already partially works  
> on my hardware.
> That also gives the code an extra review.
>
> -- 
> Greetings, Michael.

Re: [b43] opensource firmware

[Francesco Gringoli]

Michael,

I think someone else other than us two (me and Lorenzo, here) should  
test the firmware. Have you tested it on your boards?

1) We are pretty sure this firmware works on the hardware we have  
tested it for now six months... nevertheless some external testing  
should be required
2) On Linux RTS/CTS seems to be default disable (at least on the  
kernel we used for testing, 2.6.27-rc5-wl) but if someone enables it  
the driver+firmware chain could freeze and leave the system in  
undetermined state
3) The firmware does not support the QoS interface of b43, it should  
be disable on module load.

Cheers,
-FG

On Jan 9, 2009, at 11:49 AM, Michael Buesch wrote:

> I'd like to start merging this into the "firmware" directory
> of the mainline kernel.
>
> On Friday 09 January 2009 11:29:22 Michael Buesch wrote:
>>
>> ----------  Forwarded Message  ----------
>>
>> Subject: opensource firmware
>> Date: Friday 09 January 2009
>> From: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
>> To: bcm43xx-dev@lists.berlios.de
>>
>> Hello folks,
>>
>> we have been involved in the past few months in testing modifications
>> to the standard 802.11 MAC for research purposes. During this time we
>> did some tests with Broadcom 802.11b/g boards and we wrote down a
>> simple 802.11 compliant firmware that we used as a starting point for
>> the modified MAC algorithms.
>>
>> Although the base firmware is not fully 802.11 compliant, e.g., it
>> does not support RTS/CTS procedure or QoS, we believe that someone
>> could be interested in testing it. The firmware does not require the
>> kernel to be modified and it uses the same shared memory layout and
>> global registers usage of the original stuff from broadcom to ease
>> loading by the b43 driver (and ease our writing...). We wrote it to
>> make the b43 driver recognize it as Broadcom version 5 firmware: it
>> still uses the original initval files of that version of the
>> Broadcom's firmware, we do not include them as usual users have to
>> extract these files following the b43 installation instructions.
>>
>> Lorenzo and I tested this firmware only on 4306 and 4318 hardware  
>> (pci
>> and minipci, pc-card based architectures seem to have problems), and
>> we did simple tests on the integrated board of a Linksys WRT54GL, so
>> we are quite sure it runs on 4306, 4318 and 4320 cards. We did all  
>> the
>> works on kernel 2.6.27-rc5-wl.
>>
>> The firmware along with the instructions to build it from the  
>> assembly
>> code using the tools developed by the b43 community can be found here
>>
>> 	http://www.ing.unibs.it/openfwwf
>>
>> In the firmware website you can find more information about the fw
>> algorithm, its interaction with Broadcom hardware and other
>> information that we discovered as we were writing it.
>>
>> We would like to underline that this work would have not been  
>> possible
>> without the instruments already developed by the b43 community
>> (assembler/disassembler), hardware specifications (sipsolution's
>> website), the opensource test firmware written by Michael Buesch and
>> useful talks with those guys (b43 developers), which we deeply
>> acknowledge. As we used several definition files written by Michael
>> for its firmware and we have prepared a source tar file that includes
>> them, we kindly ask Michael if this could be a problem.
>>
>> Finally we stress that this is a TEST firmware and some stuff needs  
>> to
>> be fixed (e.g. RTS/CTS and QoS), we have been using it as a starting
>> point to implement other MAC algorithms for research purposes: if
>> someone is interested in this kind of work and would like to share
>> ideas also on research topics, please let us know.
>>
>> Cheers,
>> Francesco Gringoli
>> Lorenzo Nava
>> _______________________________________________
>> Bcm43xx-dev mailing list
>> Bcm43xx-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>
>>
>> -------------------------------------------------------
>>
>
>
>
> -- 
> 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: [b43] opensource firmware

[Michael Buesch]

On Friday 09 January 2009 12:00:41 Francesco Gringoli wrote:
> I think someone else other than us two (me and Lorenzo, here) should  
> test the firmware. Have you tested it on your boards?

Yep, it doesn't work.
So I'll first try to (partially) merge it into my git repository and give it an extra review.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Lorenzo Nava]

Hi,

the only advice that I can give you is to pay attention to have the
correct initvals: firmware need v480 firmware initvals.

regards

Lorenzo.

2009/1/9 Michael Buesch <mb@bu3sch.de>:
> On Friday 09 January 2009 12:00:41 Francesco Gringoli wrote:
>> I think someone else other than us two (me and Lorenzo, here) should
>> test the firmware. Have you tested it on your boards?
>
> Yep, it doesn't work.
> So I'll first try to (partially) merge it into my git repository and give it an extra review.
>
> --
> Greetings, Michael.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [b43] opensource firmware

[Lorenzo Nava]

> Yep, it doesn't work.
> So I'll first try to (partially) merge it into my git repository and give it an extra review.

Can you tell us which kind of problem did you have?

Thank

regards

Lorenzo.

>
> --
> Greetings, Michael.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [b43] opensource firmware

[Lorenzo Nava]

Hello everybody,

today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device  
with Broadcom 4306 chipset:

BCM94306 802.11g (rev 03)
PHY: Analog 2, Type 2, Revision 2
Radio: Manuf 0x17F, Version 0x2050, Revision 2

I did some tests and everything seems to work fine.

I remember, once again, that OpenFWWF needs v480 initvals to work  
properly, and was tested on 2.6.27-rc5 kernel.

During firmware development we used these devices

Belkin PCMCIA 4306 card,
Siemens PCI 4306 card.
Belkin PCI 4306 card.
ASUSTeK PCI 4318 card.

and firmware seems to work fine. Everyone that is interested in  
testing OpenFWWF is welcome: please let us know if the firmware works  
correctly, and, if it doesn't, please report which kind of problems  
you had.

Michael please let us know which kind of problem you had with your  
device.

cheers

Lorenzo Nava.

Re: [b43] opensource firmware

[Buran Ayuthia]

I have just tried out the firmware on my 4311 rev 01 using the 2.6.28
kernel and it works!  I am using an HP Pavilion dv6338se laptop.

Here is my lspci info:
03:00.0 Network controller [0280]: Broadcom Corporation BCM94311MCG
wlan mini-PCI [14e4:4311] (rev 01)
        Subsystem: Hewlett-Packard Company Device [103c:1363]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at b6000000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Express (v1) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s,
Latency L0 <4us, L1 <64us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
        Capabilities: [100] Advanced Error Reporting <?>
        Capabilities: [13c] Virtual Channel <?>
        Kernel driver in use: b43-pci-bridge
        Kernel modules: wl, ssb

Please let me know if you need more information.  Also, are we to use
this mailing list or is there another place where this information
should be posted?

Buran Ayuthia

On Sat, Jan 10, 2009 at 11:37 AM, Lorenzo Nava <navalorenx@gmail.com> wrote:
> Hello everybody,
>
> today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device
> with Broadcom 4306 chipset:
>
> BCM94306 802.11g (rev 03)
> PHY: Analog 2, Type 2, Revision 2
> Radio: Manuf 0x17F, Version 0x2050, Revision 2
>
> I did some tests and everything seems to work fine.
>
> I remember, once again, that OpenFWWF needs v480 initvals to work
> properly, and was tested on 2.6.27-rc5 kernel.
>
> During firmware development we used these devices
>
> Belkin PCMCIA 4306 card,
> Siemens PCI 4306 card.
> Belkin PCI 4306 card.
> ASUSTeK PCI 4318 card.
>
> and firmware seems to work fine. Everyone that is interested in
> testing OpenFWWF is welcome: please let us know if the firmware works
> correctly, and, if it doesn't, please report which kind of problems
> you had.
>
> Michael please let us know which kind of problem you had with your
> device.
>
> cheers
>
> Lorenzo Nava.
>
>
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>

Re: [b43] opensource firmware

[John W. Linville]

On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote:
> Hello everybody,
>
> today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with 
> Broadcom 4306 chipset:
>
> BCM94306 802.11g (rev 03)
> PHY: Analog 2, Type 2, Revision 2
> Radio: Manuf 0x17F, Version 0x2050, Revision 2
>
> I did some tests and everything seems to work fine.
>
> I remember, once again, that OpenFWWF needs v480 initvals to work  
> properly, and was tested on 2.6.27-rc5 kernel.

Any chance on getting a set of initvals packaged with the open source
firmware?  That would allow distros like Fedora to package this...

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: [b43] opensource firmware

[Michael Buesch]

On Monday 12 January 2009 16:39:49 John W. Linville wrote:
> On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote:
> > Hello everybody,
> >
> > today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device with 
> > Broadcom 4306 chipset:
> >
> > BCM94306 802.11g (rev 03)
> > PHY: Analog 2, Type 2, Revision 2
> > Radio: Manuf 0x17F, Version 0x2050, Revision 2
> >
> > I did some tests and everything seems to work fine.
> >
> > I remember, once again, that OpenFWWF needs v480 initvals to work  
> > properly, and was tested on 2.6.27-rc5 kernel.
> 
> Any chance on getting a set of initvals packaged with the open source
> firmware?  That would allow distros like Fedora to package this...

Did anybody try with the set of initvals from my git repository?
It includes the major parts. It just misses parts like the default-beacon-template
and stuff. But that's not really needed for now.

-- 
Greetings, Michael.

Re: [b43] opensource firmware

[Francesco Gringoli]

On Jan 12, 2009, at 4:39 PM, John W. Linville wrote:

> On Sat, Jan 10, 2009 at 06:37:43PM +0100, Lorenzo Nava wrote:
>> Hello everybody,
>>
>> today I tried OpenFWWF with kernel 2.6.28 on a Siemens wifi device  
>> with
>> Broadcom 4306 chipset:
>>
>> BCM94306 802.11g (rev 03)
>> PHY: Analog 2, Type 2, Revision 2
>> Radio: Manuf 0x17F, Version 0x2050, Revision 2
>>
>> I did some tests and everything seems to work fine.
>>
>> I remember, once again, that OpenFWWF needs v480 initvals to work
>> properly, and was tested on 2.6.27-rc5 kernel.
>
> Any chance on getting a set of initvals packaged with the open source
> firmware?  That would allow distros like Fedora to package this...
>
> John
> -- 
> John W. Linville		Linux should be at the core
> linville@tuxdriver.com			of your literate lifestyle.
Yes, we have it now. Still testing as several values can be cut out.  
Posting ASAP.
Cheers.
-FG