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 twarren@nvidia.com:Stephen Warren swarren@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