Extracting firmware from Broadcom STA driver
Hi. Is it possible to modify b43-fwcutter to extract firmware from the Broadcom's STA driver? http://www.broadcom.com/support/802.11/linux_sta.php I'm asking about that because Canonical is distributing this driver as part of the Ubuntu CDs, so it would be possible to have a working b43 driver without having to download the firmware from the internet (the paradox of requiring to have an internet connection to install a network driver). http://packages.ubuntu.com/source/karmic/bcmwl http://packages.ubuntu.com/karmic/bcmwl-kernel-source Did anyone try to use the firmware from this driver in the b43 driver? If not, would anyone be willing to try? As far as I understand, the License of this driver allows distribution in unmodified form, so the package manager of any linux distro could run b43-fwcutter on the STA driver and extract the firmware for use in the b43 driver. What do you think about it? Would that make sense? Or are there any legal or technical obstacles that would block it? Does this driver differ that much from the one that is used currently to extract the firmware? http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2 Regards -- ## Przemysław Kulczycki Azrael Nightwalker ## # jabber: azrael[na]jabster.pl | tlen: azrael29a # ### www: http://reksio.ftj.agh.edu.pl/~azrael/ ### ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Rewrite DMA Tx status handling sanity checks
On 11/22/2009 11:52 AM, Michael Buesch wrote: On Thursday 19 November 2009 22:24:29 Michael Buesch wrote: This rewrites the error handling policies in the TX status handler. It tries to be error-tolerant as in try hard to not crash the machine. It won't recover from errors (that are bugs in the firmware or driver), because that's impossible. However, it will return a more or less useful error message and bail out. It also tries hard to use rate-limited messages to not flood the syslog in case of a failure. Signed-off-by: Michael Buesch m...@bu3sch.de So did somebody try this with opensource firmware, yet? I'm testing now. So far, it has survived about 18 hours running tcpperf in one console, and a flood ping in another. It looks really good, but I want at least 24 hours before committing. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Rewrite DMA Tx status handling sanity checks
On Sunday 22 November 2009 19:11:52 Larry Finger wrote: On 11/22/2009 11:52 AM, Michael Buesch wrote: On Thursday 19 November 2009 22:24:29 Michael Buesch wrote: This rewrites the error handling policies in the TX status handler. It tries to be error-tolerant as in try hard to not crash the machine. It won't recover from errors (that are bugs in the firmware or driver), because that's impossible. However, it will return a more or less useful error message and bail out. It also tries hard to use rate-limited messages to not flood the syslog in case of a failure. Signed-off-by: Michael Buesch m...@bu3sch.de So did somebody try this with opensource firmware, yet? I'm testing now. So far, it has survived about 18 hours running tcpperf in one console, and a flood ping in another. Cool. Thanks for testing. I'd have expected it to blow up, though. It's a little bit strange, because there still are reports of blowing up opensource firmware. This patch should produce better error messages in that case (it will not fix the blown firmware). It looks really good, but I want at least 24 hours before committing. Well, no. Just commit it, please. If this breaks, the _firmware_ has to be fixed. Not the patch. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312
On Sat, 21 Nov 2009 00:15:12 + Chris Vine ch...@cvine.freeserve.co.uk wrote: WARM BOOT FROM KERNEL WITH WL MODULE INSTALLED The patched kernel makes no change on a warm boot in the sense that if I warm boot after initialising the wireless device with the wl module then the b43 module appears to work correctly, both with and without the patch applied. On the same stress test as mentioned above, I have not been able to induce the DMA errors nor kernel warnings. It resolutely refuses to do anything except work correctly. This is just to say that I have carried out further stress tests today after warm booting to an unpatched linux-2.6.32-rc8 kernel with the b43 driver (on the assumption that unpatched is the least favourable case for the driver). This is a warm reboot from a 2.6.31.6 kernel which had the wl driver installed. I have created an extended period of high speed traffic on my wireless lan and I cannot induce any errors at all with the b43 driver on a warm reboot. This makes me wonder whether the patch is just (partially) masking the problem rather than actually dealing with it. Chris PS The wl driver was compiled from hybrid-portsrc-x86_32-v5.10.91.9.3.tar.gz available at http://www.broadcom.com/support/802.11/linux_sta.php . (Note for anyone want to try this with a warm boot from 2.6.32, that this driver will not compile with 2.6.32 without patching the headers of one of the blob glue files as one of them fails to include linux/sched.h.) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Fatal DMA error problem with netbook and BCM4312
On 11/22/2009 01:03 PM, Chris Vine wrote: On Sat, 21 Nov 2009 00:15:12 + Chris Vine ch...@cvine.freeserve.co.uk wrote: WARM BOOT FROM KERNEL WITH WL MODULE INSTALLED The patched kernel makes no change on a warm boot in the sense that if I warm boot after initialising the wireless device with the wl module then the b43 module appears to work correctly, both with and without the patch applied. On the same stress test as mentioned above, I have not been able to induce the DMA errors nor kernel warnings. It resolutely refuses to do anything except work correctly. This is just to say that I have carried out further stress tests today after warm booting to an unpatched linux-2.6.32-rc8 kernel with the b43 driver (on the assumption that unpatched is the least favourable case for the driver). This is a warm reboot from a 2.6.31.6 kernel which had the wl driver installed. I have created an extended period of high speed traffic on my wireless lan and I cannot induce any errors at all with the b43 driver on a warm reboot. This makes me wonder whether the patch is just (partially) masking the problem rather than actually dealing with it. We know that the wl driver does something to the interface that persists across a warm boot - we just do not know what. It does not appear to be done in any of the MMIO traffic - at least I have not seen it in the mmio-trace output. If anyone has a KVM setup using PCI passthrough, it is possible to trace PCI configuration traffic? Have you tried running your system with the patch entitled [PATCH] b43: Rewrite DMA Tx status handling sanity checks? It cleared up some of the problems that I was seeing with the open-source firmware. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Rewrite DMA Tx status handling sanity checks
On 11/19/2009 03:24 PM, Michael Buesch wrote: This rewrites the error handling policies in the TX status handler. It tries to be error-tolerant as in try hard to not crash the machine. It won't recover from errors (that are bugs in the firmware or driver), because that's impossible. However, it will return a more or less useful error message and bail out. It also tries hard to use rate-limited messages to not flood the syslog in case of a failure. Signed-off-by: Michael Buesch m...@bu3sch.de --- Tested and ACKed by Larry Finger. Not only does this improve the error handling for b43, but it also appears to fix the skb == NULL error that I experienced with the open-source firmware. John - please push this into wireless-testing. It should also go to 2.6.32, but it is likely too large for the current stage. At least Cc it to stable. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
