[U-Boot] [PATCH 4/5] e1000: New "e1000" commands for SPI EEPROM management

[Moffett, Kyle D]

On Apr 12, 2011, at 16:24, Wolfgang Denk wrote:
> In message <1297467482-14864-5-git-send-email-Kyle.D.Moffett at 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.

Hmm, there seem to be some fairly significant functionality differences
between this e1000 driver and those other EEPROM drivers.

In particular, those other eeprom drivers simply have a single hardcoded
I/O base address that they assume is properly mapped, IE:
>   struct eth_device dev;
>   dev.iobase = CONFIG_SMC911X_BASE;

That won't really work with the way the existing E1000 driver is set
up; it expects to run with full PCI device access using the standard
U-Boot PCI calls.  It seems to get very confused if you poke at the
hardware behind its back.

Also, I can't see any way to allow CONFIG_CMD_SPI to link against an
external "app" (the functionality provided by patch 5/5).

Finally, from an actual operational standpoint, this EEPROM driver is
designed to allow the user to program up to 64kB of information to the
E1000 EEPROM, including manageability firmware and other stuff; speed
and copy-to/from-memory operations are very important.

The other EEPROM "apps" only really support changing individual bytes
one-at-a-time and reprogramming the MAC address, which is insufficient
for initial hardware load.

If you agree then I will modify the patch to move the new code into a
separate e1000_eeprom.c file which is conditionally compiled, but
still linked into the main U-Boot image.

Thanks for your comments!

Cheers,
Kyle Moffett