[U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support

Masahiro Yamada yamada.m at jp.panasonic.com
Wed Apr 23 14:03:35 CEST 2014


Hi Wolfgang,


On Tue, 22 Apr 2014 14:13:44 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Masahiro,
> 
> In message <1398159826-29398-2-git-send-email-yamada.m at jp.panasonic.com> you wrote:
> > CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment
> > variables, "arch", "cpu", "board", etc. depending on
> > CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively.
> > 
> > We are discussing the introduction of Kconfig.
> > In our discussion, we found boolean CONFIG macros are more useful
> > in Kconfig context.
> > 
> > That is,
> > 
> > CONFIG_ARM=y
> > CONFIG_CPU_ARMv7=y
> > CONFIG_BOARD_HARMONY=y
> > CONFIG_VENDOR_NVIDIA=y
> > 
> > rather than
> > 
> > CONFIG_SYS_ARCH="arm"
> > CONFIG_SYS_CPU="armv7"
> > CONFIG_SYS_BOARD="harmony"
> > CONFIG_SYS_VENDOR="nvidia"
> 
> I understand your intention - but does this not mean that we lose all
> flexibility in assigning board and vendor names?  So far, we allow any
> kind of names, lowercase and uppercase and mixed.  Will we not lose
> this capability?  Also, we have '-' characters in a number of board
> names - would this not also cause trouble?
> 
> Finally, I don't see what your replacement code would be to create the
> set of environment settigns - and I think these are needed, as some
> user defined scripts are processing these?

The user who needs such environment setting can
add them by using CONFIG_EXTRA_ENV_SETTINGS.

For example,

#define CONFIG_EXTRA_ENV_SETTINGS \
   "arch=arm\0" \
   "cpu=armv7\0" \
   "soc=tegra20\0"

I am not sure this is acceptable.



Best Regards
Masahiro Yamada



More information about the U-Boot mailing list