[U-Boot] [PATCH v2 5/6] ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board.

[Tom Rini]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150716/14efecdc/attachment.sig>