From: Andrew Miklas <public@mikl.as>
To: Gianni Tedesco <gianni@scaramanga.co.uk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linux Incompatibility List
Date: Sun, 29 Aug 2004 17:04:21 -0400 [thread overview]
Message-ID: <200408291704.24820.public@mikl.as> (raw)
In-Reply-To: <1093749701.7064.37.camel@sherbert>
[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]
Hi,
On August 28, 2004 11:21 pm, Gianni Tedesco wrote:
<snip>
> OK, exactly which drivers were you using to do this? When I had the
> interface brought up in win2k-server with the bcmwl5.sys driver I was
> seeing every few hundred milliseconds a batch of say 12 2-byte reads on
> the register space to check status...
I was never able to get it going myself (If I remember correctly, there was
some issue with how the interrupts were being routed on my notebook. We were
doing some strange stuff to forward interrupts from the host kernel into
Bochs that didn't work on all configurations.)
However, Frank Cornelis was using the Windows 98 drivers running under Win98
on pcidev+Bochs. Kendall Blake was using the Windows XP drivers and a
modified ndiswrapper running under Linux also on pcidev+Bochs. Kendall told
me that he generated about 400 megs of logs just looking at the card
initialization. I think it was at this point I decided that decompiling the
thing would be easier. :)
Anyway, you could try asking Frank and Kendall for some of the data they
gathered.
kendallb () eden rutgers edu
fcorneli () pandora be
<snip>
>
> Hrm, you're sure those variations aren't trivial? Although theres lots
> of checks, I would have thought they would just be stuff like "card A
> supports X, Y and Z features"?
The differences between radio chips (ex. a vs. g) aren't going to be trivial.
That is to say, entirely different code paths are executed in the wlc_phy.o
component. The variations caused by different board configurations don't
appear to be too big (at least from the code I've looked at). Some of the
variations (probably bug fixes) caused by different revisions of the chips
are also a little large. But, I think it will be pretty difficult to
determine how the differences in the dumps relate to differences in the
hardware configuration.
>
> The approach that makes the most sense to me is get 1 card working to
> the point where it sends/receives packets, then look at the binaries to
> see what the variations are, and how they apply to what cards and just
> go fill in the blanks...
The problem is that all Broadcom's wireless hardware is supported by one big
driver. If you wanted to be able to see the differences between what code is
executed against each device, you'd pretty much have to decompile the whole
thing, or at least do some serious debugger work. Assuming you don't want to
do that, it seems you're left with doing the capture analysis on every
variation, which doesn't seem practical.
<snip>
> Also, you mention DMA and sending/receiving packets, exactly how much
> progress have you made so far?
I'm pretty sure that they were able to get packets to go back and forth. But,
the last I heard from anyone using the capture method with pcidev and Bochs
was about six months ago.
-- Andrew
[-- Attachment #2: Type: application/pgp-signature, Size: 201 bytes --]
next prev parent reply other threads:[~2004-08-29 21:07 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-21 19:41 Linux Incompatibility List David N. Welton
2004-08-21 20:16 ` Joseph Pingenot
2004-08-21 20:20 ` Wakko Warner
2004-08-21 20:31 ` Lee Revell
2004-08-21 20:51 ` Wakko Warner
2004-08-21 21:06 ` Jan-Benedict Glaw
2004-08-21 21:11 ` Lee Revell
2004-08-21 21:16 ` Lee Revell
2004-08-22 14:30 ` Tonnerre
2004-08-22 14:45 ` Michael Buesch
2004-08-24 15:17 ` Jan-Benedict Glaw
2004-08-24 17:41 ` Michael Buesch
2004-08-21 21:18 ` Francois Romieu
2004-08-21 22:01 ` Wakko Warner
2004-08-21 23:53 ` Andrew Miklas
2004-08-23 3:54 ` Gianni Tedesco
2004-08-25 5:59 ` Andrew Miklas
2004-08-25 7:21 ` Gianni Tedesco
2004-08-29 1:42 ` Andrew Miklas
2004-08-29 3:21 ` Gianni Tedesco
2004-08-29 21:04 ` Andrew Miklas [this message]
2004-08-22 5:29 ` Jonathan Bastien-Filiatrault
2004-08-22 1:56 ` James Courtier-Dutton
2004-08-22 6:36 ` Jonathan Bastien-Filiatrault
2004-08-22 4:15 ` Kyle Moffett
2004-08-22 5:58 ` Lee Revell
2004-08-22 8:05 ` Geert Uytterhoeven
2004-08-22 12:07 ` R. J. Wysocki
2004-08-22 12:32 ` Gene Heskett
2004-08-24 21:30 ` Hamie
2004-08-22 15:25 ` Tonnerre
2004-08-22 11:10 ` Alan Cox
2004-08-22 12:42 ` Dave Jones
2004-08-23 6:31 ` Eric W. Biederman
2004-08-21 21:20 ` David N. Welton
2004-08-21 22:03 ` Wakko Warner
2004-08-22 0:18 ` Rutger Nijlunsing
2004-08-21 20:22 ` David N. Welton
2004-08-22 11:14 ` Alan Cox
2004-08-22 15:08 ` Joseph Pingenot
2004-08-22 20:48 ` David N. Welton
2004-08-22 20:45 ` Alan Cox
2004-08-23 20:45 ` cliff white
[not found] ` <200408221045.29316.mbuesch@freenet.de>
2004-08-22 20:34 ` David N. Welton
2004-08-22 21:24 ` David N. Welton
2004-08-25 7:41 ` Helge Hafting
2004-08-25 7:49 ` David N. Welton
2004-08-31 7:28 ` Helge Hafting
2004-08-31 10:21 ` David N. Welton
-- strict thread matches above, loose matches on Subject: below --
2004-08-22 4:19 linux
2004-08-22 13:05 ` Wakko Warner
2004-08-22 16:43 ` Horst von Brand
2004-08-22 22:42 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200408291704.24820.public@mikl.as \
--to=public@mikl.as \
--cc=gianni@scaramanga.co.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.