From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Fri, 17 Jun 2011 00:09:00 +0200 Subject: [U-Boot] SPL framework re-design In-Reply-To: <20110616114556.7d3c2a78@schlenkerla.am.freescale.net> References: <4DF9B9E0.8020206@ti.com> <20110616114556.7d3c2a78@schlenkerla.am.freescale.net> Message-ID: <20110616220900.0746C19E5AC5@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Scott Wood, In message <20110616114556.7d3c2a78@schlenkerla.am.freescale.net> you wrote: > > What is a "generic SPL library", or even a "generic NAND SPL library"? > > There is no code that is shared by all NAND SPLs. The files directly under > "nand_spl/" are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. > Counterproposal: keep the basic structure the same, but refactor the > makefiles so that they use a common template but supply their own policy. > > That is, the board makefile would just set some variables to be lists of > objects it's interested in (and any other relevant tunables, or special > rules), and then include the common SPL makefile that will do all the > symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? > We could perhaps get rid of the symlinking and have the SPL makefile build > directly from the source into a different object location, though whether > we should depends on whether it actually makes things simpler. Agreed. > > That's no longer the case with the proposed scheme. Source > > files and Makefiles in the generic and CPU directory are shared by many > > boards. How do we allow customizability for individual boards. using > > CONFIG_ flags? This may be needed for the boards to make the right > > trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and > > -ffunction-sections help in dealing with this? > > What about when code depends on #defines that are not present for a given > target, because that target isn't going to select that file? What about > when alternative files have the same function names? What do you mean? When a target does not select (and thus build) a file, then it does not matter which #defines are in there or not - they don't get build anyway. If files which export the same funcktion names get linked together we have an error somewhere that needs to be fixed - but this is not a new issue, this situation is the same now already. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "I dislike companies that have a we-are-the-high-priests-of-hardware- so-you'll-like-what-we-give-you attitude. I like commodity markets in which iron-and-silicon hawkers know that they exist to provide fast toys for software types like me to play with..." - Eric S. Raymond