Hi Stephen,
> >>> diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig > >>> new file mode 100644 > >>> index 0000000..fbf00f3 > >>> --- /dev/null > >>> +++ b/configs/beaver_defconfig > >>> @@ -0,0 +1,10 @@ > >>> +CONFIG_SPL=y > >>> +CONFIG_ARM=y > >>> +CONFIG_SYS_CPU="armv7" > >>> +CONFIG_SOC_DIR=y > >>> +CONFIG_SYS_SOC="tegra30" > >>> +CONFIG_SYS_BOARD="beaver" > >>> +CONFIG_VENDOR_DIR=y > >>> +CONFIG_SYS_VENDOR="nvidia" > >>> +CONFIG_SYS_CONFIG_NAME="beaver" > >>> +CONFIG_BOARD_MAINTAINER="Tom Warren <twar...@nvidia.com>:Stephen Warren > >>> <swar...@nvidia.com>" > >> > >> This is odd; defconfig in the Linux kernel is for defining values for > >> user-editable configuration options. However, at least > >> CONFIG_BOARD_MAINTAINERS is a property of the board port, not something > >> the a user should be editing. > > > > In U-Boot, each board and its maintainer are tightly coupled. > > So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. > > I think you're completely missing my point. None of the information > contained in the defconfig files you posted is even *remotely* related > to what a defconfig file is. defconfig is for user-configurable > configuration of the software, not for core values that must be set up > in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. "make randconfig" or "make allyesconfig" will not work at all. > > I am following that concept. > > That's why I added maintainers information to defconfig files > > rather than keeping it in a seperated file. > > > > Anyway, this item is for open discussion. > > Do you have any idea instead of this? > > I don't think there's any need at all for a "defconfig" file here. > > Perhaps the solution is to simply name these files something other than > "defconfig", but rather something else that reflects what the content > really is. There is a plan to move user-editable macros to Kconfig. For example, CONFIG_BAUDRATE. Or someone might to disable CONFIG_CMD_* to reduce the binary size. We definitely need "defconfig". Renaming it to something else will break the Kconfig infrastructure. I believe the right way to reuse the Linux's Kconfig with minimum modification. > >> Other values in this file feel very odd > >> too. For example, I would expect selecting SYS_SOC=tegra30 it > >> automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... > > > > This is really really Tegra-specific matter. > > Absolutely not at all. > > Any board contains a specific SoC. Each specific SoC is a particular CPU > architecture and type, etc. In that case, all boards must have board/*/Kconfig to automatically select correct CONFIG_SYS_VENDOR, CONFIG_SYS_SOC, etc. Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
