Re: [RFC PATCH] b43: Implement LP-PHY baseband table initialization
> Well, I converted the tables directly from the Wikitext on > bcm-v4.sipsolutions.net using regex search&replace - if you > know a good regex to convert the tables to use multiple values > on each line, please post it. An emacs macro ? Or use any other editor with an macro capability. -- http://www.holgerschurig.de ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Implement fullmac-mode support
> + if (modparam_fullmac) > + goto ssb_disable; > + ... > +ssb_disable: > ssb_device_disable(dev->dev, 0); > ssb_bus_may_powerdown(dev->dev->bus); > } April April! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Problems sniffing custom frames with b43
> Oh wait, I think it's probably not needed to modify the > firmware. It has a knob to pass "bad frames" up to the driver. > It should pass these frames then. Shouldn't the monitor mode then turn on this knob by default? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom driver in Android
> Just found this in the Android's repository and think maybe > this info can be useful for someone in this list: > > http://android.git.kernel.org/?p=platform/system/wlan/broadcom >.git;a=summary .. and it's even GPL. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Thoughts about the b43 RNG
> I was doing some random tests on the b43 hardware RNG. > These are the results. As you're german, you should get a look at the current c't 2/2009. At page 172 it has a in-depth articel about randomness tests. They also have some tools to download, see http://von-und-fuer-lau.de/random-tools.html http://www.heise.de/ct/09/02/links/172.shtml ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 fails to reauthenticate
> From my uneducated point of view it looks like problem in
> driver
Not necessarily. It might be your wpa_supplicant or the AP.
> After some time of successful usage (5-10 minutes) AP sends
> deauthentication with reason code 2, which AFAIU is "Previous
> authentication no longer valid".
The you need to find out why the AP does this in the first place.
> WPA configuration:
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=1
> fast_reauth=1
>
> network={
> scan_ssid=0
> ssid=".."
> proto=WPA
> key_mgmt=WPA-PSK
> pairwise=CCMP TKIP
> group=CCMP TKIP WEP104 WEP40
> psk=""
> }
So, the above entry is strange. If you know the network/AP, you
can do an "iwlist eth1 scan" and fill in pairwise/group
accordingly. Usually they're both identical. As you
have "proto=WPA", you should normally then have pairwise=TKIP,
group=TKIP. CCMP is used with proto=WPA2 (or proto=RSN, which is
the same).
> network={
> ssid="any"
> key_mgmt=NONE
> priority=2
> }
And that's even more strange, an entry for something that
shouldn't exist: an open, unencrypted, unprotected wireless
network ...
Some things that might help you: Try "wpa_cli" and it's "status"
and "level" commands. Make sure that no other external programs,
e.g. Network-Manager, is responsible. Look with "ps faxwww" at
the command line arguments for wpa_supplicant. Then kill it, do
an "ifconfig XXX up" (name of the interface) and start
wpa-supplicant by yourself, but this time without the "-B"
(background) option, but with one or two "-d" (debug options).
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 driver problems
> See, this is what I'm talking about. There's a lot of placebo > involved. There was no change to b43 in the .26-stable kernel. > So it cannot regress between .26.1 and .26.5. So maybe something outside b43 has weird side effects. Maybe Mike tries 26.26.2, 2.6.26.3, 2.6.26.4 as well and tries to identify when the errors start to happen. The list of changes in the stable series is usually so little that this could give a hint. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC/T] b43: to few loop tries in do_dummy_tx
> The b43 and b43-legacy driver are _based_ on these > specifications. There are no other specs available. Can it be the case that the binary windows driver the spec producer analyzed used a different PCI settings? And that therefore the delays/access-patterns in the binary driver work as expected *in their environment*, but that Linux might have programmed the PCI bus/controller differently and that therefore the identical approach fails (sometimes) ??? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx for bcm-4328
> http://bcm43xx.berlios.de/?go=devices
>
> In fact, I would suggest that this is the most common starting
> point for anyone who does not know much about wireless drivers
> and would prefer to avoid asking FAQ's on discussion forums.
I tend to disagree.
First thing: bcm43xx is outdated. The in-kernel b43 driver is
state-if-the-art.
Second thing: when a driver is in-kernel, I'd suggest that the
driver-webpage contents get's transferred to the central place
for all in-kernel-drivers, and that would be
http://wireless.kernel.org.
The main page of bcm43xx (http://bcm43xx.berlios.de/?go=home)
even states both things: "This site won't be updated anymore.
Please check the b43 driver page at linuxwireless.org for
up-to-date information.".
("linuxwireless.org" is an alias to "wireless.kernel.org", the
now canonical web address).
> This page does not list BCM4328 anywhere
That's because the web page you referred to doesn't get updated
anymore. 4328 is mentioned on
http://linuxwireless.org/en/users/Drivers/b43, thought.
As to the "make more accessible to less technical oriented
people" I don't have a good answer. Maybe this is the job of
SuSE, RedHat, Debian, Ubuntu, ... Not sure about that.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Rewrite PHY API for N-PHY/LP-PHY -- good on 4311
> I know, which is one of the reasons I don't use a Debian-based > distro. I want nothing to do with one whose stated goal is to > make it so difficult to change the kernel that the users won't > do it. Huh? I use "make install modules_install" from my kernel source dir (which I usually get via git) and that works fine, as in every distro on earth. Hehe, but I seldom use distro kernels, not even when I used Red Hat or Mandrake in old times :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: after 3 weeks of problems, should I go back to windows?
> I have > worked with all of them over the last three years (must have > thrown away 100 plus live and install cd's). I want Debian > and may have to die before I find my solution but so be it. I'm on Debian (and love it!) and use various kinds of WLAN cards (mostly for tests only) without any problem. However, I don't use the Debian kernels, I use kernels that I get directly from http://www.kernel.org or http://git.kernel.org. However, if you're new to linux and/or have a unsupported 3D card (e.g. nVidia one), than this might be too much hassle to you. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: vendor/product ID's
> Hopefully someone can provide a link for a windows utility > that fits my needs or a GNU source package that can be built > on the majority of *nix based OSes that doesn't have many > obscure external dependancies. GIT exists for Mac OSX, as a google search for "git macosx" quickly reveals. In the linux world, git isn't seen as an "obscure external dependency" :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: suspend vs. b43
> Odd. Resume itself works just fine here, except when b43 is > up. But then again, you might not notice that this is the > problem because by default, nothing gets printed on the resume > console and then it will indeed hang with a black screen. pepper it with printk's and add netconsole ... ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 sysfs interface
Hmm, I found "ip" and it's built in help confusing ... at least two years ago, things might have changed. Since then I'm using "ifconfig" / "route" again ... ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: unsuscribe
> unsuscribe That won't work. And it's not good style to write a message by replying --- except if you actually want to reply. :-) Why don't you try the URL that is pasted at the end of each message? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: rfkill radio button do not work (SOLVED)
> i continue search and found that i forgot enable the > CONFIG_INPUT_POLLDEV option. > Thanks Shouldn't this be done automatically by a proper entry in the Kconfig file? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation "wpa_driver_wext_set_countermeasures" not supported
On Monday 17 December 2007 15:09:32 Robert Allerstorfer wrote: >>> But shouldn't setting/unsetting B43_DEBUG only affect the >>> verbosity level of the kernel messages, but not change any >>> functionality? >> No. > So that means enabling Broadcom 43xx debugging may disable > functionality? You're confused :-) When you turn debugging on, you'll get a variety of additional debug messages into your kernel log. You expected them all to be identical, but they aren't necessarily. For example, the value after cur= is a value that has actually been measured, so don't assume that it stays all the time at exactly the same value. It depends on your (physical) circumstances what get's measured and printed. The "No" was the answer to the last part of your question. "No, it should not change functionality" is a more verbose form. Note that there might be rare situations where turning on debug messages change functionality: in the case of race-conditions. I'll leave the explanation of this to your google skills :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Operation "wpa_driver_wext_set_countermeasures" not supported
> > What is reason 3 for disassociating? > > WLAN_REASON_DEAUTH_LEAVING = 3, > > But I don't know what LEAVING means in this case. If a client decides to roam, it can (not a must, after all the client can be in reception hole) send a de-auth mesage to the old AP. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Microcode reverse engineering
It could also be the case that the opcodes on the website aren't opcodes to a real CPU, but that they are executed by a VM. So they could have used a MIPS, now an ARM cpu, and as long as the VM is implemented in one of those languages, it would be able to execute the uCode. That's just speculation, thought. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
Do you have any logs of the APs, e.g. do they log that somebody tried to associate and failed? Did you try a workaround to put all 3 APs to the same frequency? If you then observe the same problem, you could then use wireshark to capture a log of what happens "in the air". If the APs have different frequencies, then your monitoring WLAN card can't follow the maybe-roaming-card in sync, therefore use temporarily only one frequency. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
mac80211 regression: doesn't associate automatically
I'm on wireless-2.6, branch everything, git commit 7446b6c0e3b18fd2c5f9c406bb20841e6193d058 When I insert a b43 based card, I don't get associated automatically. This happens: $ # Insert the card pccard: CardBus card inserted into slot 0 PCI: Enabling device :03:00.0 ( -> 0002) ACPI: PCI Interrupt :03:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 ssb: SPROM revision 1 detected. ssb: Sonics Silicon Backplane found on PCI device :03:00.0 b43-phy0: Broadcom 4306 WLAN found b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 phy0: Selected rate control algorithm 'simple' $ ifconfig eth1 up b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) b43-phy0 debug: Chip initialized b43-phy0 debug: 30-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 $ iwconfig eth1 essid BLAHMUMPF HW CONFIG: channel=1 freq=2412 phymode=2 HW CONFIG: channel=2 freq=2417 phymode=2 HW CONFIG: channel=3 freq=2422 phymode=2 HW CONFIG: channel=4 freq=2427 phymode=2 HW CONFIG: channel=5 freq=2432 phymode=2 HW CONFIG: channel=6 freq=2437 phymode=2 HW CONFIG: channel=7 freq=2442 phymode=2 HW CONFIG: channel=8 freq=2447 phymode=2 HW CONFIG: channel=9 freq=2452 phymode=2 HW CONFIG: channel=10 freq=2457 phymode=2 HW CONFIG: channel=11 freq=2462 phymode=2 HW CONFIG: channel=1 freq=2412 phymode=2 $ iwconfig eth1 key s:1 b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff $ iwconfig eth1 eth1 IEEE 802.11g ESSID:"BLAHMUMPF" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:3131-3131-31 Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 As you can see, I'm not associated. However, this sequence used to work with non-mac80211 based WLAN drivers. However, I can actually associate if I reverse the essid/key, e.g. first set the key, then the ssid. Note that the same happens if I let Debian manage the card. An excerpt from my /etc/network/interfaces shows: allow-hotplug eth1 iface eth1 inet static address 10.2.1.3 netmask 255.255.255.0 wireless-essid BLAHMUMPF wireless-key1 s:1 (the test above has been made completely manually, without this entry) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Output message at startup if hardware switch for radio is off
> Well... Pressing the rfkill button is the _FIRST_ thing that I > would do, if the device does not work. I'm wondering why > people have a problem with that. On other operating systems > it's the very same. On Windows there is no dmesg. On Windows, the "Wireless Network Connection" wizard displays - No wireless networks were found in range Make sure the wireless switch on your computer is on. To see an updated list, click "Refresh network list". - The Linux äquivalent would be NetworkManager or the KDE tools for this job. That's at least displayed on the WinXP Embedded device that I just created :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: What is the right way to pull the wireless-dev + b43 from the git tree?
wireless-dev has been declared "dead" by John W. Linville, use wireless-2.6. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: minor grips with b43
> Are you using openSUSE 10.2? If so, you need to add the following rule to
> /etc/udev/rules.d/80-sysconfig.rules:
>
> SUBSYSTEM=="ssb", ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe
> $env{MODALIAS}"
Debian/Etch. Thanks for this tip, will try later.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: minor grips with b43
> > When I power-up my device, I only see that ssb has been > > loaded. Not "b43.ko" as well. Is this expected? > > Where were you looking? If "b43.ko" has been loaded? With lsmod: # lsmod Module Size Used by mousedev5800 0 ssb19204 0 usbtouchscreen 3332 0 > In dmesg, you should see something > like: > > ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) > ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) > ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) > ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) > ssb: Sonics Silicon Backplane found on PCI device :01:00.0 > b43-phy0: Broadcom 4311 WLAN found My output here is: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) ssb: Sonics Silicon Backplane found on PCI device :03:00.0 And, because b43.ko doesn't get auto-loaded, I don't have a "b43-phy0"-line. I'm not sure if the following is relevant, but here is the output of "lspci -n": 03:00.0 0280: 14e4:4320 (rev 03) And if I manually "modprobe b43", I get this: b43-phy0: Broadcom 4306 WLAN found b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy0 debug: Radio turned off wmaster0: Selected rate control algorithm 'simple' After "iwconfig eth1 essid X", "iwconfig eth1 key s:X" and "ifconfig eth1 up", I get this: b43-phy0 debug: Adding Interface type 2 b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) b43-phy0 debug: Radio turned on b43-phy0 debug: Radio enabled by hardware b43-phy0 ERROR: bbatt(11) >= size of LO array b43-phy0 debug: Chip initialized b43-phy0 debug: 30-bit DMA initialized b43-phy0 debug: Wireless interface started HW CONFIG: channel=1 freq=2412 phymode=3 b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff But I'm pretty sure this is unrelated to auto-loading b43 :-) > I assume that you meant b43 when you typed b32 Yes. That's why I did "dmesg >a" and "scp" for the texts above :-) > you may also see errors like > b43-phy0 debug: Invalid LO control pair (I: 111, Q: 111) > and > b43-phy0 ERROR: Adjusting Local Oscillator to an uncalibrated control pair: > rfatt=3,no-padmix bbatt=2 Fortunately not in my case. > the bit rate for my BCM4311 was toggling between 18 and 24M. > With the same setup, b43 usually is at either 48 or 54M. > Take that Broadcom!!! I don't care that much for bitrate, I'd rather have a very long range, even when it's only 1 MB/s. My main application is SSH :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
minor grips with b43
I have a 2.6.22.5 kernel where I implanted * ssb * mac80211 * radiotab * b43 from linux-wireless-dev, branch everything, commit 0347a7c86f8406b1058870bb11f0c739dc2b9bf2. I also put the firmware according to http://www.linuxwireless.org/en/users/Drivers/b43 into lib/firmware/b43. When I power-up my device, I only see that ssb has been loaded. Not "b43.ko" as well. Is this expected? # ifup eth1 Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 b32-phy0 ERROR: bbatt(11) >= size of LO array ... Is this error serious? I was able to connect to my AP, despite the error. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: include FCS at end of frames
> b43_wireless_init(struct ssb_ } > > /* fill hw info */ > - hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE; > + hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE | > + IEEE80211_HW_RX_INCLUDES_FCS; > hw->max_signal = 100; You must have a very different tree to wireless-dev, branch everything. According to git blame, since 2007-08-13 the piece of code there looks like this: hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE | IEEE80211_HW_MONITOR_DURING_OPER | IEEE80211_HW_DEVICE_HIDES_WEP | IEEE80211_HW_WEP_INCLUDE_IV; The patch subject in this mailing list was "[RFC 5/10] Port of bcm43xx from softmac to mac80211" ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Update to ssb-sprom README
> > SSB_SPROM=$(find /sys -name ssb_sprom) > > Actually every modern shell can do this. And I cannot see why one is more ugly than the other version :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Update to ssb-sprom README
> > +sudo cat ssb_sprom_copy > $SSB_SPROM > > This won't work as an unprivileged user who won't be able to > open the file for writing. sudo "cat ssb_sprom_copy > $SSB_SPROM" should do the trick. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I will switch to quilt based development
> I see. One thing I didn't like in quilt is that I have to > decide what I'm going to do before actually changing the > sources. All I have to decide beforehand is the name of patch. In stgit this is the same. However, stg is worse, because there I even have to enter a description of what I'm about to do beforehand. *) Sometimes, I just make patches in quilt, then I do "quilt refresh", "quilt pop -a", "cd patches" and modify the patches and series file manually, e.g. by moving one patch from one file into the other. The "cd ..", "quilt push -a" and off I am. That the "database" of quilt is in a known format and I can hack on it with an editor is a plus for me :-) That said: once I'm finished with quilt-things, I'm using stg import to import this into git and use git to send it off to the mailing list. I'm not working with stg on the first place, because quilt is noticably faster than stg. *) in stgit I can do "stg refresh -e" to edit the description afterwards ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm4301: A mac80211 driver using V3 firmware
> 3. If the port of softmac to mac80211 is merged before > Michael's driver, it will be known as bcm43xx with > bcm43xx-mac80211 remaining in wireless-dev. Renaming a driver always creates madness. For example, even now people and projects (e.g. Kismet) refer to "madwifi-ng", but there is no madwifi-ng anymore, because this beast has been renamed to madwifi. If possible, use names that can stay. Peoples grey cells, projects, and webpages don't then suffer from bitrott. > > 4. Once bcm43xx-mac80211 gets merged to mainline, then > Michael's driver should become bcm43xx and my driver gets its > PCI IDs stripped to the 802.11b-only devices and once again > becomes bcm4301. This name change for Michael's driver would > cause some disruption for current users as their firmware > would have the wrong name/version. That might be too much of a > problem. A gread, even more renames :-( ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: can I contribute to the project ?
> http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess "creative Mac-On-Linux hack" ... where is the URL? Obviously this is used to create traces of memory accesses. Where are the traces, so that other people can have a look at them and run them throught their own tools? That page just says "we carefully analysing disassembled code", with what? IDA Pro, objdump? What tools to you have to add annotations, names to functions or jump targets? Where are the perl/python/ruby scripts that you use in correlating memory access traces with your disassembly? Later it says "Translate assembly to C". Which de-compiler are you using? I saw this pages some months ago, but it made me no wiser on how to do this reverse-engeneering :-) Hmm, some weeks ago I saw something about a PCI proxy, that was either for QEMU or for Linux itself. With it, one could, at kernel/emulator level, log any access to a PCI memory address range. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: can I contribute to the project ?
> I would be happy, if you'd join the reverse engineering team. > Currently there's kind of a bottleneck, as our two active > people are busy with other things. Is there some page there they describe the used method and methodology for the reverse-engeneering? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
And what is the AP is not next to you?
I'm more interested in wireless links there the AP is not next to you, e.g. I want to maximize range, not throughput. Is BCM usable in such a scenario or do I have to go with NDISWRAPPER? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Survey of bcm43xx cards
> That "high speed" and "high power" is just a matter of > programming the eeprom differently, only in the case of "high > sensitivity" *may* actually a slightly different chip be > present on the card. For high speed I assumed the same. > "high power" I'm not sure about. For high power I don't think this is the case. The card is visually much thicker (the part that is outside the laptop). However, I opened the case and it looks like that "just" the antenna plates are wider away from the PCB. Maybe there is also some extra chip there to get more antenna gain, I don't know. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Survey of bcm43xx cards
I have three PCCards from Buffalo with the BCM43xx chipset, which I all added to into the registration site. One thing to note it that the debug output of bcm43xx.o puts out exactly the same info between for the "normal" card (the first below) and the high speed version (the second below). I'm also posting the data for the high power card, in case anyone want me to test some patches against this card. BTW: all of those cards have an external antenna socket. I don't have any info right now on how to select this antenna. But I haven't even tried to find this out :-) Buffalo AirStation 54 Mbps CardBus WLI-CB-G54A bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243 bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243 bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243 bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243 bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) 03:00.0 0280: 14e4:4320 (rev 03) Buffalo AirStation 125 High Speed Mode WLI-CB-G54S bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243 bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243 bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243 bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243 bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Buffalo AirStation High Power WLI-CB-G54HP bcm43xx: Chip ID 0x4318, rev 0x2 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243 bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243 bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243 bcm43xx: Detected PHY: Version: 3, Type 2, Revision 7 bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8) 03:00.0 0280: 14e4:4318 (rev 02) Subsystem: 1154:033a ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[no subject]
Buffalo AirStation 54 Mbps CardBus WLI-CB-G54A bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243 bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243 bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243 bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243 bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) 03:00.0 0280: 14e4:4320 (rev 03) Buffalo AirStation 125 High Speed Mode WLI-CB-G54S bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243 bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243 bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243 bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243 bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Buffalo AirStation High Power WLI-CB-G54HP bcm43xx: Chip ID 0x4318, rev 0x2 bcm43xx: Core 0: ID 0x800, rev 0xd, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0x9, vendor 0x4243 bcm43xx: Core 2: ID 0x804, rev 0xc, vendor 0x4243 bcm43xx: Core 3: ID 0x80d, rev 0x7, vendor 0x4243 bcm43xx: Detected PHY: Version: 3, Type 2, Revision 7 bcm43xx: Detected Radio: ID: 8205017f (Manuf: 17f Ver: 2050 Rev: 8) 03:00.0 0280: 14e4:4318 (rev 02) Subsystem: 1154:033a ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Survey of bcm43xx cards
> (upload) [3] in excellent conditions [4]. I know 1.8 MB/s is > above theoretical limit of 11Mbps but it is exactly like that. If you transmit above theretical limit, then you probably don't send at 11 MBit/s, but at a higher 802.11g rate. Don't you guys have real access points (e.g. Cisco or whatever) where the Access Point can say with what data rate you're coming in? ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix for oops on resume
> I use a BCM4318 on PPC. When I first boot, I get: > bcm43xx: It took 16 tries to set IRQ_READY > > Then I suspend-to-RAM, and after wake-up, I get: > bcm43xx: It took 65 tries to set IRQ_READY Maybe the error is somewhere else. AFAIK a PC-Card is handled like a PCI device. Therefore, from pciutils you can use "lspci" to look at the PCI settings and tinker with them using "setpci". Maybe "lspci -vvv" displays different timing information before and after the suspend/resume, e.g. a different latency for the BCM or for another PCI device, which then "steals us" bus time. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
