Penny for your thoughts (on DECchip)

[B. James Phillippe]

On Sat, 8 Aug 1998, Donald Becker wrote:

> [[ Quick note: the 0.89K version puts a 21143w/MII into Rx-all mode.
>   Look for 0.89L in a few hours. ]]

Excellent, I'll try it out ASAP, and let you know the results.  Looks like
a lot of changes; I'm eager to test the 21143/MII support. 8)

> On Sat, 8 Aug 1998, B. James Phillippe wrote:
> 
> > In my case, I have boards with the (common) QS6611 tranceiver.  I spoke to
> > an engineer at Digital/Intel who informed me that with this tranceiver it
> > is not possible to do NWay for 100base-Tx.  There is no MII on my board.
> 
> Check out the QS6611 datasheet at
>    http://www.qualitysemi.com/products/network.html

Okay, I'll take a look at this, too.  I have a .pdf file from
developer.intel.com that has some information on this tranceiver, also, but
I don't recall seeing anything in there that jumped out at me.  BTW, I
found that some of our test boards do seem to have MII tranceivers.  It's
wacky, really; they're all supposed to be identical, but both tulip.o and
tulip-diag report MII's on about 1/4 of the NIC's.  Is it possible that a
mis-programmed SROM or other board problem would produce a phantom MII?
I can't see anything physically different on them..

> This transceiver includes specific support for the NWay autonegotiation.
> Note that the autonegotiation must take place on the 10baseT link beat, so
> you can't start at 100mbps.  Once the driver has decided that
> autonegotiation has failed it should switch to auto-sense mode, looking for
> link beat first at 10mbps, then at 100mbps.

Ah... I see.  This makes a lot of sense.  This "auto-sense" mode you
describe is where you are stopping transmit/receive, setting CSR6 with
appropriate values (for threshold, etc), then resetting SIA and port
activity bits.. and then CSR5 interrupts on link pass?  And then test
10/100 link fail bits in CSR12?

> > What drives me nuts though is that Windows98 seems to be able to detect the
> > media type very quickly without a problem.  I wonder if they a.) know
> > something we don't, or b.) are polling the controller very rapidly and
> > looking for activity bits.
> 
> The generic Win98 driver, or a card-specific one?
> Is it do NWay, or link beat sensing?
> It's possible the link beat signal is connected to a general-purpose pin.

It's the generic included driver, which I hate to admit seems to work
semi-reliably.  It (and the davies driver) can hiccup if you're swapping 10
and 100 quickly, and then can get "stuck" at 10Mbit on a 100Mbit cable.
Then you have to pop it back in.  I don't know if the Windows driver does
NWay, but there is near-zero delay between switching media types.

> >  Is this SROM decoding what you mean when you refer to the
> > EEPROM media table?  How does this work?  I can't seem to find any further
> > information in any of the material I have.
> 
> Digital calls it the "SROM" (Serial ROM).  It's always an EEPROM, so I call
> it that.
> Digital has published about a zillion version of the SROM table description.

So using this table description (assuming an accurate one was available)
would allow you to determine the media type of a connection?  It seems that
if this were possible, it would be much smarter/easier for there to just be
a word in a CSR that would indicate this information(?)  The only part of
the EEPROM I can identify is the MAC address. :(  I suppose I can run
tulip-diag -e -e -f when connected to different media types...?  Perhaps
this will educate me further..

> Oh, and most versions are only available in MSWord version-de-jour.
>
> [[ I just deleted a very nasty comment.. ]]

Darn, and deprive me of the free entertainment.

-bp
--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGT Inc.
http://earth.terran.org/~bryan