Scott,
On Thu, Dec 06, 2012 at 12:18:39PM -0600, Scott Wood wrote:
On 11/28/2012 03:06:00 PM, Phil Sutter wrote:
Hi,
On Tue, Nov 27, 2012 at 04:04:15PM -0600, Scott Wood wrote:
On 11/21/2012 06:59:19 AM, Phil Sutter wrote:
Without this patch, when the currently chosen environment to be written has bad blocks, saveenv fails completely. Instead, when there is redundant environment fall back to the other copy. Environment
reading
needs no adjustment, as the fallback logic for incomplete writes applies to this case as well.
Signed-off-by: Phil Sutter phil.sutter@viprinet.com
Isn't this what CONFIG_ENV_RANGE is supposed to deal with?
Yes, that is more or less what is supposed to help for cases like this. But given the fact that CONFIG_ENV_RANGE needs to span multiple erase pages which in our case are 128k in size, this is quite a deal. Especially since one needs to have multiple pages for both normal and redundant environment to be really sure.
And *that* is what CONFIG_ENV_OFFSET_OOB is supposed to deal with. :-)
Good to know, I already wondered what exactly this option is there for.
Though at the moment redundant environment is not supported with CONFIG_ENV_OFFSET_OOB.
I will have a look at it now, because that could be an elegant solution for both of us I think.
But, we already have a fixed hashmap in field, so using CONFIG_ENV_RANGE is simply no option.
That's relevant to what you put in your product, but it shouldn't be the basis of how mainline U-Boot does things for all boards.
Yes, of course. That was merely me explaining myself, not so much of a real point in matters of what should go mainline and what not.
Redundant environment is to deal with other problems such as a power failure during saveenv. If you just fall back to the other copy, you're silently losing the redundancy.
The alternative to silently losing redundancy in case one of the blocks in either normal or redundant env areas turns bad is to not being able to save the environment at all anymore. I'd prefer dropping the redundancy but still having a working system then. ;)
Another alternative is to noisily lose redundancy.
Would that be an acceptable alternative from your point of view? Having CONFIG_ENV_OFFSET_OOB in mind, there may be situations where all blocks of either one of the redundant environments get bad (quite artificial, I know). Losing redundancy in exchange for keeping env writeability could still be an option then. What do you think?
Best wishes,
Phil Sutter Software Engineer