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:
- write the environment data to flash. *After* this has completed, make the data valid by
- writing the CRC checksum. *After* this has completed, make this copy of the environment valid by
- writing the valid flag to this copy. *After* this has completed, make the other copy of the environment obsolete by
- 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@denx.de