[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/21/2016 02:33 PM, Tom Rini wrote:
> On Sun, Aug 21, 2016 at 02:12:03PM -0500, Andrew F. Davis wrote:
>> On 08/21/2016 01:50 PM, Tom Rini wrote:
>>> On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote:
>>>> On 08/19/2016 02:54 PM, Tom Rini wrote:
>>>>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
>>>>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
>>>>>>> Hello Andrew,
>>>>>>>
>>>>>>> first thanks for this series!
>>>>>>>
>>>>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>>>>>>>> Create a new Kconfig file to contain SPL boot media loading support
>>>>>>>> options as we begin moving these to the Kconfig system and out of header
>>>>>>>> files. Initially add new configs for all the existing boot media types,
>>>>>>>> giving them the same definition name as before to allow compatibility
>>>>>>>> with systems not yet using Kconfig.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew F. Davis <afd at ti.com>
>>>>>>>> ---
>>>>>>>>   common/Kconfig     |  7 +++++++
>>>>>>>>   common/spl/Kconfig | 54
>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>   2 files changed, 61 insertions(+)
>>>>>>>>   create mode 100644 common/spl/Kconfig
>>>>>>>>
>>>>>>>> diff --git a/common/Kconfig b/common/Kconfig
>>>>>>>> index 46e7173..f594db5 100644
>>>>>>>> --- a/common/Kconfig
>>>>>>>> +++ b/common/Kconfig
>>>>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT
>>>>>>>>         booted via SPI flash. This is not a must, some SoCs need this,
>>>>>>>>         somes not.
>>>>>>>>
>>>>>>>> +menu "SPL Media Loading Support"
>>>>>>>> +    depends on SPL
>>>>>>>> +
>>>>>>>> +source "common/spl/Kconfig"
>>>>>>>> +
>>>>>>>> +endmenu
>>>>>>>> +
>>>>>>>>   endmenu
>>>>>>>>
>>>>>>>>   config BOOTDELAY
>>>>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..788ca14
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/common/spl/Kconfig
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +config SPL_YMODEM_SUPPORT
>>>>>>>> +    depends on SPL
>>>>>>>> +    bool "SPL Support for loading next stage from UART"
>>>>>>>> +    help
>>>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>>>> +      over a UART line using the x/y/z/modem protocol.
>>>>>>>> +
>>>>>>>> +config SPL_MMC_SUPPORT
>>>>>>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
>>>>>>>> +    help
>>>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>>>> +      from an SD/MMC/eMMC device.
>>>>>>>
>>>>>>> Hmm.. why do you not move, for existing board configs, which use
>>>>>>> this symbols, them into their defconfigs? There is the great
>>>>>>> script from Masahiro
>>>>>>>
>>>>>>> u-boot:tools/moveconfig.py
>>>>>>>
>>>>>>> which should do the most things for you ... 
>>>>>>
>>>>>> Maybe I'm not understanding this script but after getting it to run it
>>>>>> doesn't seem to find any uses of the config, I'm not sure this works
>>>>>> with SPL configs, as the check looks only at the non-SPL build case as
>>>>>> far as I can tell.
>>>>>
>>>>> Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
>>>>>
>>>>
>>>> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
>>>> Makefile, this way it will pick up SPL_ defines that are blocked of by
>>>> conditionals for CONFIG_SPL_BUILD.
>>>>
>>>> Anyway the bigger problem is that some boards conditionally define an
>>>> option based on what other configs are enabled, we don't have this kind
>>>> of thing in Kconfig, at least not at the board level as far as I know.
>>>> (Select could work, but it would end up with a lot of conditionals per
>>>> board supported)
>>>
>>> I think the problem is that we have some "soft" dependencies here.  ie I
>>> think that when I was making am335x_evm.h work for all of the various
>>> possible board and feature combos that were desired I took some
>>> short-cuts to say that A means lets grab B and C.  I think it's
>>> perfectly reasonable that in moving to Kconfig we start out by getting
>>> everything into Kconfig and worry about getting all of the select /
>>> depends statements right as the second step.  So the defconfigs might
>>> start out a bit fuller and we'll get options removed from them as the
>>> Kconfig logic improves.
>>>
>>
>> If this is okay then I'll post a series with all these cleanups and the
>> config options moved. I believe they don't now make any changes to the
>> build output of any board (at lease according to buildman).
> 
> With sizechecks enabled?  You may way to look at the tbot test that
> Heiko got setup after the last problematic Kconfig migration:
> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
> 
>> The patch for moving SPL_TEXT_BASE will probably have to be dropped as
>> it breaks a couple old powerpc boards for some strange reason (they look
>> like they depend on SPL_TEXT_BASE being unset, and giving it even a
>> default value breaks build for them) and I don't have any time to look
>> into how the build works on those. So I will depend on the
>> ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL
>> address in Kconfig like we do in AM43xx boards for now.
> 
> OK. Can you do it as an RFC at the end of the series?  I'll try and take
> a look at fixing that one up.  Thanks!
> 

Sure, this works well for me, should have v2 ready this afternoon.

Thanks,
Andrew