On Thu, Jul 16, 2015 at 08:28:03AM -0500, Rob Herring wrote: > On Wed, Jul 15, 2015 at 7:41 PM, Peter Griffin <peter.grif...@linaro.org> > wrote: [snip] > >> > +#define CONFIG_ENV_OFFSET 0x0 > >> > +#define CONFIG_ENV_SIZE 0x1000 > >> > +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + > >> > CONFIG_ENV_SIZE) > >> > +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT > >> > >> Is redundant env necessary? It seems like this was more for raw NAND > >> and shouldn't really be needed for MMC. > > > > README file documents it as being valid for CONFIG_ENV_IS_IN_MMC, and a > > bunch of boards > > declare it with their CONFIG_ENV_IS_IN_MMC such as omap5_uevm.h, > > dra7xx_evm.h, > > am335x_evm.h. Whilst using managed NAND should be more reliable, I think it > > is still used in case there is a power failure whilst issuing 'saveenv'. > > Perhaps a bunch of cut and paste. I'd guess there are many more > platforms that use MMC and don't enable redundant.
No, we turn it on, on purpose, out of a certain level of paranoia (and for ref boards like those, showing everything one could do, let $company and their experts argue of which failure possibilities are the important ones). > > Anyways with moving to CONFIG_ENV_IS_IN_FAT I won't need it anymore so it > > will be > > removed in V3. > > Storing in FAT probably only increases your chance of failure from > power failure. :) True but IMHO env in FAT is the most friendly option for a community board. "Broke your ENV? Stick the SD card in your PC, delete .." "Here, take a look at my env, copy this file ..." and all that. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
