Penny for your thoughts (on DECchip)

[B. James Phillippe]

On Sat, 8 Aug 1998, Donald Becker wrote:

> On Wed, 5 Aug 1998, B. James Phillippe wrote:
> 
> > 	My main problem is this: the 21143 doesn't seem to autonegotiate
> > 100base-Tx.  10base-T will autonegotiate (per CSR12), and CSR5 interrupts on
...
> > for all media types.  I can't believe that this would be an intentional
> > design limitation of the chip.  Do you have any advice for me?
> 
> I can't seem to get the 21143 chip to do all of its magic either.  And the
> Tulip driver is a horrible mess, since media selection has to been done
>    at probe time,      (must generate link beat immediately)
>    at open() time,     (can't delay operation for simple boards)
>    during interrupts,  (21143/LiteOn/MXIC)
>    in response to timer ticks and  (21040, 21041, FD with MII)
>    during transmit timeouts.   (gotta do something)

I've been trying to follow your footsteps through the driver.  It's quite
amazing really, how complicated the media-detection can be.  The 21143
databook claims at one point (6.6 Autonegotiation) "The whole negotiation
is done by the 21143 without software involvement".  I don't know who
they're trying to kid.

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.
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.

> Complicating all of this is the EEPROM media table.  It's sometimes missing
> or wrong (copied verbatim from the Digital design kit), so the driver must
> hedge its bets.  But with the 21140 chips it is the only way the driver can
> enable and detect the link beat on SYM transceivers.

I did some investigation with Davies de4x5.c driver.  It's a much (much!)
larger piece of code and has some very hard to follow sections (the
"recursively decode the infoblocks" section loses me).  However, media
detection there works almost identical to the Windows98 driver.  I also
notice that the de4x5 driver doesn't use NWay at all?  It seems the
autonegotiation state bits in CSR12 are always 0, disabled.  Based on
comments in the code, it seems that he detects the media type by frequently
interating over the SROM.  How this works I do not know.  There is also a
comment that FD detection is not possible using this means of media
detection.  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.

Thanks again for your helpful information!

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