[U-Boot-Users] Flash environment vs EEPROM environment

[Wolfgang Denk]

Dear Thomas,

in message <D9F0B2AD4531B0449D51C1F09199D484050E72 at mail.kom-saarbruecken.com> you wrote:
> 
> Yes, I know that this has been discussed recently and the recommendation
> is to store the environment in flash, but:

Indeed.

> - storing the environment in flash with redundancy means to spend 2 (128
> kB in our case) sectors for approx. 1 kB of environment data.

As long as you say "spend" (and not "waste") that's ok :-)

> - the problem described for EEPROM storage should also appear when
> storing other data in EEPROM's (e.g. SPD data etc.) and thus a proper

Indeed. It happened before.

> solution should be found for EEPROM storage.

Yes, machine should work, men should think, etc. In the  meantime  we
have to live with the current situation. The question is how reliable
your system has to be.

Note that even with perfect operation of the EEPROM you still  cannot
get  the  robustness you get with redundand flash sectors. Not unless
you have two EEPROM chips on your board for redundant storage, but  I
haven't seen this yet. And it would be painfully slow to boot, too.

> - The solution provided in common/soft_i2c.c sets the SDA line to 1 and
> issues 9 cycles on the SCL line. Is this an undefined I2C pattern

No, it's not undefined. It's well-defined as you just described.

> causing a reset on the I2C bus (which is not specified in the I2C
> specification)? Why is it not sufficient to issue a simple Start/Stop
> sequence on the bus?

Because the I2C controller may be in a state where  it  misinterprets
this; see "doc/I2C_Edge_Conditions".

> - Are there conditions known to cause similar effects with flash chips
> as described for EEPROM devices? Could power loss or similar conditions

No.

> when writing environment sectors cause a flash device to destroy other
> sectors than the just written one?

In theory yes. You could assume a  system  without  power  monitoring
where  the  power  is failing slowly so that at some point during the
brownout the CPU migth start executing  bogus  insructions,  or  that
some  bus  driver  corrupts  the  addresses  or data, or... In theory
anything can happen.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
		        -- Bertrand Russell, "Skeptical Essays", 1928