Gmail Collector wrote:
Not being a reverse engineer, nor any kind of engineer for that matter,
I was wondering if the driver files for the (rev 02) from my Vista would
help in any way? If so, I'd be happy to send them as an attachment.
Gary
No, we've already got a driver that supports
Pavel Roskin wrote:
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:
The spec is telling us to lookup an invalid index in the LO table.
I see. Thanks for your explanation!
I think the way to solve it would be to see how the table is used in the
proprietary driver. Either the data
Pavel Roskin wrote:
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote:
Well, it's not that easy. Current code just doesn't make any sense.
I do not understand how hardware power control works exactly, so I
can't write some detailed message or something.
That's probably a chicken and
Johannes Berg wrote:
On Fri, 2007-08-03 at 16:00 +0200, Michael Buesch wrote:
Does someone have some time to reverse engineer the
table upload functions (DC table, TSSI table and the other one
I don't remember). They are uploaded in the hwpctl setup.
I'm pretty sure there are bugs. If I omit
Mansour wrote:
Great, and regarding the acpi, I have to boot with pci=noacpi. Am I wrong ?
I can't really say anything about this, it's not really related to
bcm43xx though. You might have more luck asking the support
forums/mailing lists for your distro.
-Joe
I have a DV9208NR and I have had no acpi problems. However, I have to
boot with the pci=nommconf in order for the ndiswrapper to drive the
broadcom 4311. I periodically black list the ndiswrapper and enable
the bcm43xx-80211 driver and this past week was the first time I could
get the
John, Thank you. This is the first time I was able to boot to the login
screen with out using noacpi option. I took your advice and used
pci=nommconf instead. And it worked fine. Further more, when I try to
start my wireless connection, it's not complaining any more about
SIOCSIFFLAGS:
Are the txpower adjustment bugs a problem with the specs? Is
there anything I can do?
I'm not sure what causes this, yet. It's either a bug in estimating
the current power or in calculating the new attenuation values.
I'm working on updating the v4 specs for estimating the current
power,
snip lots of good news
The machine that I use to test PCMCIA modules is very slow. For example
recompiling a kernel using
the configuration of an openSUSE distribution kernel takes roughly 36 hours.
To help speed
development and testing, I have that computer export /home with NFS and
Otto Solares wrote:
Hi!
I have seen lot of progress in the bcm43xx driver so I searched
for the BCM4320 support but can't find anything on the homepage
nor this list's archive.
Would like to know what is the status for this chipset? or is
this chipset too different to be supported by
There should be USB support in the bcm43xx-mac80211 driver, but I have no
idea what the status is.
USB devices will never be supported in bcm43xx-softmac, which is near its
end-of-life.
We don't support USB devices at all right now. The only one we've
seen in the wild is the USR5421 which
Johannes Berg [EMAIL PROTECTED]
Joseph Jezak [EMAIL PROTECTED]
We are two members of the reverse engineering team as can be
verified by looking at the specification.
This infighting between two teams trying to support the same chipset
is a complete mockery of the publicness of the original
Theo de Raadt wrote:
Johannes Berg [EMAIL PROTECTED]
Joseph Jezak [EMAIL PROTECTED]
We are two members of the reverse engineering team as can be
verified by looking at the specification.
And how exactly does seeing this public flogging involve you?
Do you feel that Marcus should give up
the output of lspci -nv is:
==
0c:00.0 Class 0280: 14e4:4311 (rev 01)
Subsystem: 1028:0007
Flags: fast devsel, IRQ 177
Memory at ecffc000 (32-bit, non-prefetchable) [disabled] [size=16K]
Michael Buesch wrote:
On Thursday 22 March 2007 22:02, Pavel Roskin wrote:
It will be easy enough to change bcm43xx-sm names to avoid
them.
s/bcm43xx/bcm4301/
or something like that
I'd vote for that name change, yes.
What about bcm43xx-bphy since the 4303 would also be supported by
I'm not sure whether this information is of interest for you, but here
it is: (bcm4310 is not in the the list on the website - is it actually a
4312?)
Yes, the PCI ID database has it incorrectly listed.
-Joe
___
Bcm43xx-dev mailing list
David Woodhouse wrote:
On Fri, 2007-03-02 at 11:30 -0600, Larry Finger wrote:
There was an error in the B5PHY init specifications.
This patch doesn't fix the machine check in bcm43xx_phy_initb5 which
Pavel Roskin and I reported a couple of weeks ago. To get rid of that
crash, I still have
Joe, can you re-check if the specs is correct here?
B5PHY:
5. If this is a G PHY
1.
If the RadioID Radio Version is 2050
1.
OR RadioRegister 0x7A with 0x20
2.
OR RadioRegister 0x51 with 0x4
2.
Write 0 to MMIO offset 0x3E2
Pavel Roskin wrote:
On Thu, 2007-02-22 at 19:14 -0500, Joseph Jezak wrote:
The spec is correct, but there is a special case that is most likely
causing this. Basically, there's a few things that we're calling
If this is a G PHY. We need to separate them out. :p Here, this
code isn't
Well, I don't review the rest until you say to which specs you did the
changes. ;)
http://bcm-specs.sipsolutions.net/B5PHY
Larry was working from the old specs, so when I updated it, I only
updated the old specs. I'll fix the v4 specs soon.
-Joe
dprintk(KERN_INFO PFX Detected PHY: Version: %x, Type %x,
Revision %x\n,
You should change this too, the Version text should read Analog
instead.
-Joe
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
I'll agree to that as long as there is a clear indication of any differences
between V3 and V4 firmware.
That's also part of the problem. With the v4 driver, Broadcom
dropped support for a number of older BPHY devices (4301/4303 and
some 4306 revisions). Do we still want to support those?
The specs are unclear at this point:
Write the value to the offset
Offset in which register type?
PHY Register. I've clarified it in the specs, I think this was said
before, I made it worse when I cleaned it up.
// Initialization
-if (phy-version == 0) {
+if (phy-analog ==
Michael Buesch wrote:
On Friday 09 February 2007 20:05, Joseph Jezak wrote:
I'll agree to that as long as there is a clear indication of any
differences between V3 and V4 firmware.
That's also part of the problem. With the v4 driver, Broadcom
dropped support for a number of older BPHY
This is correct. Why do you think it's a specs bug?
Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
Could this be PHY or radio register 0x3?
Apologies. You are correct that this should be PHY Register 0x3,
not MMIO offset 0x3. I've
Also, I looked at the
http://bcm-specs.sipsolutions.net/RadioRegister#head-6f5fcae4505eb6ec71683a3438346bbcb58f3391
There are many registers offset, that have unknown functionality (i.e. it is
blank).
Is it left blank intentionally or is it really unknown?
We don't know what they do.
Erik Chakravarty wrote:
I take it that this is not a problem known to be associated with the
bcm43xx driver then, which means I will have to do some further testing.
The problem in diagnosing this is that it's difficult to see log output
once the machine's locked - the first thing I notice
1) is the SPEC wrong?
Yeah, the spec was wrong, I checked it against the older MIPS
version and it was mistranslated. Fixed in the specs.
Sorry,
-Joe
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
Bin Zhang wrote:
Hi,
I can't compile the latest wireless-dev:
CC [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.o
In file included from drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:44:
drivers/net/wireless/d80211/bcm43xx/bcm43xx.h: In function 'bcm43xx_priv':
I'm sorry but I'm currently too busy because of university and job. But if
someone outbids you, please wait. We got donations for this, so just ask me
for hardware if you plan to work with it. In case you win the bid, feel
free to ask me for a refund. I guess Joe, Johannes, Martin and Michael
2. After it I've got to do couple times (sometimes just once)
localhost linux # ifconfig wlan0 up
SIOCSIFFLAGS: Protocol error
localhost linux # ifconfig wlan0 up
SIOCSIFFLAGS: Protocol error
localhost linux # ifconfig wlan0 up
SIOCSIFFLAGS: Protocol error
localhost linux # ifconfig wlan0
Jory A. Pratt wrote:
Well after doing a serious upgrade on my line I discovered just how
bad off the bcm4318 truely is. I have a 3Mbp/s line and with bcm4318 I
am lucky if I can utilize a 1/3rd of that. ( i.e =1.0Mbps ) Those who
have this card might want to concider throwing it in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There certainly could be a race condition, but I have no idea how it could be
triggered by the
signal-quality patch. Have you seen the firmware load failure before?
Anyone have any ideas here?
Larry
Well, we were seeing similar things on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This question relates to a BCM4310 PCI-E card with a Rev. 8 PHY that
There are no BCM4310 PCI-E cards. It's a 0x4311 series card with a
PCI ID of 0x4311, 0x4312, or 0x4313.
particularly concerned about the 7 in the statement If 2 = PHY
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Buesch wrote:
On Thursday 07 September 2006 00:43, Michael Buesch wrote:
Hi,
I need to know the exact microcode revision/patchlevel which is the
first one being incompatible with current bcm43xx driver.
I need this, because I want to
Michael Buesch wrote:
On Saturday 26 August 2006 11:19, Jochen Puchalla wrote:
[Samstag, 26. August 2006 10:59] schrieb Michael Buesch (wrote):
On Saturday 26 August 2006 10:34, Jochen Puchalla wrote:
[Donnerstag, 24. August 2006 22:08] schrieb Michael Buesch (wrote):
On Thursday 24 August
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As soon as you get a chance to build a clean system and boot it, please let
me know the results. As
soon as I know that the card works, I'll push the patch.
Once you get an entry in iwconfig, please run the following script and send
me the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shawn wrote:
Hi All,
Had a question about my Linksys WPC54G v4 card. Not sure if this is
supported yet, does anyone know which chipset this card has?
I'm pretty sure it's not a Broadcom card. You would have to look up
the PCI ID to find
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Clifton Watson wrote:
Hi all,
Does bcm43xx set a flag or has a statistic indicating that a packet
has a bad CRC? Thanks.
What exactly are you looking for? There is a bad CRC counter, but
it's not documented yet since stats aren't really
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 3889f79..03a1330 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -130,6 +130,8 @@ #endif /* CONFIG_BCM43XX_DEBUG*/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Basically, the initvals are always arranged in the same order. I do not
think that the 4.x problems are caused by any wrong initvals.
Yeah, you're right. :p Sorry for the trouble. As soon as I get a
chance I'll take a look at what's different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
bcm43xx kind of works here too (on Dell Insprion 2200 with just
plain vanilla 2.6.17.4 kernel) -- except that it is not able to
hold connection for longer time (after couple of minutes it
falls down), and I am not able to up network with it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As far as I can tell, the 4.x firmware isn't all that different,
it's the initvals that are causing the trouble. For instance, in
the wl_apsta.o file with version 4.80.9.1, the initvals and firmware
are laid out like this:
d11b0g0initvals4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Langer wrote:
On Thu, Jul 06, 2006 at 10:25:40AM -0400, Joseph Jezak wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As far as I can tell, the 4.x firmware isn't all that different,
it's the initvals that are causing the trouble
The driver will not work if I used mixed firmware files. If I use a 4.x
microcode and 3.x initvals and a 3.x pcm file, I'll get bcm43xx error
messages and the driver doesn't work.
My conclusion was: The ucode is different.
Another possibility is: This pair of initvals and ucode is
Larry Finger wrote:
In http://bcm-specs.sipsolutions.net/APHYSetup/noise_scale_table in the
table for G PHY Rev = 2, offset 13 has the value 0x1402, whereas
bcm43xx_ilt.c has 0x1400 for the equivalent number. Is this a typo in
the driver or on the website?
Larry
I redid this function for
added a check to the wx handler to see if we're connecting to a
different network than the one already in progress. This scenario was
causing multiple requests on the same network because the network BSSID
was not being updated despite the fact that the ESSID changed.
Signed-off-by: Joseph Jezak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florian Fainelli wrote:
I thought this page was specifying it :
http://bcm-specs.sipsolutions.net/PowerManagementQueue
sorry for my misunderstanding.
That page describes managing the Power Management Status of STAs while
the bcm43xx card is in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jun 3 00:56:29 thirtytwo bcm43xx driver
Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2
Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6
Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243,
enabled
Jun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shawn Q.Z. Tang wrote:
Understand !
So , the firmware has noting to do with the architecture of the host
machine , and i can use it in no matter ARM or x86 system as long as
the other things have been done .
I have cross-compiled the ieee80211
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- if (bcm-chip_rev 5) {
+ if (bcm-core_pci.rev = 5 bcm-core_pci.id !=
BCM43xx_COREID_PCIE) {
sbimconfiglow = bcm43xx_read32(bcm,
BCM43xx_CIR_SBIMCONFIGLOW);
sbimconfiglow = ~
There isn't much the driver folks can do there except maybe allowing for
a PIO only mode.
Unfortunately, on newer cards, the hardware doesn't support PIO mode.
The queue lengths are reported as 0, so we can't use them. :p
-Joe
___
Bcm43xx-dev mailing
iwconfig eth1 rate 11Mb
iwconfig eth1 mode Managed
iwconfig eth1 ap 00:0d:72:7c:24:c9
iwconfig eth1 key restricted
softmac just supports open authentication.
softmac supports wpa (and wep, iirc)
Those are encryption methods. Restricted authentication is an extra
step in the
bcm43xx: Chip ID 0x4312, rev 0x0
bcm43xx: Number of cores: 4
Is this a PCI-E Card? Can we get more details about the card itself?
bcm43xx: Unknown core found (ID 0x900)
bcm43xx: Unknown core found (ID 0x817)
bcm43xx: Unknown core found (ID 0x820)
That's interesting though. The 0x900 is
Does anyone know why, in particular, the 11M trick needs to occur with
most (all) cards?
We don't really understand all of the power settings yet. We're working
on it.
-Joe
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
Douglas Ward wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was wondering if this driver (when finished) would be able to support
broadcom's afterburner technology (linksys calls it Speedbooster
technology) sorry if this is the wrong place to ask about such things.
- --
Douglas K Ward
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventing the wheel again and again? Yes, I know that code is not
perfect and needs a
57 matches
Mail list logo
