From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 27 Jun 2011 13:42:05 -0500 Subject: [U-Boot] SPL framework re-design In-Reply-To: <20110627093633.679C71A23C3F@gemini.denx.de> References: <4DF9B9E0.8020206@ti.com> <20110616104716.762DD19E5AC3@gemini.denx.de> <4DFA00B8.7000807@gmail.com> <4E080733.2030001@ti.com> <20110627093633.679C71A23C3F@gemini.denx.de> Message-ID: <20110627134205.021af180@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 Mon, 27 Jun 2011 11:36:33 +0200 Wolfgang Denk wrote: > Dear Aneesh, > > In message <4E080733.2030001@ti.com> you wrote: > > > > > I wonder why do we need this whole spl thing in the first place (well, > > > surely I know what they are used for but why do we need a separate entity > > > for this)? Isn't it just the same U-Boot in, well, very special configuration > > > (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree > > > at spl/ instead of just providing the _configuration_? > > > > > > Am I missing something? > > > > The reason is that the regular U-Boot is not configurable enough to > > build the extremely small images that should fit in internal RAM. The > > last time I attempted, I ended up getting an ~60KB image for > > OMAP4(that too without any of the hardware initialization I am adding > > in my SPL work). > > This statement does not make much sense to me. If we can do it in the > spl/ directory, we should be able to do it in any other directory as > well. The worst to happen is that we have to keep two setsof object > files separated, but chosing a different suffix should be sufficient. We do it in the spl/ directory by bypassing the normal makefile config system, specifying a board-and-spl-specific list of objects instead. It could of course be done with the standard config system, but it will require that every bit of code in U-Boot be enabled only with a particular config option -- no "always on" code. This would be a good thing anyway, but it will take some work to do it cleanly. A first step would probably be a global "finegrained/small" flag that configs use to opt into the new system, but eventually all bits of functionality should have appropriate individual config symbols. -Scott