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

[Andrew F. Davis]

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).

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.

Thanks,
Andrew