From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 20 Sep 2011 23:16:04 +0200 Subject: [U-Boot] =?iso-8859-1?q?=5BPATCH_2/2_RESEND=5D_SPL=3A_Allow_user_?= =?iso-8859-1?q?to_disable_CPU=09support_library?= In-Reply-To: <4E78E588.1010508@freescale.com> References: <1315800204-19705-1-git-send-email-marek.vasut@gmail.com> <201109200031.29588.marek.vasut@gmail.com> <4E78E588.1010508@freescale.com> Message-ID: <201109202316.04328.marek.vasut@gmail.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 Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote: > 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. That kind of granularity is there already too -- though on driver level. But so far it seem sufficient. > > 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. No, it's really rare if you want to replace your lowlevel init code because your ROM seems strange. > > -Scott