Dear Kyle Moffett,
In message 1297467482-14864-5-git-send-email-Kyle.D.Moffett@boeing.com you wrote:
For our new board ports, we are programming the EEPROMs attached to our Intel 82571EB controllers from software (using U-Boot and Linux).
This code provides a helpful set of "e1000" subcommands for performing EEPROM manipulation on e1000 devices, including displaying a hex-dump, copying to and from main memory, and verifying/updating of the software checksum.
The following commands work for programming the EEPROM from USB: usb start fatload usb 0 $loadaddr 82571EB_No_Mgmt_Discrete-LOM.bin e1000 0 eeprom program $loadaddr 0 1024 e1000 0 eeprom checksum update
Please keep in mind that the Intel-provided .eep files are organized as 16-bit words. When converting them to binary form for programming you must byteswap each 16-bit word so that it is in little-endian form.
This means that when reading and writing words to the SPI EEPROM, the bit ordering for each word looks like this on the wire:
I don't like the idea of having this in the driver code itself. It is a separate function, which should be implemented in a separate source file.
Eventually this should not even be linked with U-Boot, but kept separate as lodable module, like eepro100_eeprom.c, smc911x_eeprom.c and smc91111_eeprom.c.
What do you think?
Best regards,
Wolfgang Denk