On 04/23/2014 06:03 AM, Masahiro Yamada wrote: > On Tue, 22 Apr 2014 14:13:44 +0200 > Wolfgang Denk <w...@denx.de> wrote: >> In message <1398159826-29398-2-git-send-email-yamad...@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.
Right now, we get the values set up automatically for free. It seems like a regression to force the board maintainer to set these all up manually instead. Kconfig supports string variables. The Linux kernel stores the ARM debug_ll include filename in one for example. Perhaps using that technique would resolve the issue. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
