Intel-brand 21143 CardBus card

KOGAN_VADIM KOGAN_VADIM@student.smc.edu
Tue Apr 13 01:06:38 1999


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > btw, dump_cis shows
> > lan_node_id 00 a0 c9 bb 00 3a
> 
> OK.
> But the PCI+CardBus drivers do not deal with the CIS.
> That's a design decision I'm not going to change for a single card.
But is this true MAC address?


> It turns out I added this to a different branch of tulip-diag 
> than I was
> publically releasing.  My internal version has all sorts of grungy
> negotiate-the-media-type code that is a prototype of what I 
> put into the
> driver.

Ok, here's the output of ./tulip-diagn2 -a -f -p 0x400 -ee -t 4
tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Digital DS21143 Tulip chip registers at 0x400:
  ffa08000 ffffffff ffffffff 00fff810 00fffa10 f0660000 38602002
fbfffbff
  e0000000 ffffcbf8 ffffffff fffe0000 000000c6 ffff0000 ffffffff
8ff00000
 Port selection is 10mpbs-serial, half-duplex.
 Transmit started, Receive started, half-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Idle'.
  The transmit unit is set to store-and-forward.
EEPROM contents:
  8086 0001 0087 0000 0000 0000 0000 0000
  00c4 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 4448
 ID CRC 0xc4 (vs. 0xc4), complete CRC eddd19c7.
 A simplifed EEPROM data table was found.
 The EEPROM does not contain transceiver control information.


> ***THE FOLLOWING IS A HACK.  Do not play with this unless you 
> need it.***
> I've implemented a '-G CSR15GPIOVAL' option to allow 
> experimenting with the
> CSR15 settings.  We can set CSR15 to typical values and see if the
> transceiver comes on:
>    tulip-diag -p 0x400 -t 4 -G 0x08af0000
>    tulip-diag -p 0x400 -t 4 -G 0x00a50000
> 
> The first command sets the four GPIO pins to be outputs. 
(0x080f0000)
> Two of the four are set to be LEDs, the other two are 
> software set.(0x00a00000)
> The second command sets the two non-LED output pins to be 
> high (0x00050000).
> 
> These are the settings in the Digital design example.
> Most card designers use the example design unless there is a 
> good reason to
> do something else.

Ghm, where are docs for this stuff? I'm still a little bit confused
when you're talking about those regs. But anyway, I'm willing to try
anything you consider to be helpful (and I guess that it's kinda Ok to
burn the card, but we better know that we did it, so that there won't
try to get anything out of dead card).

Vadim.

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQA/AwUBNxLPeYsB3WHoGn03EQKKwQCfZjn/u+dfu3/EY+rp4A3HH4uugJEAn15+
ok2U/MJOzsEYw6NLO2ASc3oU
=Kwvw
-----END PGP SIGNATURE-----