[U-Boot-Users] why eeprom vs flash

[David Hawkins]

>> So, as the designer, its up to you. But keep in mind that
>> you want to make it hard for a customer to screw up, so
>> a separate EEPROM could be a good choice.
> 
> In many cases it ain't. I've seen many board which lost their  EEPROM
> contents,  typically because of edge condition problems as documented
> in the file mentioned before - a poor power supply with too slow rise
> times of the voltages makes an excellent test case. I know of systems
> where it blows the EEPROM content in 2 out of 3 boot cycles :-(

Interesting failure mode.

In the case of say the MPC8349EA, it can use an I2C EEPROM as
the boot sequencer. So if a board design really needed to
use that mode, one would need to pay attention to the
above issue - independently of whether this same EEPROM was
used to store MAC addresses or serial numbers, etc.

An example EEPROM for the boot sequencer would be the AT24C512B.
Looking at its data sheet, there is a RESET MEMORY sequence
that could be used by the processor every time it booted
to ensure that the EEPROM was not left in a write-state.
I doubt the boot sequencer does this, so that would only
be a solution for storage of the environment in the EEPROM.
A better solution, is that the part also has a write-protect
pin, which can be controlled by a GPIO. If the GPIO is
tri-stated on power-up (likely), then a pull-up on the
pin can ensure that the part can not be written to
in error.

How slow is 'too slow' for a power-supply rise time?
(doc/I2C_Edge_Conditions doesn't mention).

To ensure correct power-supply sequencing, I use hot-swap
controllers (on cPCI power supply inputs), dc-to-dc converters
with programmable turn on times and slew-rates (for PPC/FPGA
core voltages, and DDR voltages), and linear regulators with
slew-rate controls. I've got most of them set to about 5-10ms.
The PowerPC docs state it can handle about 20ms between
all supplies, while the FPGAs want under 100ms, with
monotonic ramps on them all.

I doubt that I'll see this issue, but its an interesting
problem to be aware of.

Cheers,
Dave

PS. If anyone is interested, the power supply design notes,
and board design is here:
http://www.ovro.caltech.edu/~dwh/carma_board/