[tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus)
Matti Aarnio
matti.aarnio@zmailer.org
Wed, 3 Jan 2001 21:22:01 +0200
On Wed, Jan 03, 2001 at 11:39:04AM -0500, Donald Becker wrote:
> > I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX
>
> These are new SROM entry types.
> They are pretty obscure, and I didn't expect to see them.
Famous last words, or that effect...
...
> > The Scyld driver has type 5 supported, and somehow I thought that 6 is
> > just a variant of that.
>
> No, it's a different type of reset.
I see.
> Type 5 was introduced because some SYM transceivers needed to be reset
> in order to switch back to 10baseT mode so that autonegotiation could take
> place. It isn't needed for MII transceivers since they retain the
> autonegotiated capability word, and have their own reset sequence.
>
> My driver uses block type 5 only for SYM transceivers.
I haven't understood the difference of MII and SYM tranceivers,
specifically, can both types of tranceivers exist at some card ?
> Type 6 appeared to be a hack to work around a bug in a specific piece of
> hardware. The driver had to shut down the SYM transceiver when the cable
> was physically removed, but there was circuitry to restart the transceiver
> when the cable was inserted. It only applied starting at a specific
> revision of the 21143, and the SROM manual had a note about how the Intel
> drivers were broken, uhmmm, had unpredictable results for the general case.
>
> My driver ignores block type 6. I believe that this is correct.
I just switched back and forth between 100BaseT-FDX switch, and
10BaseT HUB, one such transition appears to "tulip-diag -mm" as
shows below. (I have also one 100BaseT hub somewhere, but couldn't
find it now.)
So that interface seems to work with MII in both modes.
What could be the point with those other media specifications
at this card ?
--- t.1 Wed Jan 3 20:20:14 2001
+++ t.4 Wed Jan 3 20:29:40 2001
@@ -1,18 +1,18 @@
tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DS21143 Tulip adapter at 0x2400.
- Port selection is MII, full-duplex.
- Transmit started, Receive started, full-duplex.
+ Port selection is MII, half-duplex.
+ Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 128.
The NWay status register is 000000c6.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
- 3000 782d 0040 6212 01e1 41e1 0003 0000
+ 3000 782d 0040 6212 01e1 0021 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
- 5000 0300 0000 0000 0000 017f 0500 0000
- 003f 853e 0f00 ff00 002f 4000 80a0 000b.
+ 5000 0000 0000 0000 0000 0000 0800 0000
+ 003c 8006 0f00 ff00 002c 4000 0080 000b.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
@@ -23,6 +23,6 @@
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
- Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
- Negotiation completed.
+ Link partner capability is 0021: 10baseT.
+ Negotiation did not complete.
Internal autonegotiation state is 'Autonegotiation disabled'.
> ...
> > Leaf node at offset 30, default media type 0800 (Autosense).
> > 3 transceiver description blocks:
> > Media MII, block type 3, length 19.
> > MII interface PHY 0 (media type 11).
> > 21143 MII initialization sequence is 0 words:.
> > 21143 MII reset sequence is 3 words: 0807 0000 0002.
> > Media capabilities are 7800, advertising 01e1.
> > Full-duplex map 5000, Threshold map 1800.
> > No MII interrupt.
> > Media MII, block type 5, length 8.
> > Adapter Reset Sequence, sequence length 3: 0807 0000 0002.
>
> OK, so this is bogus. A Type 5 block isn't needed for MII transceivers,
> since the reset sequence is already in the Type 3 block. Indeed, they are
> identical here.
>
> > Media MII 100baseT4, block type 6, length 11.
> > Adapter Reset Sequence, sequence length 15: 0704 0008 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000.
>
> I'm guessing that you added this case to the tulip-diag program.
Now that you mention it, yes, very possibly.
Downloading your baseline version....
> It's not quite right. It should read something like
>
> Media Reset, block type 6, length 11.
> Adapter Reset Sequence, sequence length 4: 0807 0000 0000 0002
Your tulip-diag + libmii reports actually:
Media MII, block type 5, length 8.
Adapter Reset Sequence, sequence length 3: 0807 0000 0002.
Media MII 100baseT4, block type 6, length 11.
UNKNOW MEDIA DESCRIPTION BLOCK TYPE!
06 0f 04 07 08 00 00 00 00 02 00.
> I'll add a correct line to 'tulip-diag'.
>
> But this is completely bogus. This type of reset only applies to SYM
> transceivers, not MII transceivers. I suspect that it is harmless to ignore
> this, since all three reset sequences are exactly the same.
Indeed.
> > diff -u --recursive --new-file v2.4.0-prerelease/linux/drivers/net/tulip/media.c linux/drivers/net/tulip/media.c
> > --- v2.4.0-prerelease/linux/drivers/net/tulip/media.c Mon Jun 19 13:42:39 2000
> > +++ linux/drivers/net/tulip/media.c Mon Jan 1 09:54:07 2001
> > @@ -263,6 +263,24 @@
> > tulip_mdio_write(dev, tp->phys[phy_num], 4, to_advertise);
> > break;
> > }
> > + case 5: case 6: {
> > + u16 setup[5];
> > + u32 csr13val, csr14val, csr15dir, csr15val;
> > + for (i = 0; i < 5; i++)
> > + setup[i] = get_u16(&p[i*2 + 1]);
>
> Errrmmm, this code is pretty bogus. Did it really do anything for you?
Aside of not complaining and the card works ?
Unfortunately that change wasn't the only one which happened
in between previous non-functional test, and this new one.
(Changes like pcmcia-cs tulip_cb.c vs.
Linux 2.4.0-testNN/drivers/net/tulip/, some other details
with PCMCIA/CARDBUS support.)
> Donald Becker becker@scyld.com
> Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
> Annapolis MD 21403 410-990-9993
/Matti Aarnio