[U-Boot] [PATCH] fw_env: add NAND support

[Guennadi Liakhovetski]

On Tue, 2 Sep 2008, Wolfgang Denk wrote:

> > +		/*
> > +		 * If we are reading, we don't need the flag and the crc any
> > +		 * more, if we are writing, we will set them before writing out
> > +		 */
> 
> Note that this is a serious impairment compared to the  old  version.
> 
> The whole logic of writing the envrionment (and  especially  so  when
> redundancy  is  used)  is based on separate logic steps that are per-
> formed strictly sequentially, and only  when  the  previous  one  was
> successfully  completed.  This essential to maintain consistent data.
> For the redundant case that means:
> 
> 1) write the environment data to flash.
>    *After* this has completed, make the data valid by
> 2) writing the CRC checksum.
>    *After* this has completed, make this copy of the environment valid by
> 3) writing the valid flag to this copy.
>    *After* this has completed, make the other copy of the environment obsolete by
> 4) writing the obsolete flag to the other copy.
> 
> Your new implementation breaks this by writing out the  whole  buffer
> at  once.  This  is  not  a  good  ideas,  because you may end up ith
> situations that were impossible before, like having a valid flag byte
> in flash  even  though  the  environment  data  were  not  completely
> written.

Sorry, I still do not understand what bad can happen with this 
whole-image-at-once implementation. Yes, it may happen, that crc has been 
written, flag has been written, but the data has not completely been 
written. Then, you get a CRC error on reading. Just as if you were writing 
in portions and an error occurred when writing the data. Yes, the flag 
would have been different, with the previous approach you would still have 
the "redundant" flag set in the corrupted copy that you were trying to 
update and "active" in the other one. Writing the whole image at once you 
end up with two "active" flags. But this seems unimportant, because CRCs 
are checked before - at least in fw_env - so, in both cases you end up 
using the non-damaged copy.

If you were first setting the flag to "invalid, write in progress", then 
wrote the environment, then reset the flag to "valid, write completed 
successfully", then yes, writing per one write would be essentially 
different.

In short, I think, CRC provides sufficient protection of data integrity.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de