From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 17 May 2012 13:47:13 -0700 Subject: [U-Boot] What is the correct way to configure SPL options? In-Reply-To: <4FB55E1D.4040309@freescale.com> References: <20120517184835.GB23562@bill-the-cat> <4FB55E1D.4040309@freescale.com> Message-ID: <4FB563D1.7080105@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. -- Tom