On 04/28/2014 03:39 AM, Masahiro Yamada wrote:
On Thu, 24 Apr 2014 14:36:33 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
diff --git a/configs/seaboard_defconfig b/configs/seaboard_defconfig new file mode 100644 index 0000000..88819b9 --- /dev/null +++ b/configs/seaboard_defconfig @@ -0,0 +1,3 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_TARGET_SEABOARD=y
diff --git a/configs/spl/seaboard_defconfig b/configs/spl/seaboard_defconfig new file mode 100644 index 0000000..bc3eab4 --- /dev/null +++ b/configs/spl/seaboard_defconfig @@ -0,0 +1,2 @@ +CONFIG_ARM=y +CONFIG_TARGET_SEABOARD=y
This definitely feels wrong. We shouldn't need to repeat the content of these files twice with/without CONFIG_SPL=y.
Should SPL/non-SPL be two build targets that get built when you ask to build for Seaboard, not two entirely unrelated defconfig files?
This is another item worth discussion.
The idea in my mind is to not treat SPL and TPL as special cases. (This is an idea proposed by Simon.)
I was thinking of handling Non-SPL, SPL, TPL as generic images.
Currently, C sources and Makefiles are really dirty because of ifdef CONFIG_SPL_BUILD everywhere.
But, roughly, the difference among them is how many CONFIG_ macros are enabled.
Non-SPL: enable hush command line, many useful commands, many drivers, net work feature etc. But the image size is big.
SPL: disable hush command line & all commands enable only some drivers enough for loading another image. The image size is small.
So, in future, many user ediatable settings will be moved to Kconfig. And then,
config/seaboard_defconfig will include CONFIG_SYS_HUSH_PARSER=y CONFIG_CMD_FOO=y CONFIG_CMD_BAR=y ...
but config/spl/seaboard_defconfig will disable most of them.
I guess the main issue I see here is that all the HW-configuration needs to be repeated in seaboard_defconfig and spl/seaboard_defconfig.
(As an aside, if there's nothing special about SPL-vs-not and they're just different builds of U-Boot, why put the SPL configurations into a special-case sub-directory, why not name them seaboard_spl_defconfig and seaboard_defconfig, and put them in the same configs directory).
Can we allow one defconfig to include or inherit from another? I know that ChromeOS stores kernel defconfigs in "split configs" that build upon each-other. Probably, this feature comes from elsewhere, and we could just crib the config split/combine script for U-Boot's use. To make this work, we'd probably need the user to run something like:
./build-u-boot seaboard or: ./build-u-boot seaboard_spl
... rather than running make directly, so that script could generate the .config from a set of defconfigs, and then invoke make.
(as an aside, having the user run a script to build rather than make directly gives us a huge amount more flexibility to add run arbitrary code to set up the build process before invoking make. I've found this kind of thing extremely useful in the past on other projects).
This would allow us to create something like:
file: tegra20_soc_config System is ARM ...
file: seaboard_board_config: include tegra20_soc_config Main UART is UARTD # some boards use UART A, etc. Enable UART support DT filename is tegra20-seaboard.dtb ...
file: seaboard_defconfig include seaboard_board_config Enable a whole slew of options like shell, commands, MMC drivers, USB, ...
file: seaboard_spl_defconfig include seaboard_board_config Enable a few SPL-specific options, if any