New version of 'tulip-diag' available

Sun Apr 11 04:03:51 1999

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
> 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. 
> 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
> That might be the best approach.
Did you have this situation before? If so, maybe you can share some

> 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" :-(


Version: PGP 6.0.2