
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.