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@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!