[U-Boot] What is the correct way to configure SPL options?
Hi All
My understanding of the way SPL is intended to be configured is:
(a) You have one config file for both SPL and u-boot. (b) SPL features are selected via SPL-specific options.
I have a need to build SPL with MMC/FAT support, but I don't want u-boot to have MMC/FAT support.
I do however see that quite a few SPL feature selections don't use SPL config definitions though which would seem to violate (b) above.
eg.drivers/mmc/Makefile contains COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
It seems to me there are three ways to address this:
A) Change all those Makefiles to something like:
ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o else COBJS-$(CONFIG_GENERIC_MMC) += mmc.o endif
B) Modifying the config file with something like
#ifdef CONFIG_SPL_BUILD #define CONFIG_GENERIC_MMC ... #endif
C) Separate config files. One for SPL and the other for u-boot.
Which is the best way to do this?
Thanks
Charles
On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
Hi All
My understanding of the way SPL is intended to be configured is:
(a) You have one config file for both SPL and u-boot.
Yes.
(b) SPL features are selected via SPL-specific options.
For some parts, yes. Note that SPL does use -ffunction-sections/-fdata-sections/--gc-sections.
I have a need to build SPL with MMC/FAT support, but I don't want u-boot to have MMC/FAT support.
This is a new challenge, yes.
I do however see that quite a few SPL feature selections don't use SPL config definitions though which would seem to violate (b) above.
eg.drivers/mmc/Makefile contains COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
It seems to me there are three ways to address this:
A) Change all those Makefiles to something like:
ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o else COBJS-$(CONFIG_GENERIC_MMC) += mmc.o endif
B) Modifying the config file with something like
#ifdef CONFIG_SPL_BUILD #define CONFIG_GENERIC_MMC ... #endif
C) Separate config files. One for SPL and the other for u-boot.
Which is the best way to do this?
I think (B) is the method to go with. We already do this with certain things like CONFIG_SKIP_LOW_LEVEL_INIT.
On 05/17/2012 01:48 PM, Tom Rini wrote:
On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
Hi All
My understanding of the way SPL is intended to be configured is:
(a) You have one config file for both SPL and u-boot.
Yes.
(b) SPL features are selected via SPL-specific options.
For some parts, yes. Note that SPL does use -ffunction-sections/-fdata-sections/--gc-sections.
I have a need to build SPL with MMC/FAT support, but I don't want u-boot to have MMC/FAT support.
This is a new challenge, yes.
I do however see that quite a few SPL feature selections don't use SPL config definitions though which would seem to violate (b) above.
eg.drivers/mmc/Makefile contains COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
It seems to me there are three ways to address this:
A) Change all those Makefiles to something like:
ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o else COBJS-$(CONFIG_GENERIC_MMC) += mmc.o endif
B) Modifying the config file with something like
#ifdef CONFIG_SPL_BUILD #define CONFIG_GENERIC_MMC ... #endif
C) Separate config files. One for SPL and the other for u-boot.
Which is the best way to do this?
I think (B) is the method to go with. We already do this with certain things like CONFIG_SKIP_LOW_LEVEL_INIT.
We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
I still think (C) is the way to go.
-Scott
On 05/17/2012 01:22 PM, Scott Wood wrote:
On 05/17/2012 01:48 PM, Tom Rini wrote:
On Thu, May 17, 2012 at 12:13:20PM +1200, Charles Manning wrote:
Hi All
My understanding of the way SPL is intended to be configured is:
(a) You have one config file for both SPL and u-boot.
Yes.
(b) SPL features are selected via SPL-specific options.
For some parts, yes. Note that SPL does use -ffunction-sections/-fdata-sections/--gc-sections.
I have a need to build SPL with MMC/FAT support, but I don't want u-boot to have MMC/FAT support.
This is a new challenge, yes.
I do however see that quite a few SPL feature selections don't use SPL config definitions though which would seem to violate (b) above.
eg.drivers/mmc/Makefile contains COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
It seems to me there are three ways to address this:
A) Change all those Makefiles to something like:
ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o else COBJS-$(CONFIG_GENERIC_MMC) += mmc.o endif
B) Modifying the config file with something like
#ifdef CONFIG_SPL_BUILD #define CONFIG_GENERIC_MMC ... #endif
C) Separate config files. One for SPL and the other for u-boot.
Which is the best way to do this?
I think (B) is the method to go with. We already do this with certain things like CONFIG_SKIP_LOW_LEVEL_INIT.
We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
I still think (C) is the way to go.
But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it normally, yes? I really think it's a good thing that one build target gets one a bootable system now. If we need to rework things further, lets figure that out but I think it's a good thing that 'make omap3_beagle' spits out both parts.
On 05/17/2012 03:47 PM, Tom Rini wrote:
On 05/17/2012 01:22 PM, Scott Wood wrote:
We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
I still think (C) is the way to go.
But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it normally, yes?
That was more of an instance of "OK, I give in, we'll do it the simple but ugly way if it's just this one thing" than "the normal way".
-Scott
On Friday 18 May 2012 08:58:06 Scott Wood wrote:
On 05/17/2012 03:47 PM, Tom Rini wrote:
On 05/17/2012 01:22 PM, Scott Wood wrote:
We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
I still think (C) is the way to go.
But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it normally, yes?
That was more of an instance of "OK, I give in, we'll do it the simple but ugly way if it's just this one thing" than "the normal way".
To me it looks like the ugliness comes from an unclear policy resulting in SPL configs being handled in two different ways.
IMHO, the policy can be simplified and rationalised in two ways:
A) Recognise name each config option that might vary with an SPL and regular variant. That will just lead to hell in the Makefiles. - non inclusive or- C) Each binary has a different config and is built separately. Then there is no need for multiple CONFIGs for the same feature.
I have found (C) to work fine for building multiple variants (using a much older version of u-boot). For example, I build two stripped u-boots to run a manufacturing loader process. I thus build at least 3 different u-boots for the same board. Each has a different config and is built separately.
I guess common stuff can be rationalised: foo-common.h ....
foo-uboot.h #include "foo-common.h" ...
foo-spl.h #include "foo-common.h" ...
But that really makes for config file proliferation. Still, that would seem more manageable.
-- CHarles
On 05/17/2012 02:23 PM, Charles Manning wrote:
On Friday 18 May 2012 08:58:06 Scott Wood wrote:
On 05/17/2012 03:47 PM, Tom Rini wrote:
On 05/17/2012 01:22 PM, Scott Wood wrote:
We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles.
I still think (C) is the way to go.
But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it normally, yes?
That was more of an instance of "OK, I give in, we'll do it the simple but ugly way if it's just this one thing" than "the normal way".
To me it looks like the ugliness comes from an unclear policy resulting in SPL configs being handled in two different ways.
IMHO, the policy can be simplified and rationalised in two ways:
A) Recognise name each config option that might vary with an SPL and regular variant. That will just lead to hell in the Makefiles.
- non inclusive or-
C) Each binary has a different config and is built separately. Then there is no need for multiple CONFIGs for the same feature.
I have found (C) to work fine for building multiple variants (using a much older version of u-boot). For example, I build two stripped u-boots to run a manufacturing loader process. I thus build at least 3 different u-boots for the same board. Each has a different config and is built separately.
I guess common stuff can be rationalised: foo-common.h ....
foo-uboot.h #include "foo-common.h" ...
foo-spl.h #include "foo-common.h" ...
But that really makes for config file proliferation. Still, that would seem more manageable.
My suggestion would be to walk a few boards to that conversion. foo-common.h will be 97% of what foo.h is. A single file and making use of boards.cfg to set flags when we really need different builds and behaviors should do it. Of course with the Kconfig wishlist item maybe we could revisit this problem :)
participants (4)
-
Charles Manning -
Charles Manning -
Scott Wood -
Tom Rini