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

[Masahiro Yamada]

2016-08-20 0:29 GMT+09:00 Andrew F. Davis <afd at ti.com>:
> On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
>>
>>
>> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>>> Currently U-Boot proper has Kconfig options that enable the generation
>>> of U-Boot binaries that are capable of being booted from the selected
>>> boot media type. The same set of generation targets for SPL are assumed
>>> with various methods and config header hackery. On some platforms the
>>> options for SPL, such as load address, are dependent on boot type
>>> and cannot depend on boot image type selected for U-Boot proper.
>>> Add a Kconfig menu to select SPL boot image types, and populate it
>>> with the same media types as are already available for U-Boot proper.
>>> Uses of this option are added later.
>>>
>>> Signed-off-by: Andrew F. Davis <afd at ti.com>
>>> ---
>>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 69 insertions(+)
>>>
>>> diff --git a/common/Kconfig b/common/Kconfig
>>> index f594db5..90ba5b2 100644
>>> --- a/common/Kconfig
>>> +++ b/common/Kconfig
>>> @@ -156,6 +156,75 @@ config SPI_BOOT
>>>        booted via SPI flash. This is not a must, some SoCs need this,
>>>        somes not.
>>>
>>> +menu "SPL Boot media"
>>> +    depends on SPL
>>> +
>>> +config SPL_NOR_BOOT
>>> +    bool "Support for booting SPL from NOR flash"
>>> +    default n
>>
>> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
>>
>
> Nope, these simply enable the SPL to be built for being itself loaded
> from this media, for instance the SPL does not need to know how to load
> images over UART just because it itself was.
>
>> May be a dump question. Do you see any issue with using
>> SPL_<media>_SUPPORT config for the same purpose as SPL_<media>_BOOT
>> instead of creating a new defconfig?
>>
>
> Kind of the same answer as above, the idea is that _SUPPORT is for
> adding the ability to load images from a media type to the SPL, and
> _BOOT is to inform the make system to generate an SPL image that can be
> loaded from this media. This mirrors, for SPL, the same options that
> already exist for U-Boot proper.
>
> Now something that I had considered was using the U-Boot proper _BOOT
> options to determine what kinds of media the SPL should know how to load
> images from, but this becomes very complex and would led to
> misunderstandings of the options, like the one I correct in patch 8, so
> I have kept them independent of each other.
>


I do not see anything systematic for CONFIG_*_BOOT,
i.e., you can use it for any purpose.

Why don't you use the existing CONFIG_*_BOOT
for deciding the boot media for U-Boot proper, or SPL, or whatever.

If SPL is supported on your board, the U-Boot proper image
can have generic format, which makes it independent of a specific media.
Why do you need both CONFIG_*_BOOT and CONFIG_SPL_*_BOOT?



I do not want to see even the current "Boot media" menu.

http://patchwork.ozlabs.org/patch/661706/


Your patch is adding more.  :(




-- 
Best Regards
Masahiro Yamada