[U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL__SUPPORT as Kconfig option

Andrew F. Davis
2016-08-23T15:02:59Z

On 08/23/2016 01:08 AM, Masahiro Yamada wrote:
> 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
>> 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@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.
>> +
>> +config SPL_SPI_SUPPORT
>> + bool "SPL Support for loading next stage from SPI flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from SPI flash.
>> +
>> +config SPL_USB_SUPPORT
>> + bool "SPL Support for loading next stage from USB"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from a USB device.
>> +
>> +config SPL_SATA_SUPPORT
>> + bool "SPL Support for loading next stage from SATA"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from a SATA device.
>> +
>> +config SPL_NOR_SUPPORT
>> + bool "SPL Support for loading next stage from NOR flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NOR flash.
>> +
>> +config SPL_NAND_SUPPORT
>> + bool "SPL Support for loading next stage from NAND flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NAND flash.
>> +
>> +config SPL_ONENAND_SUPPORT
>> + bool "SPL Support for loading next stage from ONENAND"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from ONENAND.
>> +
>> +config SPL_NET_SUPPORT
>> + bool "SPL Support for loading next stage from NET"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NET.
>
>
>
> Historically, config options for SPL build were named
> in the format of CONFIG_SPL_*_SUPPORT,
> but the suffix "_SUPPORT" was not adding anything
> except making the macro name longer, in my opinion.
>
> New options such as CONFIG_SPL_CLK, CONFIG_SPL_PINCTRL,
> only use SPL_ prefix because this naming scheme
> can exploit CONFIG_IS_ENABLED() macro.
>
>
> Then, I was hit by this question:
>
> Given that SPL exists for loading the next stage image,
> "SPL Support for loading next stage from SD/MMC/eMMC"
> (from the Kconfig prompt of this patch) is nearly equal to
> "Enable MMC driver support for SPL".
>
>
>
> SPL_MMC_SUPPORT in common/spl/Kconfig (for loading image from MMC)
> SPL_MMC in drivers/mmc/Kconfig (for enabling MMC driver for SPL)
> it would make it tedious to use if we added both of them.
> Theoretically, we can control them independently if we want, but
> common/spl/spl_*.c are almost small entry stubs.
>

We could have the *_SUPPORT option select the appropriate driver config
options. This way the stubs and the drivers would be enabled with one
option, all in one place. Right now you can build the driver into SPL
but not enable the SPL stub that uses it is, making for a rather useless
situation.

Andrew

>
> Tom,
> Which do you think a better place for those options?
> (SPL_YMODEM has no good directory, though)
>
>
>
>
>