Hi Stephen,
On Wed, 23 Apr 2014 10:08:49 -0600
Stephen Warren <swar...@wwwdotorg.org> wrote:
> 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.
I think you mentioned the following config:
config DEBUG_LL_INCLUDE
string
default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
default "debug/pl01x.S" if DEBUG_LL_UART_PL01X || DEBUG_UART_PL01X
default "debug/exynos.S" if DEBUG_EXYNOS_UART
default "debug/efm32.S" if DEBUG_LL_UART_EFM32
default "debug/icedcc.S" if DEBUG_ICEDCC
default "debug/imx.S" if DEBUG_IMX1_UART || \
DEBUG_IMX25_UART || \
DEBUG_IMX21_IMX27_UART || \
DEBUG_IMX31_UART || \
DEBUG_IMX35_UART || \
DEBUG_IMX50_UART || \
DEBUG_IMX51_UART || \
DEBUG_IMX53_UART ||\
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART
default "debug/msm.S" if DEBUG_MSM_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 ||
DEBUG_SIRFMARCO_UART1
default "debug/sti.S" if DEBUG_STI_UART
default "debug/tegra.S" if DEBUG_TEGRA_UART
default "debug/ux500.S" if DEBUG_UX500_UART
default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
default "debug/vf.S" if DEBUG_VF_UART
default "debug/vt8500.S" if DEBUG_VT8500_UART0
default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
default "mach/debug-macro.S"
Actually I did this in my first RFC series.
http://patchwork.ozlabs.org/patch/330796/
like this:
config SYS_CPU
default "mcf5227x" if MCF5227x
default "mcf523x" if MCF523x
default "mcf52x2" if MCF52x2 || MCF520x
default "mcf532x" if MCF532x || MCF5301x
default "mcf5445x" if MCF5441x || MCF5445x
default "mcf547x_8x" if MCF547x_8x
I think it works for sereval dozens of strings.
But I hesitate to apply the same approach to CONFIG_SYS_BOARD.
We have already hundreds of boards. It would be very dirty.
Best Regards
Masahiro Yamada
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
