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

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

[Thomas Schäfer]

Hello u-boot users,

We are in the state of porting u-boot to our PPC405 based custom board and have to decide whether to store the environment in flash or in a serial EEPROM.

Yes, I know that this has been discussed recently and the recommendation is to store the environment in flash, but:

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

- 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 solution should be found for EEPROM storage.

- 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 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?

- Are there conditions known to cause similar effects with flash chips as described for EEPROM devices? Could power loss or similar conditions when writing environment sectors cause a flash device to destroy other sectors than the just written one?

Any pointer/comments would be appreciated.

Best regards,

Thomas Sch?fer

____________________________________

Kontron Modular Computers GmbH

Konrad-Zuse-Str. 9
66115 Saarbr?cken

Tel.: + 49 (0)681 / 95916 - 203
Fax:  + 49 (0)681 / 95916 - 100
E-mail: thomas.schaefer at kontron.com 

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

[Rune Torgersen]

> From: u-boot-users-admin at lists.sourceforge.net 
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf 
> Of Thomas Sch?fer
> Sent: Tuesday, February 01, 2005 11:10

> - 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 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?

This has the effect of making sure that if a EEPROM (or other device) was in the middle of something when a reset occurred, it will get enough clocks to cycle through its state-machine to a point where it can detect a stop or abort. (24LC64 are notorious for this)
This is only possible to do using the soft i2c. If you are using a hardware I2C, you are SOL if the external device is in the middle of a data-transfer when a reset occurs, because it WILL hang the I2C bus. Only way to reset the I2c device is to use the method soft_i2c uses, or power cycle the device. 

And yes... I have seen this problem, on a PCI card with CPU on it that got reset by the host just as it was reading the onboard EEPROM. Locked the card up solid. Only way to recover was to turn the power off.

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

[Wolfgang Denk]

Dear Thomas,

in message <D9F0B2AD4531B0449D51C1F09199D484050E72@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

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

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Thomas,
> 
> in message <D9F0B2AD4531B0449D51C1F09199D484050E72@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.

[snip]

>>- 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

Flash corruption is more than in theory: proper hardware design is to 
have a power fail warning sufficient to allow a flash write cycle to 
complete before power completely fails and your software should not 
write to the flash when the power fail warning is active.

If you do a lot of flash erase/writing and glitch the power rapidly and 
repeatedly during the flash activity, you _will_ have corrupted flash at 
_unpredictable_ (i.e. not necessarily the block you were intending to 
write/erase) locations.  Guaranteed.  Want to see the scars :-)?

Fortunately, most people (a) don't write rapidly and repeatedly to 
flash, (b) have stable power supplies that don't glitch rapidly and 
repeatedly (large output filter capacitors and power supervisory chips 
are your friends!) and (c) flash operations are relatively fast making 
the window of vulnerability very short.

Thus people get away with not using a power fail warning because the 
probability of corruption is extremely small, not necessarily by design 
but rather by happy coincidence.

gvb

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

[Roger Larsson]

On Tuesday 01 February 2005 20.06, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > Dear Thomas,
> >
> > in message 
<D9F0B2AD4531B0449D51C1F09199D484050E72@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.
>
> [snip]
>
> >>- 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
>
> Flash corruption is more than in theory: proper hardware design is to
> have a power fail warning sufficient to allow a flash write cycle to
> complete before power completely fails and your software should not
> write to the flash when the power fail warning is active.

I assume this is true for all flash CHIPS and not only higher level
assemblies like Compact Flash (that I read can be destroyed if written
to when power fails)

/RogerL

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

[Jerry Van Baren]

Roger Larsson wrote:
> On Tuesday 01 February 2005 20.06, Jerry Van Baren wrote:
> 
>>Wolfgang Denk wrote:
>>
>>>Dear Thomas,
>>>
>>>in message 
> 
> <D9F0B2AD4531B0449D51C1F09199D484050E72@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.
>>
>>[snip]
>>
>>
>>>>- 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
>>
>>Flash corruption is more than in theory: proper hardware design is to
>>have a power fail warning sufficient to allow a flash write cycle to
>>complete before power completely fails and your software should not
>>write to the flash when the power fail warning is active.
> 
> 
> I assume this is true for all flash CHIPS and not only higher level
> assemblies like Compact Flash (that I read can be destroyed if written
> to when power fails)
> 
> /RogerL

Correct.  My experience is actually with bare flash chips (NAND and 
NOR).  Assemblies will inherit the problems (to the best of my 
knowledge).  Since most applications write rarely and diabolical power 
glitches happen even rarer (except in our labs where we have a 
diabolical glitch machine for testing :-), most people get away without 
taking special precautions (power failure warnings).

I've seen a CF marketing sheet (I forgot which manufacturer offhand) 
which bragged that their CF would not get corrupted if power were 
removed "unexpectedly", but in the fine print it stated that power had 
to be held up for some period of time (basically a write cycle time) 
after a write.  Of course, that requires a power failure warning ;-).

Always read the fine print :-).

Incidentally, I have never seen a bare flash chip be destroyed.  I 
believe what happens with CF et al. assemblies is that the metadata gets 
corrupted and the CF controller gets confused, turning it into a brick 
(well, more like a skipping stone).  I understand you can do a low level 
format to recover them.  A quick google search turned up:
   http://www.sandisk.com/retail/rescuepro.asp
   http://www.lc-tech.com/rescuepro.htm

gvb

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

[Wolfgang Denk]

In message <41FFD322.4030401@smiths-aerospace.com> you wrote:
> 
> If you do a lot of flash erase/writing and glitch the power rapidly and 
> repeatedly during the flash activity, you _will_ have corrupted flash at 
> _unpredictable_ (i.e. not necessarily the block you were intending to 
> write/erase) locations.  Guaranteed.  Want to see the scars :-)?

I know that this is true. But we don't discuss if this is possible at
all,  the  question  was  how  this  might  affect  U-Boot  and   the
envrionment storage.

Assuming that we use redundant flash sectors, than the worst thing to
happen is that one copy of the environment gets corrupted. This  will
leave you with the other, good copy.

You could say that with redundant flash sectors a write operation  to
the  environment  storage  in flash has transaction character: either
you will see the state before the write operation was started, or the
state after it has completed. I think we're pretty safe against  data
loss or corruption.

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
Repeat after me:
Usenet is not a word processor; it's a medium where aesthetics count.
Mozilla is not a newsreader; it's a web browser.
Windows is not an operating system; it's a GUI on a program loader.
         -- Tom Christiansen in <6bq0g5$lr4$2@csnews.cs.colorado.edu>

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

[Thomas Schäfer]

Hi,

Thanks to all for your comments. I think we will put environment to flash using redundant sectors... :-)

Regarding Rune's answer I checked the _i2c_bus_reset function in cpu/ppc4xx/i2c.c and found a reset sequence using the IIC Direct Control Register of the PPC4xx CPU. Functionality is the same as implemented in the common/soft_i2c.c module. This should prevent the error condition described in doc/I2C_Edge_Conditions, or am I missing something? (We still have to store SPD data et al. in EEPROM).

Best regards,

Thomas Sch?fer

____________________________________

Kontron Modular Computers GmbH

Konrad-Zuse-Str. 9
66115 Saarbr?cken

Tel.: + 49 (0)681 / 95916 - 203
Fax:  + 49 (0)681 / 95916 - 100
E-mail: thomas.schaefer at kontron.com