[vortex] The mysteries of on-chip MII.

[Bill Cattey]

New facts that I did not know was significant until now:

We are using Etherboot to install systems.
I just found out a little while ago that the etherboot 3c90x driver we
have been using takes it upon itself to set EEProm location 0x000d to
0x0160.
This change ALL BY ITSELF is enough to cause failure to identify MII's
and mis-negotiation!

EEPROM contents before Etherboot is run:

 0x000: 00b0 d0c9 ba60 9200 00ca 0000 0000 6d50
 0x008: 2940 0001 00b0 d0c9 ba60 8010 0000 00aa
 0x010: 72a2 0000 0000 0180 0000 0004 0000 1028
 0x018: 00be 000a 0000 6300 ff68 6868 0000 0024
 0x020: 00ee 1030 70f0 0000 0000 0000 0000 0000
 0x028: 0000 0000 0000 0000 0000 0000 0000 0000
 0x030: 0000 0000 ffff ffff ffff ffff ffff ffff
 0x038: ffff ffff ffff ffff ffff ffff ffff ffff
 The word-wide EEPROM checksum is 0x93d1.

After:

 0x000: 00b0 d0c9 ba60 9200 00ca 0000 0000 6d50
 0x008: 2940 0001 00b0 d0c9 ba60 8010 0000 00aa
 0x010: 72a2 0000 0000 0160 0000 0004 0000 1028
 0x018: 00be 000a 0000 6300 ff68 6868 0000 0024
 0x020: 00de 1030 70f0 0000 0000 0000 0000 0000
 0x028: 0000 0000 0000 0000 0000 0000 0000 0000
 0x030: 0000 0000 ffff ffff ffff ffff ffff ffff
 0x038: ffff ffff ffff ffff ffff ffff ffff ffff
 The word-wide EEPROM checksum is 0x93a1.

As you see the ONLY difference is:

Address	Beforeval	Afterval
0x000d	0x0180	0x0160
0x0020	0x00ee	0x00de

So this is something we did to ourselves but did not know we were doing
to ourselves!  We discovered the problem when someone with a windows
system that was doing PXE booting ran just the etherboot phase of our
installed, and could no longer PXE boot because his system complained of
problems with Ethernet.

So now I've got to kick off some investigation at our end with regards
to Etherboot.  We did not know until today that it was toxic!

QUESTION:  What exactly is being changed when the EEPROM gets
0x000d changed from 0x0180 to 0x0160?

I will follow up in a subsequent message with details on testing I've done
as per your previous reply.

-wdc