On Mon, 2014-04-28 at 11:47 -0600, Stephen Warren wrote:
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).
It's special in that both configs are built and assembled into what looks to the user like one output image.
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.
Yes, that'd be nice.
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.
Why couldn't the makefile do this when asked to use a board's defconfig?
The user shouldn't need to know about the details of SPL or that there are separate sub-builds. Both seaboard and seaboard_spl would need to be built, not one or the other.
(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).
What arbitrary code do you want to run that can't be run in the config makefile target? There is MAKEALL for users that want a one-step build.
-Scott