Linux Driver Development for the "Tulip" Ethernet Architecture

This page contains development information on the Linux device drivers for the Intel (nee Digital) 21040/21041/21140/21142/21143 "Tulip" chips, as well as the many other chips which use this architecture. The master copy of this page resides on the Scyld web server.

Index

People

People associated with this project are
Donald Becker
becker@scyld.com

Drivers

For information on the released driver and usage, see the main Tulip web page.

This driver is available in several versions.

Current driver issues:

  • Supporting the Matrox multiport board that was deliberately designed to not work with non-Matrox drivers. They put the EEPROM on the second of the four ports, so that neither detection order would find that interface first.
  • Detecting when the interrupt lines are actually mapped to the reported IRQs, instead of all being on one IRQ. Almost all x86 motherboard BIOSes report incorrect IRQ lines for all but the first port on multiport boards. The best I can come up with storing an alternate possible IRQ value in struct tulip_private. If the timer code detects that the chip has posted an interrupt that we haven't gotten, release the primary IRQ and request the new one. Ugly, especially if we fail requesting the new one.

Info on the Lite-On PNIC

The PNIC chip uses a register interface very similar to that of the Digital Tulip chip series.

The modifications to the Tulip driver are:

Recognizing the vendor and device ID
The PNIC uses vendor ID 0x11AD and device ID 0x0002
Reading the EEPROM
  • it's much like a 21040, not the 21041 or 21140.
  • Data is read as 16 bit words in CSR9 (low 16 bits)
  • a new register at offset 0x98 specifies the EEPROM address to read
    	   outl(0x600 | addr, ioaddr + 0x98);
    	   while (inl(ioaddr + 0x98) & 0x80000000) /*wait*/ ;
    	   result = inl(ioaddr + CSR9) & 0xffff;
        
the setting of CSR6 is similar to the 21140
the use of the general purpose pin register, CSR12, is unique
  • it should be set to 0x33 for 100mbps, 0x32 for 10mbps
  • read bit 0x08 for 100mbps link beat (1 == 100mbps ???)
a new register at offset 0xB8 controls the internal transceiver
the default setting does not enable NWay autonegotiation.

Comments on the 21142/21143

I lump these two chips under one heading because they both report the same PCI chip ID. While their programming interfaces are similar, it would have been easier to support them if Digital hadn't tried to pretend that they were the same chip. But I guess that is keeping with Digitals tendency to add features without updating the part number.

The 21143 adds NWay autonegotiation support to the Tulip core. This requires a bit of an explaination: All fast Ethernet versions of the Tulip have three physical media "PHY" interfaces: an on-chip 10baseT section, a 5B symbol mode "SYM" interface, and a "MII" media independent interface.

The PHY interface is 100mbps-only port that handles part of the transceiver functionality and was intendended for early products, before regular MII transceivers were available. The PHY interface is usually used in conjuction with the on-chip 10baseT transceiver, with a relay to select between the 10 and 100mbps port.

The MII interface is a general-purpose interface to transceivers that support both 10 and 100mpbs, with arbitrary physical layer modulation. That means that they can support and automatically select among 10baseT, 100baseT4, 100baseFx and 100baseTx without the host chip needing to know much about what is going on. Typically MII transceivers support NWay internally, with the driver only needing to read the MII transceiver's management registers to find out if full-duplex has been negotiated.

While most PCI board designs have switched over to using MII transcievers, CardBus power limitations and agressive cost reductions have made it advantageous to once again use the simplier SYM transceivers. For this to be acceptable in the current network world, Digital had to add NWay negotiation to the on-chip 10baseT transceiver.

Alas, Digital didn't quite get it right. I don't mean from a functionality standpoint -- the chip can physically do everything. But they omitted the easy-to-implement functionality of MII's automatic speed selection, instead electing to have the chip generate an interrupt and let the driver figure out what is going on. That's not a big deal, except that it doesn't mesh with the media selection procedure on their previous chips, and it doesn't work at all well with their media descriptions in SROM (which were only required because of earlier design botches).

A few more specific bitches about the 21142 design:

  • Why the hell are the NWay advertised capability bits sprinkled randomly over CSR14 and CSR6? And why overload the 10baseTx-FD capability bit in CSR6 bit 10?
  • There is no fast way to detect incoming 100baseTx link beat. It's not even clear how long you have to be in 100baseTx mode before you can detect a link beat.
  • With only two bits defined in CSR13, why put aggregate such disparate functionality in CSR15?

References and Other Information Sources

Long-term

  • Implement the Wake-On-LAN capability available in 21143. The driver part is easy, but the kernel support requires writing extensive APM interface code.

Support

Support for the Tulip driver is now being handled through the mailing list linux-tulip-request@beowulf.org. To subscribe, send a message with word "subscribe". To do this at the shell prompt do: echo subscribe | /bin/mail linux-tulip-request@beowulf.org

Diagnotic program

A diagnostic program is available to help debug media selection and board-setup problems.


Author:Donald Becker, becker@scyld.com.

Linux Network Drivers Page
SCYLD information.
Author: Donald Becker
See the drivers for the contact email address. Do not bother sending email to zinc.anode@scyld.com, as email to that address adds your domain or IP address to the known-spammer list.