[U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files

[Stephen Warren]

On 05/16/2014 12:55 PM, Tom Rini wrote:
> Wading in here later than I had wanted to, sorry.
> 
> On Mon, Apr 28, 2014 at 06:39:33PM +0900, Masahiro Yamada wrote:
...
>> But, if people don't like this,
>> I can change this part as only one defconfig per board
>> in the next version.
>> (Instead, we may lose flexibility to some extent
>> because SPL and non-SPL will share the same defconfig.)
> 
> So this I believe answers what I was hoping which is that yes, down the
> line more things will be questions and less things selected, which means
> defconfig are more about providing config options.
> 
> And then yes, we need to re-evaluate what we do for SPL/TPL and see if
> really we can't just handle things with a user-selected CONFIG_SPL/TPL
> (for the just very different parts) and perhaps decouple these parts of
> the build.

A somewhat tangential thought:

I was recently trying to build a really tiny U-Boot.

I first tried building a regular main U-Boot, but to get a small enough
binary (256KB RAM total), I had to strip too much out to be useful.
Without doing that, the resultant run-time image was too large to allow
relocation; text+data+bss was more than half the size of my possible RAM
footprint.

So, I tried switching to building SPL instead, since SPL doesn't do
relocation. However, SPL is far too limited in terms of features and
APIs to allow the feature-set I want (I wanted device-mode USB, with
some custom protocol sitting on top, which I think currently requires
pulling in the host-mode EHCI stack, a malloc pool, etc.). I guess I
could go add a bunch more stuff to spl/Makefile to start fixing this,
but I started wondering exactly why I needed to do that.

I'd love to see CONFIG_SPL/CONFIG_TPL completely disappear. Instead, we
should just select all the features we want through Kconfig, and things
like CONFIG_DO_RELOCATION that the main U-Boot selects, and whatever SPL
currently does to minify itself, should be Kconfig options just like any
other. Does that seem reasonable?

For this part of the conversation, I'm completely ignoring whether we'd
then represent our current SPL and main U-Boot binaries via separate
user-visible defconfigs, sub-defconfigs pulled in as sub-builds by other
defconfigs, or some other means.