Wolfgang Denk wrote:
Dear Jerry Van Baren,
In message 49E32C3C.8090404@ge.com you wrote:
Since flash can change 1s to 0s, but cannot change them back, you could redefine the env storage to be <next><crc><env><NUL>[undefined] (note the added <next> at the start). By definition, the valid env's <next> == 0xFFFFFFFF. To write a new env, simply write the offset of [undefined] into the <next> location and then write a new env lump.
I see problems with this:
- it's incompatible with the current format, i. e. detection of existing old formats needs a special case which is something I always consider ugly.
True, although that is an issue only for upgrades to boards that have an existing env and that you want to use the new env method on. I would expect the special casing would not be excessively ugly and may not be necessary, depending on how important backward compatibility (board upgrading) is.
- it works only on NOR flash, not on any media that can be accessed only in blocks
Not true: the offset merely needs to be aligned to the next block in that case: <next><crc><env><NUL>FFFFFFFFFFFF <next><crc><env><NUL>[undefined] ^^^^ offset of ------------------> ^^^^ 0xFFFFFFFF
All flash that I can recall seeing allows at least a limited number of rewrites to a block (the limited number getting smaller on successive generations), so two writes to the env start block (once to write the new env, a second time to rewrite the 0xFFFFFFFF to point to the superceeding env). If the flash didn't support two writes, that would be a show-stopper. Due to how people use flash, I don't think the number will ever go to one write (IIRC, 4 is typical of current generation NAND).
- handling of redundant environment becomes a lot more complicated
I don't think so: it would be handled the same way as the primary env in a separate sector as is done currently. If you step through all of the primary env lumps and the last one has an invalid CRC, you fall back to the backup env and repeat the search.
BTW: what was the exact problem we were trying to solve? Saving the time it takes to erase one flash sector?
If we have to pay for this with introducing a new, incompatible environment format, and probably having to handle NOR flash and other storage media differently, I doubt if this is worth the effort.
That could very well be true.
Best regards,
Wolfgang Denk
Ditto, gvb