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.sut...@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 -- Viprinet Europe GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49 6721 49030-0 Direct line/Durchwahl: +49 6721 49030-134 Fax: +49 6721 49030-109 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany Commercial register/Handelsregister: Amtsgericht Mainz HRB44090 CEO/Geschäftsführer: Simon Kissel _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
