[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