[U-Boot] [PATCH v3 00/45] Kconfig: Move CONFIG_SPL_..._SUPPORT to Kconfig

[Simon Glass <sjg@chromium.org>]

Hi Tom,

On 18 September 2016 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Sep 12, 2016 at 11:18:18PM -0600, Simon Glass wrote:
>
>> This series moves all the CONFIG_SPL_..._SUPPORT options to Kconfig and
>> fixes up existing boards to continue to build.
>>
>> It also adds a few small but useful features to moveconfig.
>>
>> There is existing work going on in this area, so some of these patches may
>> be superseded. It has taken me a while to get this building cleanly. But I
>> have run out of time so want to get this out.
>>
>> As mentioned on a recent thread [1] there is some confusion about whether an
>> option means enabling driver support or media support. Andrew's recent
>> series seems like a good vehicle to tidy that up. But I hope this series
>> will make it easier.
>>
>> NOTE: in the v2 series I have tried to use common things in Kconfig to
>> reduce the diffs in the defconfig files. This has helped a fair bit. But it
>> is very error-prone and time consuming. Also I have had to add some
>> exceptions (disabling an option in specific board configs). Overall it was
>> not a pleasant experience :-(
>>
>> There are a few strange features of this conversion. The main difficulty is
>> that some PowerPC boards do things like this in their board config file:
>>
>> This means that TPL reuses the SPL options. We can't support this in Kconfig
>> so I have added a small number of CONFIG_TPL_xxx_SUPPORT options to cope
>> with this. This made the conversion more painful than it should have been.
>>
>> A related issue is boards using a common header file and setting options only
>> for SPL:
>>
>> This is not noticed by moveconfig so we have to clean it up manually. Also
>> there are a few incorrect things where Kconfig options are set with #define:
>>
>> Finally, many defconfig files are not ordered correctly, resulting in larger
>> patches than we might like. It would be great to have a solution for this,
>> perhaps with buildman providing a warning. But it might slow down
>> development.
>>
>> The series is fully build-tested (for bisectability) and causes no failures
>> for the boards that already pass. The following boards fail for me at
>> present on mainline (which I have not yet looked at):
>>
>> 01: buildman
>>   blackfin:  +   cm-bf527 bf609-ezkit bf537-stamp
>>      sparc:  +   grsim grsim_leon2 gr_cpci_ax2000 gr_xc3s_1500 gr_ep2s60
>>      nios2:  +   10m50 3c120
>> microblaze:  +   microblaze-generic
>>   openrisc:  +   openrisc-generic
>>
>> [1] https://patchwork.ozlabs.org/patch/661511/
>
> This is not totally size neutral.  I've looked over the changes and in
> some cases, strings just get resized slightly, and, it happens.  In
> other cases, it comes down to the "fun" games I did on am335x to support
> network booting in SPL and the size constrains that can be run into
> there, along with just including extra stuff.  It all still links, so
> I'll clean up that config afterwards.

The latter is a funny case. I assumed something interesting was going
on but didn't dig into what.

It would be helpful if SoC maintainers would take a look at the
resulting defconfig files with their boards and see if some of the
variation could be removed. E.g. I suspect that some boards disable a
particular option for no particular reason. More uniformity (by
setting defaults in Kconfig however distasteful) will reduce the
defconfig size.

> --
> Tom