Open source firmware for Broadcom wireless adapters
| From: | Francesco Gringoli <francesco.gringoli-i2lwkhdiEHM3ahhDiVHSzw-AT-public.gmane.org> | |
| To: | bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w-AT-public.gmane.org | |
| Subject: | opensource firmware | |
| Date: | Fri, 9 Jan 2009 09:21:52 +0100 | |
| Message-ID: | <1ED57B4C-BDB3-4D7F-BF80-EBE811FE239C@ing.unibs.it> | |
| Archive-link: | Article, Thread |
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
(Log in to post comments)
Lesson for Broadcom
Posted Jan 9, 2009 21:39 UTC (Fri) by proski (subscriber, #104) [Link]
If you don't open the code for your driver, somebody will reverse engineer not only the driver, but also the firmware.I just cannot imagine anyone reverse engineering Intel firmware. It's not interesting because it doesn't help improve the driver. Sure, somebody might hack the existing firmware for some purposes, but reimplementing it completely would be too much work.
Lesson for Broadcom
Posted Jan 9, 2009 22:06 UTC (Fri) by elanthis (guest, #6227) [Link]
With Broadcom, you always had to download the firmware after installing the driver, which was a real bitch when your wireless was your only way to get online in the first place.
Lesson for Broadcom
Posted Jan 9, 2009 23:36 UTC (Fri) by mb (subscriber, #50428) [Link]
Well, note that the reverse engineered broadcom stuff really is a pain in the ass. It has a lot of issues and there are only a few cards where it works at 100% performance on.
I really hope Broadcom will release the driver in the near future, so we can merge their PHY code into b43. That would make Broadcom devices one of the best Linux WLAN devices available. Currently it's probably almost the worst choice to buy a Broadcom card...
Lesson for Broadcom
Posted Jan 11, 2009 17:28 UTC (Sun) by clugstj (subscriber, #4020) [Link]
Lesson for Broadcom
Posted Jan 11, 2009 19:11 UTC (Sun) by mb (subscriber, #50428) [Link]
Yeah, 4318 more or less works now. I'm going to start using a 4318 for my main AP, soon.
But the 4318 still doesn't work as good with b43 as with the binary driver. It also depends a bit on the antennae and stuff, but it's always worse than the original driver. And it probably won't ever become as good as the original stuff.
The problem is two things: I don't have the $50k measureing equipment to debug this and we don't know what most of the PHY registers do. So even if I know what was wrong, it would be basically impossible to fix it.
But there's a lot of hardware that's not supported at all. For instance none of the LowPower-PHY and N-PHY devices are supported, yet. These devices basically are 95% of the broadcom devices sold in notebooks today.
The team is working on these devices, but it will take another few months (at least) until this gets usable.
So yeah. It's probably not-so-much pain in the ass, if you have a device older than say 1.5 or 2 years. But if you buy a new device today, you're screwed.
So I really hope Broadcom will get the clue some day... .
Hey, and you don't even have to release the firmware sources; just the driver sources! We already worked that out for you, Broadcom. Aren't we nice guys? :P
Lesson for Broadcom
Posted Jan 14, 2009 20:56 UTC (Wed) by man_ls (guest, #15091) [Link]
> If you don't open the code for your driver, somebody will reverse engineer [...]Actually, it's not as GP said just "somebody". As your message attests it's a few good individuals ready to spend their time for the benefit of others. We cannot thank you enough. Keep it up!
Mixed feelings
Posted Jan 10, 2009 0:31 UTC (Sat) by pr1268 (subscriber, #24648) [Link]
I dunno... I have mixed feelings about all the successes that Francesco's team has had (and the open-source community in general) with respect to Broadcom adapter support. As more stable and versatile b43 drivers and firmware are released, the more Broadcom will likely be less willing to lend any support to Linux.
Why should Broadcom bother giving the Linux community driver code, specs, or other documentation, if the community will just go figure it out on its own?
I don't mean to dismiss or impugn the hard work the firmware (and driver) development team has had with Linux support; in fact, I'm happy to hear this news. My reservations are due to how Broadcom will react to this.
I remember reading on Broadcom's web site a few years ago where they summarily dismissed any notion of providing Linux drivers and even encouraged Linux users to run NDISWrapper and the Windows driver!
Mixed feelings
Posted Jan 10, 2009 1:54 UTC (Sat) by nowster (subscriber, #67) [Link]
Why should Broadcom bother giving the Linux community driver code, specs, or other documentation, if the community will just go figure it out on its own?
Control. It's possible we might eventually do a better job of it than they did.
Mixed feelings
Posted Jan 10, 2009 10:57 UTC (Sat) by mb (subscriber, #50428) [Link]
I think this is hardly possible.
Yeah, we do better for one device or two, but we do a _lot_ worse for 200 other types of devices. And this is not going to change without broadcom releasing some PHY code.
Hardware manufacturers are not to be trusted with drivers or firmware
Posted Jan 13, 2009 14:08 UTC (Tue) by prl (guest, #44893) [Link]
If the hw manufacturers genuinely open up specs, the result is usually open source that works better than what they can provide. There are many reasons why hw makers do not want to do so (the LinuxBIOS guys much experience here) - not the least being that they can disguise bugs and security holes. Also, hw vendors (particularly their marketing people) are obsessed with differentiation and Unique Selling Points - and most hardware is actually just like any other really, far more than they want to admit.
Remember that the motivation of hw vendors is to sell you their kit, not to make it work well - it only has to work well enough that you buy it, whether directly or via a system integrator. Open source developers and users want to make it work *well*.
Hardware manufacturers are not to be trusted with drivers or firmware
Posted Jan 13, 2009 15:34 UTC (Tue) by mb (subscriber, #50428) [Link]
But I was talking about reverse engineered stuff. In my experience, with the reverse engineered stuff you can hardly get better than the binary stuff it was based on. You can only get as good as the reverse engineered stuff and add a few more bugs. So you end up worse.
The problem with reverse engineered stuff is, that you don't understand what lots of the code actually does. So it's very hard to spot bugs that were in the binary blob and fix them in your open code.
Of course, there are always a few exceptions to this rule. For example some BCM4311 flavours, which work better with b43 than with the native windows driver.
Mixed feelings
Posted Jan 10, 2009 2:29 UTC (Sat) by Ze (guest, #54182) [Link]
>>Why should Broadcom bother giving the Linux community driver code, specs, or other documentation, if the community will just go figure it out on its own?
It's in Broadcom's interest to open up to the community so they get better linux support for their hardware. Broadcom's hardware is used by quite a lot of embedded devices , Broadcom supplies drivers to these people but if the open source driver is already good then Broadcom can reduce it's support costs for OEM's by pushing the development out to community. When the open source support wasn't good then it was a more risky decision for them since they'd have to support their internal as well till the open source version got up to scratch and they still had the possibility of them keeping their secrets. A good reverse engineered open source solution removes both these impediments.
Mixed feelings
Posted Jan 13, 2009 23:31 UTC (Tue) by mlankhorst (subscriber, #52260) [Link]
came out?
They only had binary drivers that sucked ass. Eventually it was reverse engineered (forcedeth
and nvidia sound driver, amonst others), and the drivers were so much better than what nvidia
provided, that they saw the light and contributed to the open source drivers instead :)