[U-Boot] [PATCH v2] mmc: fix env in mmc with redundant compile error

Tom Rini trini at ti.com
Thu May 16 01:48:46 CEST 2013


On Wed, May 15, 2013 at 05:31:30PM -0500, Andy Fleming wrote:

> On Tue, May 14, 2013 at 8:38 PM, Bo Shen <voice.shen at atmel.com> wrote:
> 
> > The commit d196bd8 (env_mmc: add support for redundant environment)
> > introduce the following compile error when enable redundant
> > environment support with MMC
> > ---8<---
> > env_mmc.c:149: error: 'env_t' has no member named 'flags'
> > env_mmc.c:248: error: 'env_t' has no member named 'flags'
> > env_mmc.c:248: error: 'env_t' has no member named 'flags'
> > env_mmc.c:250: error: 'env_t' has no member named 'flags'
> > env_mmc.c:250: error: 'env_t' has no member named 'flags'
> > env_mmc.c:252: error: 'env_t' has no member named 'flags'
> > env_mmc.c:252: error: 'env_t' has no member named 'flags'
> > env_mmc.c:254: error: 'env_t' has no member named 'flags'
> > env_mmc.c:254: error: 'env_t' has no member named 'flags'
> > env_mmc.c:267: error: 'env_t' has no member named 'flags'
> > make[1]: *** [env_mmc.o] Error 1
> > --->8---
> >
> > Add this patch to fix it
> >
> > Signed-off-by: Bo Shen <voice.shen at atmel.com>
> > Reviewed-by: Michael Heimpold <mhei at heimpold.de>
> > ---
> > Changes in v2:
> >   - s/reduandant/redundant in commit message
> >
> >  include/environment.h |    6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/include/environment.h b/include/environment.h
> > index 4c6a37b..460ccb4 100644
> > --- a/include/environment.h
> > +++ b/include/environment.h
> > @@ -75,6 +75,12 @@
> >  # endif
> >  #endif /* CONFIG_ENV_IS_IN_FLASH */
> >
> > +#if defined(CONFIG_ENV_IS_IN_MMC)
> > +# ifdef CONFIG_ENV_OFFSET_REDUND
> > +#  define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> > +# endif
> > +#endif
> > +
> >
> 
> 
> If CONFIG_SYS_REDUNDAND_ENVIRONMENT must be defined when
> CONFIG_ENV_OFFSET_REDUND is defined, then isn't it, itself, redundant?
> 
> Further, if defining CONFIG_ENV_OFFSET_REDUND is enough to make env_mmc.c
> access a variable that is protected by CONFIG_SYS_REDUNDAND_ENVIRONMENT,
> then doesn't that mean that those accesses are improperly protected (or
> that the "flags" field is)?
> 
> It looks like we keep patching over this problem, rather than fixing it....
> 
> Andy
> 
> PS - Is there a reason it's REDUNDAND, and not REDUNDANT?

The answer for all of the above is, history.  A problem is that we need
CONFIG_SYS_REDUNDAND_ENVIRONMENT if any of:
- CONFIG_ENV_OFFSET_REDUND
- CONFIG_ENV_ADDR_REDUND
- CONFIG_ENV_UBI_VOLUME_REDUND

are set.  And the config variable is used in both common/env_ubi.c
(which would be easy to switch to UBI_VOLUME_REDUND) and tools/envcrc.c,
which would be harder.  And I don't think we can just whack flags as
being always on as that would invalidate peoples environment, from a
quick peek at things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130515/aba1b637/attachment.pgp>


More information about the U-Boot mailing list