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@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 bootloaderover 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 bootloaderfrom 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.