Hi all again!

I've finally managed to bring my NIC back to life by doing some very ugly
hacks to the fxp driver to completely rewrite the EEPROM with 'sane' values.
The NIC now works and the Intel diagnostics no longer complains about a
faulty EEPROM.

For others in the same situation, and the fxp driver maintainer:


These docs contain valuable information:

Intel® 82801EB I/O Controller Hub 5 (ICH5) and Intel® 82801ER I/O Controller
Hub 5 R (ICH5R) Datasheet
http://www.intel.com/design/chipsets/datashts/252516.htm

82562EZ/82551ER/82541ER Combined Footprint LOM Design Guide
http://www.intel.com/design/network/applnots/ap456.pdf


Intel® 82801EB I/O Controller Hub 5 (ICH5) and Intel® 82801ER I/O Controller
Hub 5 R (ICH5R) Datasheet:
On page 276, section 7.1.2 the document states the following:

>DID-Device Identification Register
>(LAN Controller-B1:D8:F0)
>
>Offset Address: 02-03h Attribute: RO
>Default Value: 1051h Size: 16 bits
>
>Bit Description
>15:0 Vendor ID - RO. This is a 16-bit value assigned to Intel.
>
>Bit Description
>15:0
>Device ID - RO. This is a 16-bit value assigned to the Intel® ICH5
integrated LAN controller.
>1. If the EEPROM is not present (or not properly programmed), reads to the
Device ID return the
>default value of 1051h.
>2. If the EEPROM is present (and properly programmed) and if the value of
Word 23h is not
>0000h or FFFFh, the Device ID is loaded from the EEPROM, Word 23h after the
hardware
>reset. (See Section 7.1.14 - SID, Subsystem ID of LAN controller for
detail)

This I believe is the explanation why the NIC changes it's PCI id to 0x1051
after the "disabling dynamic standby mode" hack. That is, the EEPROM is not
properly programmed, and thus the LAN controller assumes the default PCI ID
of 0x1051 (instead of whatever used to be the correct one).

82562EZ/82551ER/82541ER Combined Footprint LOM Design Guide
On page 27, section 5.3 there is an EEPROM map and example EEPROM image for
the 82562EZ chip. I never found anything like this for the 82562ET, which I
have, so I hoped that the info for the EZ-variant would also work for the ET
(which it seems to do).

What I did with this information is I took the example EEPROM image and
filled in the missing information (MAC address, changed PCI ID to 1050 from
the example 1039, filled in the correct subsystem device id and vendor and
calculated the checksum). MAC address, subsystem device ID and vendor ID
information was recovered from the Windows registry. The checksum was
calculated using the fxp_eeprom_update_cksum. The 0xbaba method of
calculating the checksum seems to be correct also for the 82562 controllers.
This EEPROM image was then hacked into the /sys/dev/ic/i82557.c file and
compiled into a custom "run once" NetBSD kernel.


Now If you remember my last posting, my first attempt was to make a custom
boot floppy which dumped the NIC eeprom to the screen, and almost every word
in the EEPROM was 0xFFFF, with the occasional one being 0x0000. Why was the
EEPROM 'cleared' by the "disabling dynamic standby mode" thing? I don't
know, but maybe the change made to offset 0x0A triggered some kind of "clear
the EEPROM on reboot" function of the LAN controller, instead of the wanted
"disable dynamic standby mode".

/ Peter Fors