From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Schwierzeck Date: Fri, 17 Jun 2011 20:45:19 +0200 Subject: [U-Boot] SPL framework re-design In-Reply-To: <20110616214704.B53F519E5AC5@gemini.denx.de> References: <4DF9B9E0.8020206@ti.com> <20110616104716.762DD19E5AC3@gemini.denx.de> <20110616214704.B53F519E5AC5@gemini.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang, On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk wrote: > Dear Daniel Schwierzeck, > > In message you wrote: >> >> The relocate_code and board_init_r functions must not be compiled, >> they are not needed anyway. This >> can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. > > This is very much wrong. ?In the general case, you still need > relocation (because the final start address of the U-Boot code canonly > be determined at runtime), and you definitely need the code in > board_init_r(). I guess we are talking about different kinds of SPL. In my understanding a SPL runs inside an internal SRAM, initializes any external RAM and loads U-Boot from any kind of memory or flash device into that RAM at a fixed load address and then jumps to that address. In this case no relocation is needed. Some kind of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM loads the SPL initially into SRAM and jumps to it. > > >> >> available in media specific directories such as nand_spl/ and mmc_spl/. >> >> Symbolic links? >> > >> > No. ?Let's put this stuff into ?spl/common/ >> >> To use the spl directory as remote build directory, the obj and src variables >> must be tweaked a little. To keep this changes minimal, it is not possible to >> have further source files and directories inside the spl directory. I suggest to >> put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. > > No. ?All SPL related stuff should go into spl/ ok Best regards, Daniel