From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 27 Jun 2011 11:27:28 +0200 Subject: [U-Boot] SPL framework re-design In-Reply-To: <4E0804DC.8090805@ti.com> References: <4DF9B9E0.8020206@ti.com> <20110616104716.762DD19E5AC3@gemini.denx.de> <4DFB8579.1020309@ti.com> <4E00799A.5040302@ti.com> <20110625121050.6CAAB20155D@gemini.denx.de> <4E0804DC.8090805@ti.com> Message-ID: <20110627092728.D19B91A23C3F@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 Aneesh, In message <4E0804DC.8090805@ti.com> you wrote: > > >> +spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend > >> + $(MAKE) -C spl/ all > >> + > >> $(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl > > > > The mmc_spl/ is suppoed to be moved into spl/, isn't it? > > This patch was intended only as a prototype for the new directory > structure. I didn't bother to touch the existing stuff. I see. > >> --- /dev/null > >> +++ b/spl/Makefile > >> @@ -0,0 +1,94 @@ > >> +# > >> +# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierzeck at googlemail.com. > > > > Really??? > > I copied Daniel's Makefile and started from there. I guess the only real part that was left from the old file is the GPL header... > > As Mike mentioned, we can eventually directly include the OBJSs here > > and omit the building of libraries? > > I can't seem to find a mail from Mike on this thread. Did I miss any > mail? I can find it either. I don't know what I had in mind then. > Do you mean re-using equivalent libraries from the normal U-Boot > without re-compiling them? There are actually two different topics here: - The first is how to link all the objects in the spl/ tree together. As I understand, you proposal was to link all objects in each of the subdirectories into a library, and then link all the libraries together. Instead of doing this, we could as well just maintain a list of objects and then link all these together directly, without creating libraries first. - The other topic is if to build new object files, and where. At the moment we have two situations: * Some files are built with special options such that unneeded code gets commented out using respecive #ifdef's / #ifndef's. We can probably get rid of (most of ?) these #ifdef's / #ifndef's when properly using -ffunction-sections / --gc-sections Why should we then recompile the code? * Some files (start.S) really need different code. Here the questions is more how and where to recompile using proper options. I would be glad if we could get rid of the symlinking. Maybe we can add respective build rules to the original Makefiles (see also proposal by Ilya, http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102033 ), eventually just using a different suffix, say ".splo" instead of ".o"? > > allow for vendor directories (where "BOARDDIR = $(VENDOR)/$(BOARD)"). > > I didn't want to make the directory structure any longer than required. > But I can add this if required. It will be needed. > > Hm... can we try to do without the symlinks? > > Well. I think it's difficult. Most of my hardware initialization such > as clock init, SDRAM init etc need to know under what context it > is getting executed. The context can be: > 1. SPL > 2. Regular U-Boot executing from NOR flash > 3. Regular U-Boot executing from SDRAM > etc. Agreed - we need another, independent set of object files. But cannot we create these in the existent source tree? > If you want to do away with symlinks, I would propose going with > Daniel's approach. This uses /spl as a remote building directory, but > do not create any symlinks. Yes, this is an improvement over the current situation - but Ilya's question is a good one: why do we need the pl/ subtree in the first place? 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 "You shouldn't make my toaster angry." - Household security explained in "Johnny Quest"