[U-Boot-Users] Flash environment vs EEPROM environment
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@kontron.com
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
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
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
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
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
participants (4)
-
Jerry Van Baren -
Roger Larsson -
Thomas Schäfer -
Wolfgang Denk