---------- Forwarded Message ----------
Subject: opensource firmware
Date: Friday 09 January 2009
From: Francesco Gringoli <[email protected]>
To: [email protected]
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
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
-------------------------------------------------------
--
Greetings, Michael.
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 <[email protected]>
> To: [email protected]
>
> 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
> [email protected]
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
>
> -------------------------------------------------------
>
--
Greetings, Michael.
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.
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 <[email protected]>
>> To: [email protected]
>>
>> 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
>> [email protected]
>> 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
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.
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 <[email protected]>:
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]> 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
> [email protected]
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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.
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
> [email protected] of your literate lifestyle.
Yes, we have it now. Still testing as several values can be cut out.
Posting ASAP.
Cheers.
-FG
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.
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.
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
[email protected] of your literate lifestyle.
On Fri, 2009-01-09 at 11:49 +0100, Michael Buesch wrote:
> I'd like to start merging this into the "firmware" directory
> of the mainline kernel.
The 'firmware' directory is intended to go away. It only contains the
old firmware which used to be built-in in hex arrays in the source code,
but should never have been.
We have a separate 'linux-firmware' repository, in which we're
collecting new firmwares on top of the stuff we extracted from the
kernel source. That's where we should add the b43 firmware.
--
dwmw2