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

[Heiko Schocher]

Hello Simon,

Am 25.08.2016 um 14:04 schrieb Simon Glass:
> Hi Heiko,
>
> On 24 August 2016 at 22:30, Heiko Schocher <hs at denx.de> wrote:
>> Hello Simon,
>>
>>
>> Am 24.08.2016 um 18:51 schrieb Simon Glass:
>>>
>>> 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.
>>>
>>> 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:
>>>
>>>    #ifdef CONFIG_TPL_BUILD
>>>    #define CONFIG_SPL_SERIAL_SUPPORT
>>>    #define CONFIG_SPL_ENV_SUPPORT
>>>    #else
>>>    #define CONFIG_SPL_SERIAL_SUPPORT
>>>    #endif
>>>
>>> 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:
>>>
>>>    #ifdef CONFIG_SPL_BUILD
>>>    #define CONFIG_SPL_SERIAL_SUPPORT
>>>    #endif
>>>
>>> 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:
>>>
>>>    #ifdef CONFIG_SPL_BUILD
>>>    #define CONFIG_SPL_DM
>>>    #endif
>>>
>>> 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):
>>
>>
>> Thanks!
>>
>> Hmm... may you want to check, if your patchserie does not
>> break any existing board? I wrote a tbot testcase for this, see:
>>
>> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
>
> Yes that sounds like a good idea. I have spent quite a few hours
> ensuring that the series breaks no boards (and bisectability) but not
> yet binary compatibility.
>
> At present buildman -K can provide information about config changes,
> but it would be more useful if it ignored the difference between
> defining an option to '1' and defining it to 'y'.

Do you have this patchseries in a public tree, from where I can
pull? So I may find time to start a test with tbot.

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany