On Sat, Jan 13, 2007 at 06:49:50AM -0500, Gene Heskett wrote: > On Saturday 13 January 2007 06:20, Martin Langer wrote: > >On Sat, Jan 13, 2007 at 02:41:06AM -0500, Gene Heskett wrote: > >> On Saturday 13 January 2007 01:47, Larry Finger wrote: > >> >Gene Heskett wrote: > >> >> The following is a message I'd posted to the fedora list earlier, > >> >> with few replies. > >> >> > >> >> On Wednesday 10 January 2007 22:00, David Hollis wrote: > >> >>> On Wed, 2007-01-10 at 19:55 -0500, Gene Heskett wrote: > >> >>>> On Wednesday 10 January 2007 18:13, David Hollis wrote: > >> >>>>> On Wed, 2007-01-10 at 16:48 -0500, Gene Heskett wrote: > >> >> > >> >> Jan 10 16:04:21 diablo kernel: bcm43xx: Microcode rev 0x13f, pl > >> >> 0x66 (2005-10-15 22:46:19) > >> >> Jan 10 16:04:21 diablo kernel: bcm43xx: Firmware: no support for > >> >> microcode rev > 0x128 > > > >Your bcm43xx driver wants to have an old v3 firmware. And if you feed > >it with newer v4 firmware you will get such a reaction. > > So in this respect, ndiswrapper is ahead of bcm43xx then as it had no > problem like this. I have it connecting now with ndiswrapper loaded, but > while ifconfig says the interface is up, apparently routes aren't being > properly set to that interface. And I was too tired to investigate > further, still am in fact. > > Could the low tx power Larry alluded to also be a bcm43xx problem?
Yep, a problem with bcm4318 chips. > >> That's a bit confusing since the chip, from the way I'm reading that > >> message, is revision 13f, and in comparing md5sums, what I have is > >> either a miss-match from that chart (its late, the url escapes me > >> ATM), the only matching md5sum is from a microcode "11" in that chart, > >> but the length of the file is wrong by 200 bytes or so. Those you see > >> above were extracted > >> > >> >from the installed and working flawlessly (much to my chagrin) > >> > Windows XP > >> > >> that came on that lappy and which I haven't recovered the disk space I > >> left it. (yet) > > > >The revision numbers (0x13f, 0x127) are not any chip revisions. These > >are microcode revisions and they are defined in the firmware. > > > >The md5sums which do not match was a bug in the old 004 version of > >fwcutter. > > I see. > > >The extraction parameters for some v4 bcmwl5.sys driver files > >(IIRC, it was 4.10.40.0 and 4.10.40.1) were wrong. But this was fixed in > >fwcutter release 005. > > The rpms apparently do not maintain that fine a grain to the version > numbers, all I get for the query --version is 004 If we say "v4" we mean the numbering scheme Broadcom uses "4.x.x.x". And OTOH we use 00x for our fwcutter version numbering. Don't compare them. They have nothing in common. Fwcutter versions 005 and 006 are the ones whith the fix inside. If you run a "bcm43xx-fwcutter -l" you can see the broadcom versions 3.x.x.x and 4.x.x.x which can be used for firmware extraction. Martin _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
