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.

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.

The standard release version of the driver is at ftp://ftp.scyld.com/pub/network/tulip.c. This version should compile with all kernels from before 1.2.0 through the current 2.2 version. Support for the 2.3/2.4 kernels may be inconsistent due to the frequent interface changes being made to the development kernel.
There may also be a test version of the driver at ftp://ftp.scyld.com/pub/network/test/tulip.c, perhaps with better performance and extra features. This version is intended to support 1.2 through 2.2 kernels, but is only tested with a few recent kernel 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

For Experts Only: My guide to writing media descriptions for cards old-style EEPROMs.
Old Digital/Intel Tulip information web page.
http://www.intel.com/design/network/21143.htm New Intel 21143 information.
Macronix network products web page, http://www.mxic.com.tw/ (A perfect example of why not to use Lotus products to produce web pages.)
Lite-On PNIC web page http://www.ltnlcc.com.tw/
ADMtek web site
ASIX web site

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.






Products Scyld Beowulf Professional Edition Scyld Enterprise Solutions Scyld Training Scyld Beowulf Overview Support Documentation FAQs Network Drivers Network Diagnostics Network driver mailing lists Vendors About Scyld Press Releases Employment Contact Search	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 Comments on the PNIC Comments on the 21142/21143 References and Other Information Sources 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. The standard release version of the driver is at ftp://ftp.scyld.com/pub/network/tulip.c. This version should compile with all kernels from before 1.2.0 through the current 2.2 version. Support for the 2.3/2.4 kernels may be inconsistent due to the frequent interface changes being made to the development kernel. There may also be a test version of the driver at ftp://ftp.scyld.com/pub/network/test/tulip.c, perhaps with better performance and extra features. This version is intended to support 1.2 through 2.2 kernels, but is only tested with a few recent kernel 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 For Experts Only: My guide to writing media descriptions for cards old-style EEPROMs. Old Digital/Intel Tulip information web page. http://www.intel.com/design/network/21143.htm New Intel 21143 information. Macronix network products web page, http://www.mxic.com.tw/ (A perfect example of why not to use Lotus products to produce web pages.) Lite-On PNIC web page http://www.ltnlcc.com.tw/ ADMtek web site ASIX web site 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.


© 2000-2002 Scyld Computing Corporation