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.griffin@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.