Dear Kyle Moffett, In message <1297467482-14864-5-git-send-email-kyle.d.moff...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The rule on staying alive as a program manager is to give 'em a num- ber or give 'em a date, but never give 'em both at once. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
