[U-Boot] Question regarding NAND environment

[Peter Barada]

On 01/26/2012 12:27 PM, Scott Wood wrote:
> On 01/26/2012 11:05 AM, Peter Barada wrote:
>> I'm trying to have a robust environment stored in NAND, and three blocks
>> of space available to store it in.
>>
>> Looking at the REDUND code, I see it only keeps two copies of the
>> environment regardless of the amount of space available.  Instead I'm
>> looking to use CONFIG_ENV_RANGE to handle the extra blocks.
> CONFIG_ENV_RANGE and CONFIG_ENV_*_REDUND are orthogonal, not alternatives.
>
>> Can/does the code save multiple copies of the environment across the
>> three blocks, 
> No.  Its purpose is to provide room to skip blocks that are formally
> marked as bad.
>
> If you want REDUND with more than two copies, you'll have to modify the
> REDUND code to support that.
>
>> and can readenv read copies of the environment (skipping
>> bad blocks) until it finds one good environment?  I'm trying to prevent
>> any corruption from happening if (unlikely but possible) power fails
>> while saving the environment.
> Why are two copies insufficient for that?
Two copies are sufficient, if none of the blocks ever go bad.

To simplify things, suppose the environment is the same size as a block
and you have only two blocks (and two copies) to hold the environment. 
If one block goes bad then there is a window between when the one
remaining block is erased and written with the environment that if power
fails then there is no environment in NAND.

To solve this I can crank up the number of blocks to three which allows
one block to go bad and still at all times have one good copy of the
environment in NAND.  But looking at writeenv(), it stops as soon as
either nand_write fails, or one copy of the environment is written. So
it could make sense to modify writeenv to write as many copies of the
environment that fit into CONFIG_ENV_RANGE, and have readenv read out
copies and verify them until it finds one good one.

To prevent a "buried update", the order of reads/writes (by either
u-boot or u-boot-tools in Linux) would have to be in the same order. 
Then if power fails while writing, either no valid data was written
(while still having a copy of the previous good environment in a
following block of NAND), or at least one new copy is written and on the
next reboot u-boot will find it.

I guess what I'm proposing to is much like REDUND, but I think more
flexible...

-- 
Peter Barada
peter.barada at logicpd.com