Re: initial value extraction
On Thu, 2007-03-29 at 21:06 +0200, Martin Langer wrote: r13 is new and wasn't available during the good old v3 era. True. Was r11 even there? But my version 3 driver contains: r2-b(g?) r2-b-bs (g?) r2-a r2-a-bs r2 images are for r4 hardware, too. It's just a different name for the same file. V4 does no longer contain r2 stuff. So I think they simply renamed the r2 images. Nothing else. And r2 was a B-only revision, so they used the label b here. But r4 G-hardware will use r2-b initvals in the v3 world, too. So you can rename it to r4-g-* which is the v4 name. Ah ok. I was confused then. r5-g r5-g-bs r5-ag-a r5-ag-g r5-ag-a-bs r5-ag-g-bs Stop. Now fwcutter reads 6 images with length 0 here. Let's call them r9 images. An old version of fwcutter will create those files with length 0. Oh, I thought it just skipped over there? I guess I didn't understand the fwcutter code well enough. And other drivers will probably contain other things... I don't see how this can possibly work properly with the simple numbering scheme fwcutter gives it right now. The numbering scheme is historical from a non-reverse-engineering view. It wasn't designed... Right. A cursory look over fwcutter seemed to indicate that the numbers were assigned linearly which would be wrong I think. Do you have a concrete problem with a so called unverified fw release? No, but I was looking at N stuff and was totally confused by the numbering thing. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Fri, Mar 30, 2007 at 12:45:41PM +0200, Johannes Berg wrote: On Thu, 2007-03-29 at 21:06 +0200, Martin Langer wrote: r13 is new and wasn't available during the good old v3 era. True. Was r11 even there? r11 is only available from 3.130.x.x and 3.131.x.x. All other v3 drivers don't have it. It's funny that 3.140 comes with older firmware than 3.130 and doesn't contain r11 firmware. I still don't understand their versioning system. It's really strange. And other drivers will probably contain other things... I don't see how this can possibly work properly with the simple numbering scheme fwcutter gives it right now. The numbering scheme is historical from a non-reverse-engineering view. It wasn't designed... Right. A cursory look over fwcutter seemed to indicate that the numbers were assigned linearly which would be wrong I think. The first supported driver used linear numbering, but later ones were arranged in different orders and i introdcued the table ivmap[] (see fwcutter.h) to choose the right number. Look at the comment there. The numbering is probably the same order you are using: /* core rev 0x2, 0x4 initval numbers: 1, 2, 3, 4 */ /* core rev 0x5 initval numbers: 5, 6, 7, 8, 9, 10 */ /* core rev 0x9 initval numbers: 11, 12, 13, 14, 15, 16 */ /* core rev 0xb initval numbers: 17, 18 */ /* core rev 0xd initval numbers: 19, 20 */ There are initvals 21..25 missing in the table, but fwcutter is already miles ahead ;) and bcm43xx still doesn't support upload on core revisions =11. Well, bcm43xx do an upload but choosing wrong files (r5 files instead of r11). --- If I'll find some time I'll create a patch. Martin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Fri, 2007-03-30 at 18:50 +0200, Martin Langer wrote: There are initvals 21..25 missing in the table, but fwcutter is already miles ahead ;) and bcm43xx still doesn't support upload on core revisions =11. Well, bcm43xx do an upload but choosing wrong files (r5 files instead of r11). --- If I'll find some time I'll create a patch. I think the whole upload will have to be rewritten, also some rev = 9 cores use rev = 5 firmware but can do some fixups since they have larger FIFO sizes (usually the initial values program the FIFO sizes) I should clean up and post my IV disassembler... johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Friday 30 March 2007 21:00, Johannes Berg wrote: On Fri, 2007-03-30 at 18:50 +0200, Martin Langer wrote: There are initvals 21..25 missing in the table, but fwcutter is already miles ahead ;) and bcm43xx still doesn't support upload on core revisions =11. Well, bcm43xx do an upload but choosing wrong files (r5 files instead of r11). --- If I'll find some time I'll create a patch. I think the whole upload will have to be rewritten, also some rev = 9 cores use rev = 5 firmware but can do some fixups since they have larger FIFO sizes (usually the initial values program the FIFO sizes) I should clean up and post my IV disassembler... Ok, what's actually done in the initvals _exactly_? Does someone have a complete and exact summary? All I know is that it's stuff dependent on the loaded microcode and the running core revision. Btw, I also added some mechanism to define and generate initvals to bcm43xx-asm. I think the initvals are useful and we want them in future, too. Even with possible free microcode. Any comments on this implementation are desired, too. Currently there's mechanism to define several sets of initvals (several sets for, for example, several different core revisions) in the microcode assembly file. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Fri, 2007-03-30 at 23:19 +0200, Michael Buesch wrote: Ok, what's actually done in the initvals _exactly_? Does someone have a complete and exact summary? All I know is that it's stuff dependent on the loaded microcode and the running core revision. Well. Saying it exactly would require a few pages worth of email ;) Basically all the initial values do is hit registers and set various things. For example, they'll set the RXE copy length register and the RXE copy offset register. SHM core revision, then they program the FIFO sizes (also up on the registers spec page). A few other FIFO parameters are programmed, TXE template masks set... The initial values also program the SHM layout, i.e. that key offset pointer, a whole bunch of SHM values are set for the microcode (even some that my disassembler doesn't handle yet meaning they might not even be used). Finally, it sets all the microcode registers to some pre-defined values (some of the registers are assigned special meaning by convention, see http://bcm-v4.sipsolutions.net/802.11/ObjectMemory Btw, I also added some mechanism to define and generate initvals to bcm43xx-asm. I think the initvals are useful and we want them in future, too. Even with possible free microcode. Yeah. Any comments on this implementation are desired, too. Seems sane to me. a reg primitive would be good too, and I don't think PHY or radio registers are required (not that they hurt). Currently there's mechanism to define several sets of initvals (several sets for, for example, several different core revisions) in the microcode assembly file. :) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Fri, 2007-03-30 at 23:26 +0200, Johannes Berg wrote: Seems sane to me. a reg primitive would be good too, and I don't think PHY or radio registers are required (not that they hurt). Oh, of course the shm primitives allow that. How about getting rid of the current shm primitives again and simply using mem offset, 16-bit value reg number, 16-bit value I don't see any point in programming the other object memories from the initial values, who'd want an address in the rcmta by default? :) johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: initial value extraction
On Friday 30 March 2007 23:36, Johannes Berg wrote: On Fri, 2007-03-30 at 23:26 +0200, Johannes Berg wrote: Seems sane to me. a reg primitive would be good too, and I don't think PHY or radio registers are required (not that they hurt). Oh, of course the shm primitives allow that. How about getting rid of the current shm primitives again and simply using mem offset, 16-bit value reg number, 16-bit value I don't see any point in programming the other object memories from the initial values, who'd want an address in the rcmta by default? :) Hm, by reg you mean that object memory where the ucode registers are located? Sounds sane to only allow access to SHM-shared and reg. Currently, you have access to all object memory (must specify the routing explicitely). I'll redesign that. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: dell wireless 1390 802.11 b/g Mini PCI support?
Since those changes are in the fedora-netdev repo, I downloaded that kernel* and performance jumped to over 7Mbps to outside testing places. Wow! Nice job guys! Thanks for the advice, Larry, and thanks for the hard work from the development and spec teams! Ehud *ok, it wasn't quite that simple because I have an Nvidia video card. First I downloaded kernel 2.6.20-1.2933.4.4.netdev.8.fc6, which replaced my 2.6.20-1.2933.fc6 (from fedora-updates repo). No more usable video because of the Nvidia kernel module, but I could verify that bcm43xx worked like a charm. Downloaded the kernel source RPM. Changed the kernel ID from -prep to -1.2933.fc6, built, installed, and now everything works like a charm... the bcm4311 card is running like a rocket... my Nvidia proprietary kernel module binary is loading... and life is good. In short, again, THANKS! I only mention the story so that other people tempted to just download the kernel will consider whether they too have to put up with vendors who are so shortsighted as to release binary-only modules requiring those of us who want to use their product (or have no choice, depending on circumstance) with the latest and greatest kernel... Larry Finger wrote: ... Use the very latest set of patches. The stuff that is coming with 2.6.21 changed my interface from working best at 1 Mbs to having the best throughput at 36 Mbs. It doesn't do as well as the Windows driver (ndiswrapper), but it isn't too far from it. My downlink from Time Warner is rated at Mbs, but I have not yet found an external site that can saturate it. I get almost as good a throughput as my wired interface on a 100 Mps link. All of the changes that are in 2.6.21 can be found at the ftp site in the previous messages. Larry smime.p7s Description: S/MIME Cryptographic Signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: dell wireless 1390 802.11 b/g Mini PCI support?
Ehud Gavron wrote: Since those changes are in the fedora-netdev repo, I downloaded that kernel* and performance jumped to over 7Mbps to outside testing places. Wow! Nice job guys! Thanks for the advice, Larry, and thanks for the hard work from the development and spec teams! Ehud *ok, it wasn't quite that simple because I have an Nvidia video card. First I downloaded kernel 2.6.20-1.2933.4.4.netdev.8.fc6, which replaced my 2.6.20-1.2933.fc6 (from fedora-updates repo). No more usable video because of the Nvidia kernel module, but I could verify that bcm43xx worked like a charm. Downloaded the kernel source RPM. Changed the kernel ID from -prep to -1.2933.fc6, built, installed, and now everything works like a charm... the bcm4311 card is running like a rocket... my Nvidia proprietary kernel module binary is loading... and life is good. In short, again, THANKS! I only mention the story so that other people tempted to just download the kernel will consider whether they too have to put up with vendors who are so shortsighted as to release binary-only modules requiring those of us who want to use their product (or have no choice, depending on circumstance) with the latest and greatest kernel... I'm glad that someone else is getting the same kind of performance that I am. I wondered if I had forgotten to include something in the code. I too have an Nvidia graphics card, but I don't want to taint my kernel. That would hamper my reporting of kernel bugs. I also have no need for 3-D acceleration; therefore, I use the 2-D accelerator in X. It gives satisfactory performance; however, I did need to disable the hardware-mouse option as it prevented my laptop from suspending. Thank you for the kind words. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
2050 radio init fix!!
Just so everyone is aware of how well development is coming along here is some proof. Larry you have done an awsome job bring the softmac up to a very usuable standard in todays modern home network!! Wireless interface testing using Iperf == Testing 802.11b/g bit rates Original Bit Rate of 36 Mbs will be restored Rate set to 5.5 Mbs with iwconfig Transmit rate: 3.38 3.32 3.49 3.38 3.36 Mbits/sec, Max: 3.49, Min: 3.32, Average: 3.39, Sigma: 0.06 Receive rate: 9.98 9.88 9.95 9.85 9.94 Mbits/sec, Max: 9.98, Min: 9.85, Average: 9.92, Sigma: 0.05 Rate set to 6 Mbs with iwconfig Transmit rate: 3.86 3.90 3.93 3.95 3.87 Mbits/sec, Max: 3.95, Min: 3.86, Average: 3.90, Sigma: 0.03 Receive rate: 11.5 11.8 11.7 11.8 11.8 Mbits/sec, Max: 11.8, Min: 11.5, Average: 11.7, Sigma: 0.1 Rate set to 9 Mbs with iwconfig Transmit rate: 5.15 5.05 5.12 5.14 5.11 Mbits/sec, Max: 5.15, Min: 5.05, Average: 5.11, Sigma: 0.03 Receive rate: 11.8 12.1 12.1 11.9 12.1 Mbits/sec, Max: 12.1, Min: 11.8, Average: 12.0, Sigma: 0.1 Rate set to 11 Mbs with iwconfig Transmit rate: 5.20 5.26 5.18 5.19 5.16 Mbits/sec, Max: 5.26, Min: 5.16, Average: 5.20, Sigma: 0.03 Receive rate: 9.96 10.3 10.3 10.2 10.3 Mbits/sec, Max: 10.30, Min: 9.96, Average: 10.21, Sigma: 0.13 Rate set to 18 Mbs with iwconfig Transmit rate: 7.51 7.62 7.59 7.40 7.60 Mbits/sec, Max: 7.62, Min: 7.40, Average: 7.54, Sigma: 0.08 Receive rate: 12.6 12.5 11.0 12.5 12.6 Mbits/sec, Max: 12.6, Min: 11.0, Average: 12.2, Sigma: 0.6 Rate set to 24 Mbs with iwconfig Transmit rate: 8.49 8.62 8.70 8.23 8.32 Mbits/sec, Max: 8.70, Min: 8.23, Average: 8.47, Sigma: 0.18 Receive rate: 12.4 12.6 12.6 11.6 8.98 Mbits/sec, Max: 12.6, Min: 9.0, Average: 11.6, Sigma: 1.4 Rate set to 36 Mbs with iwconfig Transmit rate: 8.97 9.83 10.3 10.4 10.3 Mbits/sec, Max: 10.40, Min: 8.97, Average: 9.96, Sigma: 0.53 Receive rate: 12.5 11.6 10.9 10.5 9.59 Mbits/sec, Max: 12.5, Min: 9.6, Average: 11.0, Sigma: 1.0 Rate set to 48 Mbs with iwconfig Transmit rate: 10.9 10.5 10.5 9.75 10.9 Mbits/sec, Max: 10.9, Min: 9.8, Average: 10.5, Sigma: 0.4 Receive rate: 11.3 11.3 11.7 7.97 8.02 Mbits/sec, Max: 11.7, Min: 8.0, Average: 10.1, Sigma: 1.7 Rate set to 54 Mbs with iwconfig Transmit rate: 8.43 10.0 9.03 11.6 11.5 Mbits/sec, Max: 11.60, Min: 8.43, Average: 10.11, Sigma: 1.28 Receive rate: 9.56 9.14 12.7 12.4 11.6 Mbits/sec, Max: 12.70, Min: 9.14, Average: 11.08, Sigma: 1.46 Bit Rate reset to original value Enojy the results and keep moving forward. 03:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) Jory ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Patches for bcm43xx-softmac
On Thu, 29 Mar 2007, Larry Finger wrote: Also on the FTP site are two Perl scripts for testing. One of them (perf_test.pl) uses an Iperf server somewhere on your LAN. The other (file_test.pl) works with an NFS server on your LAN to measure transfer rates. Here is somet testing from me on my BCM4311 with a 2050 radio, the laptop was about 8 feet away from the AP. Rate set to 5.5 Mbs with iwconfig Transmit rate: 18.4 18.5 18.4 18.5 18.5 Mbits/sec, Max: 18.5, Min: 18.4, Average: 18.5, Sigma: 0.0 Receive rate: 18.6 18.5 18.5 18.5 18.5 Mbits/sec, Max: 18.6, Min: 18.5, Average: 18.5, Sigma: 0.0 Rate set to 6 Mbs with iwconfig Transmit rate: 16.5 18.2 18.4 18.4 13.8 Mbits/sec, Max: 18.4, Min: 13.8, Average: 17.1, Sigma: 1.8 Receive rate: 18.3 18.3 18.4 17.5 14.9 Mbits/sec, Max: 18.4, Min: 14.9, Average: 17.5, Sigma: 1.3 Rate set to 9 Mbs with iwconfig Transmit rate: 14.6 13.2 14.8 15.2 16.6 Mbits/sec, Max: 16.6, Min: 13.2, Average: 14.9, Sigma: 1.1 Receive rate: 13.9 15.0 16.0 16.2 16.6 Mbits/sec, Max: 16.6, Min: 13.9, Average: 15.5, Sigma: 1.0 Rate set to 11 Mbs with iwconfig Transmit rate: 16.3 14.3 11.3 10.7 11.2 Mbits/sec, Max: 16.3, Min: 10.7, Average: 12.8, Sigma: 2.2 Receive rate: 15.1 15.5 9.76 11.6 13.5 Mbits/sec, Max: 15.5, Min: 9.8, Average: 13.1, Sigma: 2.2 Rate set to 18 Mbs with iwconfig Transmit rate: 16.2 18.5 18.5 18.3 18.1 Mbits/sec, Max: 18.5, Min: 16.2, Average: 17.9, Sigma: 0.9 Receive rate: 17.1 18.4 18.1 18.2 17.9 Mbits/sec, Max: 18.4, Min: 17.1, Average: 17.9, Sigma: 0.4 Rate set to 24 Mbs with iwconfig Transmit rate: 18.3 17.9 17.2 18.2 18.5 Mbits/sec, Max: 18.5, Min: 17.2, Average: 18.0, Sigma: 0.5 Receive rate: 18.2 17.3 17.3 18.5 18.5 Mbits/sec, Max: 18.5, Min: 17.3, Average: 18.0, Sigma: 0.5 Rate set to 36 Mbs with iwconfig Transmit rate: 18.6 18.6 18.5 18.3 16.9 Mbits/sec, Max: 18.6, Min: 16.9, Average: 18.2, Sigma: 0.6 Receive rate: 18.7 18.4 18.4 16.8 17.2 Mbits/sec, Max: 18.7, Min: 16.8, Average: 17.9, Sigma: 0.8 Rate set to 48 Mbs with iwconfig Transmit rate: 15.9 17.0 15.8 18.5 17.9 Mbits/sec, Max: 18.5, Min: 15.8, Average: 17.0, Sigma: 1.1 Receive rate: 18.0 18.3 18.2 18.4 18.5 Mbits/sec, Max: 18.5, Min: 18.0, Average: 18.3, Sigma: 0.2 To put this in perspective here is what I got from the same setup using the ndiswrapper and the windows driver: Rate set to 5.5 Mbs with iwconfig Transmit rate: 4.23 4.19 4.27 4.26 4.29 Mbits/sec, Max: 4.29, Min: 4.19, Average: 4.25, Sigma: 0.03 Receive rate: 13.3 13.0 12.7 13.2 13.2 Mbits/sec, Max: 13.3, Min: 12.7, Average: 13.1, Sigma: 0.2 Rate set to 6 Mbs with iwconfig Transmit rate: 4.51 4.43 4.59 4.61 4.45 Mbits/sec, Max: 4.61, Min: 4.43, Average: 4.52, Sigma: 0.07 Receive rate: 16.5 16.0 16.3 15.2 16.4 Mbits/sec, Max: 16.5, Min: 15.2, Average: 16.1, Sigma: 0.5 Rate set to 9 Mbs with iwconfig Transmit rate: 6.39 6.11 6.36 6.42 6.36 Mbits/sec, Max: 6.42, Min: 6.11, Average: 6.33, Sigma: 0.11 Receive rate: 16.2 16.9 16.8 16.9 16.5 Mbits/sec, Max: 16.9, Min: 16.2, Average: 16.7, Sigma: 0.3 Rate set to 11 Mbs with iwconfig Transmit rate: 6.74 6.86 6.82 6.74 6.85 Mbits/sec, Max: 6.86, Min: 6.74, Average: 6.80, Sigma: 0.05 Receive rate: 14.0 14.0 14.0 13.9 14.0 Mbits/sec, Max: 14.0, Min: 13.9, Average: 14.0, Sigma: 0.0 Rate set to 18 Mbs with iwconfig Transmit rate: 10.8 10.9 10.8 10.8 10.8 Mbits/sec, Max: 10.9, Min: 10.8, Average: 10.8, Sigma: 0.0 Receive rate: 17.4 17.4 17.9 17.8 17.7 Mbits/sec, Max: 17.9, Min: 17.4, Average: 17.6, Sigma: 0.2 Rate set to 24 Mbs with iwconfig Transmit rate: 12.9 13.0 13.2 13.0 12.9 Mbits/sec, Max: 13.2, Min: 12.9, Average: 13.0, Sigma: 0.1 Receive rate: 17.9 17.9 18.0 18.1 17.8 Mbits/sec, Max: 18.1, Min: 17.8, Average: 17.9, Sigma: 0.1 Rate set to 36 Mbs with iwconfig Transmit rate: 16.3 16.1 15.9 16.0 16.1 Mbits/sec, Max: 16.3, Min: 15.9, Average: 16.1, Sigma: 0.1 Receive rate: 18.3 17.3 17.5 18.1 18.1 Mbits/sec, Max: 18.3, Min: 17.3, Average: 17.9, Sigma: 0.4 Rate set to 48 Mbs with iwconfig Transmit rate: 17.6 17.6 17.6 17.7 17.3 Mbits/sec, Max: 17.7, Min: 17.3, Average: 17.6, Sigma: 0.1 Receive rate: 18.3 18.2 18.2 18.3 18.4 Mbits/sec, Max: 18.4, Min: 18.2, Average: 18.3, Sigma: 0.1 At this point now I'd feel pretty comfortable getting rid of the ndiswrapper stuff completely now. Thanks for your excellent work on this everybody :) -Aaron ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
