From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 16 Jun 2011 11:45:56 -0500 Subject: [U-Boot] SPL framework re-design In-Reply-To: <4DF9B9E0.8020206@ti.com> References: <4DF9B9E0.8020206@ti.com> Message-ID: <20110616114556.7d3c2a78@schlenkerla.am.freescale.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, 16 Jun 2011 13:38:00 +0530 Aneesh V wrote: > New Design Proposed by Wolfgang: > * Have a top-level Makefile in the SPL root-directory - for instance > 'nand_spl/Makefile' > * nand_spl/Makefile builds a generic library with the generic source > files at this level. 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. 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. And no, I don't think we can get rid of building the objects separately, and I don't want a situation where #ifdef NAND_SPL is honored in some files but not others. 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. > 3. Customizability - In the existing scheme what gets built into the > SPL for a given board was completely customizable by the board level > Makefile. This is a critical feature for a situation where we need to fit in a tiny space and target a variety of different hardware. > 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? -Scott