Writing Tulip 21140 Media Description Tables

Notice: this information is needed only by driver developers. If you are a casual user of the Tulip driver you will not need to use or understand the information in this document. You should instead refer to the main Tulip driver page.

Problem Description

The Digital 21140, 21142 and 21143 Fast Tulip chips do not have a specified transceiver control interface. Instead they have eight unassigned general purpose pins controlled through the CSR12 register. These pins may be set to either inputs or outputs, and Digital provided no design suggestions. Thus every board design uses a unique mapping for the pins.

This (obvious IMO) problem became painful when every 21140 board required its own incompatible device driver. Digitial attempted to mitigate the problem by defining an EEPROM transceiver description table, but this occured too late for many boards and the initial versions had significant omissions. Subsequent versions have fixed most of the egregious flaws, but the table format is still very complex to parse and doesn't provide for some important information (e.g. the full-duplex information provided on some cards, and loopback control).

This problem does not affect the older Digital 21040 and 21041 Tulip chips, which have well defined transceiver interfaces. The 21040 has a unique EEPROM interface and a simple EEPROM layout. It supports only a 10baseT interface and one other AUI-style (typically 10base2) transceiver.

The 21041 has the new style EEPROM interface, and Digital has defined an EEPROM table format. But the only transceiver control change is an additional pin designated for switching between a 10base2 transceiver and AUI port. Thus the only EEPROM table information needed is which interfaces the specific card provides, 10baseT, AUI and/or 10base2.

The 21142/21143 has the new style EEPROM interface, and same complicated EEPROM table format of the 21140. But the table entries are of little use: the driver must know so much about each potential table entry that it effectively ignores them. For instance, 21143 media selection status changes are indicated by interrupts, which the driver must know to handle for each media type. Thus a media table entry is pointless.

Do you need to do this?

A card with an old-style EEPROM will be obvious. Both the tulip-diag program and the driver will report that you have an "old-style EEPROM". If you have a 21041 card, your card will almost certainly work anyway and you can ignore this message. If you have 21140 card that doesn't work, you should follow this proceedure.

Writing your own 21140 media description table.

The Linux tulip.c driver supports cards without a Digital-style media description table by substituting its own table. To add support for an unknown card you must write this table and add it to the driver.

Example table entry

A typical written-by-hand driver entry is one for the Maxtech NX-110:

  {"Maxtech NX-110", 0, 0, 0xE8, { 0x1e00, 0x0000, 0x0800, 0x0313,
                         0x1001, 0x009E, /* 10base2, CSR12 0x10*/
                         0x0000, 0x009E, /* 10baseT */
                         0x0303, 0x006D, /* 100baseTx, CSR12 0x03 */ }},

The first entry is a string with the card name and model number, used for emitting the card name at initialization time. The next three numbers are the station address prefix, the first three bytes of the ethernet hardware address which uniquely identify the card vendor. (Note: we can only support a single broken card type from each vendor.) The final element is the actual Digital-format table.

The table is an defined as an array of unsigned 16 bit values. (Note that it parsed on byte boundaries.) The first three table values are rarely changed:

    0x1e00, 0x0000	Table start offset
    0x0800		Default media type, 0x0800 mean "Dynamically Autosense"

The next value is the number of transceiver descriptions and the direction of the general purpose control lines:

   0x0313	Three transceiver entries, and a direction setting of 0x13

Bits set to '1' in the direction byte configure the pin to be an output rather than an input.

Each transceiver description indicates the control port settings, the media type, and which bit on the control port to monitor for link beat. As an example, the 10baseT setting for the Maxtech board is

  0x1001, 0x009E,

  0x10**  Set the control pins to bit pattern 0 0 0 1  0 0 0 0
  	Since our direction setting is 0x13, the actual output is
	     * * * 1  * * 0 0
        where the "*" indicates an input pin.
  0x**01	This entry describes media type 1, 10baseT

  0x009E  Set the chip up for 10mbps operation, and monitor line 7 for
      a '0' which will indicate link beat.
      This compact entry is composed of the following elements:

   0x0000  Set the chip for 10mbps operation.
   0x0061  Set the chip for 100mpbs operation

   0x0000  Monitor line 0.
   0x0002  Monitor line 1.
   0x0004  Monitor line 2.
    ..
   0x000E  Monitor line 7.

   0x0000  A '0' on the monitored line indicates no link beat.
   0x0080  A '1' on the monitored line indicates no link beat.

Adding card support

The first step for adding support is figuring out what the general purpose lines are use for. The most complete method is to follow the traces on the circuit board, but it's also possible to do this without opening up the machine.

Several general purpose lines are almost always used for:

    10baseT link beat (input)
    100baseTx link beat (input)

The following might also be provided as outputs:

    Enable 100baseTx transceiver
    Enable BNC transceiver

Outputs we aren't concerned with, except to avoid mis-setting them, are

    Set 10mbps transceiver to loopback
    Set 100mbps transceiver to loopback

Deducing which lines are used to detect link beat

You'll need a method to generate both 10baseT and 100baseT link beat signals, and a way to monitor the CSR12 general purpose register to see which input lines change state when the cables are attached to the cards.

Generating the link beat is best done with 10baseT and 100baseTx repeaters. It can also be done with a 10/100 transceiver that can be forced into a specific mode. Using an autosensing/autonegotiation link won't work, since it might switch speeds.

It's easiest to use the tulip-diag program to report the value of CSR12, although the driver itself can be used instead: Configure your system to load the tulip driver as a module. Load the module with the option debug=2 to get additional debugging information. Then configure the interface using a command such as /sbin/ifconfig eth0 192.168.1.1. The driver should report the current value of CSR12. Run ifconfig eth0 down before the next test. Check the value of CSR12 with both 10baseT and 100baseT signals hooked up until you are certain you have figured out which input lines are used to indicate the link beat signals.

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	Writing Tulip 21140 Media Description Tables Notice: this information is needed only by driver developers. If you are a casual user of the Tulip driver you will not need to use or understand the information in this document. You should instead refer to the main Tulip driver page. Problem Description The Digital 21140, 21142 and 21143 Fast Tulip chips do not have a specified transceiver control interface. Instead they have eight unassigned general purpose pins controlled through the CSR12 register. These pins may be set to either inputs or outputs, and Digital provided no design suggestions. Thus every board design uses a unique mapping for the pins. This (obvious IMO) problem became painful when every 21140 board required its own incompatible device driver. Digitial attempted to mitigate the problem by defining an EEPROM transceiver description table, but this occured too late for many boards and the initial versions had significant omissions. Subsequent versions have fixed most of the egregious flaws, but the table format is still very complex to parse and doesn't provide for some important information (e.g. the full-duplex information provided on some cards, and loopback control). This problem does not affect the older Digital 21040 and 21041 Tulip chips, which have well defined transceiver interfaces. The 21040 has a unique EEPROM interface and a simple EEPROM layout. It supports only a 10baseT interface and one other AUI-style (typically 10base2) transceiver. The 21041 has the new style EEPROM interface, and Digital has defined an EEPROM table format. But the only transceiver control change is an additional pin designated for switching between a 10base2 transceiver and AUI port. Thus the only EEPROM table information needed is which interfaces the specific card provides, 10baseT, AUI and/or 10base2. The 21142/21143 has the new style EEPROM interface, and same complicated EEPROM table format of the 21140. But the table entries are of little use: the driver must know so much about each potential table entry that it effectively ignores them. For instance, 21143 media selection status changes are indicated by interrupts, which the driver must know to handle for each media type. Thus a media table entry is pointless. Do you need to do this? A card with an old-style EEPROM will be obvious. Both the tulip-diag program and the driver will report that you have an "old-style EEPROM". If you have a 21041 card, your card will almost certainly work anyway and you can ignore this message. If you have 21140 card that doesn't work, you should follow this proceedure. Writing your own 21140 media description table. The Linux `tulip.c` driver supports cards without a Digital-style media description table by substituting its own table. To add support for an unknown card you must write this table and add it to the driver. Example table entry A typical written-by-hand driver entry is one for the Maxtech NX-110: {"Maxtech NX-110", 0, 0, 0xE8, { 0x1e00, 0x0000, 0x0800, 0x0313, 0x1001, 0x009E, /* 10base2, CSR12 0x10/ 0x0000, 0x009E, / 10baseT / 0x0303, 0x006D, / 100baseTx, CSR12 0x03 / }}, The first entry is a string with the card name and model number, used for emitting the card name at initialization time. The next three numbers are the station address prefix, the first three bytes of the ethernet hardware address which uniquely identify the card vendor. (Note: we can only support a single broken card type from each vendor.) The final element is the actual Digital-format table. The table is an defined as an array of unsigned 16 bit values. (Note that it parsed on byte boundaries.) The first three table values are rarely changed: 0x1e00, 0x0000 Table start offset 0x0800 Default media type, 0x0800 mean "Dynamically Autosense" The next value is the number of transceiver descriptions and the direction of the general purpose control lines: 0x0313 Three transceiver entries, and a direction setting of 0x13 Bits set to '1' in the direction byte configure the pin to be an output rather than an input. Each transceiver description indicates the control port settings, the media type, and which bit on the control port to monitor for link beat. As an example, the 10baseT setting for the Maxtech board is 0x1001, 0x009E, 0x10* Set the control pins to bit pattern 0 0 0 1 0 0 0 0 Since our direction setting is 0x13, the actual output is * * * 1 * * 0 0 where the "" indicates an input pin. 0x01 This entry describes media type 1, 10baseT 0x009E Set the chip up for 10mbps operation, and monitor line 7 for a '0' which will indicate link beat. This compact entry is composed of the following elements: 0x0000 Set the chip for 10mbps operation. 0x0061 Set the chip for 100mpbs operation 0x0000 Monitor line 0. 0x0002 Monitor line 1. 0x0004 Monitor line 2. .. 0x000E Monitor line 7. 0x0000 A '0' on the monitored line indicates no link beat. 0x0080 A '1' on the monitored line indicates no link beat. Adding card support The first step for adding support is figuring out what the general purpose lines are use for. The most complete method is to follow the traces on the circuit board, but it's also possible to do this without opening up the machine. Several general purpose lines are almost always used for: 10baseT link beat (input) 100baseTx link beat (input) The following might also be provided as outputs: Enable 100baseTx transceiver Enable BNC transceiver Outputs we aren't concerned with, except to avoid mis-setting them, are Set 10mbps transceiver to loopback Set 100mbps transceiver to loopback Deducing which lines are used to detect link beat You'll need a method to generate both 10baseT and 100baseT link beat signals, and a way to monitor the CSR12 general purpose register to see which input lines change state when the cables are attached to the cards. Generating the link beat is best done with 10baseT and 100baseTx repeaters. It can also be done with a 10/100 transceiver that can be forced into a specific mode. Using an autosensing/autonegotiation link won't work, since it might switch speeds. It's easiest to use the tulip-diag program to report the value of CSR12, although the driver itself can be used instead: Configure your system to load the tulip driver as a module. Load the module with the option `debug=2` to get additional debugging information. Then configure the interface using a command such as `/sbin/ifconfig eth0 192.168.1.1`. The driver should report the current value of CSR12. Run `ifconfig eth0 down` before the next test. Check the value of CSR12 with both 10baseT and 100baseT signals hooked up until you are certain you have figured out which input lines are used to indicate the link beat signals. 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