From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 20 Sep 2011 14:12:08 -0500 Subject: [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library In-Reply-To: <201109200031.29588.marek.vasut@gmail.com> References: <1315800204-19705-1-git-send-email-marek.vasut@gmail.com> <201109170048.36433.marek.vasut@gmail.com> <4E778659.4060403@freescale.com> <201109200031.29588.marek.vasut@gmail.com> Message-ID: <4E78E588.1010508@freescale.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 09/19/2011 05:31 PM, Marek Vasut wrote: > On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote: >> On 09/16/2011 05:48 PM, Marek Vasut wrote: >>> The stuff in arch/arm/cpu should be exactly what you need, nothing more ! >> >> This is "spl/", not "arch/arm/spl/", so let's not reason from one >> architecture, much less the subset of that architecture that has already >> been made to work with spl/ -- there are 14 different instances of >> arch/arm/cpu/$(CPU). > > I don't think I follow you on this one really -- are we still discussing the > inclusion/non-inclusion of the cpu-specific library in the SPL, right ? We're discussing CONFIG_SPL_NO_CPU_SUPPORT_CODE and its use in spl/Makefile. >> We will not want everything we normally pull from >> arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But >> we will want some small portion of it. > > Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD It's not quite that simple, since different SPLs will have different requirements. Board config headers will need to define symbols like CONFIG_SPL_FEATURE and the makefiles will use both CONFIG_SPL_BUILD and CONFIG_SPL_FEATURE to determine which object files to include. Board config headers should set appropriate symbols indicating what parts of arch/$(ARCH)/cpu/$(CPU) they want during an SPL build (at whatever granularity is appropriate). If that's an empty set, then so be it, no need to avoid the directory altogether. >> Whether it's file or directory based, everything should be off by >> default. Boards should ask for what they want, not what they want to >> exclude. > > Actually, this being a rare case where you want it excluded, it's better the way > it is. I disagree, especially in the early stages where we're setting an example for how other components will be handled. -Scott