[vortex] Mini PCI - no link

Dave Dribin dave-ml@dribin.org
Thu Jun 20 17:45:01 2002


BTW, I'm not sure of the relationship between the kernel and Scyld for
the current 3c59x driver (are they developed independently, or does
the kernel take periodic patches from Scyld?).  If this is not the
right list, please let me know and I will take my questions to the
kernel list.

I've gathered some more info on my problem.  While using the test
vortext driver (v0.99W), the MAC address is incorrect:

------------------------------------------------------------------------
% ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:AA:00:AA:00:AA  
          inet addr:10.3.1.94  Bcast:10.3.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:13
          collisions:0 txqueuelen:100 
          Interrupt:9 Base address:0x1800 
------------------------------------------------------------------------

However the vortex-diag tool reports it correctly:

------------------------------------------------------------------------
% sudo ./vortex-diag -ee
vortex-diag.c:v2.06 4/18/2002 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c566 Laptop Tornado adapter at 0x1800.
EEPROM format 64x16, configuration table at offset 0x30:
    00: 2978 6056 0040 8060 0040 0000 0000 0080
      ...
  0x10: 0000 0000 0000 0000 0000 0000 10b7 6556
  0x18: 0000 0000 0000 0000 0000 0000 0000 0a0a
  0x20: ff29 2829 0008 0000 0000 0000 0000 0000
  0x28: 0000 ff01 0000 0000 0000 0000 0000 0000
  0x30: 0004 7651 2e9c 6056 0061 0009 0000 6d50
  0x38: 2970 0009 0004 7651 2e9c 0010 0000 00aa

 The word-wide EEPROM checksum is 0xf3c5.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
 The CardBus product ID is 2978 6056.
 3Com Node Address 00:04:76:51:2E:9C (used as a unique ID only).
 OEM Station address 00:04:76:51:2E:9C (used as the ethernet address).
  Device ID 6056,  Manufacturer ID 6d50.
  Manufacture date (MM/DD/YYYY) 3/1/2000, division	, product .
  No BIOS ROM is present.
 Options: negotiated duplex, link beat required.
  Vortex format checksum is incorrect (0089 vs. 0000).
  Cyclone format checksum is incorrect (0x89 vs. 00).
  Hurricane format checksum is incorrect (0x89 vs. 00).
------------------------------------------------------------------------

So the driver is not reading the EEPROM correctly.  I did some poking
around in the code and found the kernel's driver reads the EEPROM
differently than the Scyld driver.

Here's the kernel's EEPROM read in vortex_probe1(), note that
EEPROM_OFFSET is set for my card:

------------------------------------------------------------------------
                int base;

                if (vci->drv_flags & EEPROM_8BIT)
                        base = 0x230;
                else if (vci->drv_flags & EEPROM_OFFSET)
                        base = EEPROM_Read + 0x30;
                else
                        base = EEPROM_Read;

                for (i = 0; i < 0x40; i++) {
                        int timer;
                        outw(base + i, ioaddr + Wn0EepromCmd);
------------------------------------------------------------------------

Here's the Scyld's EEPROM read:

------------------------------------------------------------------------
        for (i = 0; i < 0x40; i++) {
                int timer;
                outw((drv_flags & EEPROM_8BIT ? 0x230 : EEPROM_Read) + i,
                          ioaddr + Wn0EepromCmd);
------------------------------------------------------------------------

It looks like the kernel's read is adding an extra 0x30 to the offset
for my card where as the Scyld's driver is not.  Just for grins, I
modified the test driver to do the following:

------------------------------------------------------------------------
        for (i = 0; i < 0x40; i++) {
                int timer;
                outw((EEPROM_Read + 0x30) + i,
                          ioaddr + Wn0EepromCmd);
------------------------------------------------------------------------

Sure enough, the driver now reads the MAC address correctly, however,
my original problem (no link light) still exists.  Can anyone offer
any help here?  I'm more than willing to hack the code, but I'm really
flying blind at the moment.  I imagine this is a really simple fix,
just need to know where. :)

-Dave