New version of 'tulip-diag' available

[KOGAN_VADIM]

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

> > Well... I looked around and figured that
> > a) this must be an empty EEPROM (CRC is Ok + I was unable to find
> > anything usable - not after this 128 bytes, not w/ 8 bit
addressing)
> 
> It's not completely empty though -- the first value is 
> 0x8086, Intel's vendor
Yeah, but that's only ID block :-(
> ID.  That's bad news -- we are probably reading the EEPROM 
> correctly, it
> just doesn't have anything in it.
> 
> More likely, the program just "knows" how the card is 
> configured.  It's a
> real PITA to parse the EEPROM and guess what the designer meant. 
It's
> much easier to write a driver that only has to work with a 
> single card type.
> 
> > e) And now comes the real question - what if I get a disasm 
> and try to
> > see what's happening? Can that help? Or that would be PITA to
track?
> 
> That might be the best approach.
Did you have this situation before? If so, maybe you can share some
ideas...

> 
> Guessing at the correct register CSR15 values might 
> physically damage the
> card.
It's that bad? Hmm.. The damn thing has lifetime warranty, it's Intel.
Something tells me that I should be able to replace it, but that would
be another PITA.

Do you happen to have a pointer to some nice place that explains a
little bit about all those registers? I'm kinda new to that yet.

BTW, did you ever try to talk to Intel? I know they helped somehow w/
PCMCIA support for some of their cards (flush?). Do they send docs for
cards? I know they love to send docs for chips. BTW, now when tulip is
made by intel, they have all SROM format docs on their own site. "We
know the right way, but we don't follow it" :-(

Vadim.

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

iQA/AwUBNxBj1osB3WHoGn03EQIHdgCfXiQQVSI83pt6edpWYrOF+FXw9v4An2ji
QE0JT6GTEYA60tU1UJH3j1yS
=Cq67
-----END PGP SIGNATURE-----