From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Schwierzeck Date: Thu, 16 Jun 2011 16:27:52 +0200 Subject: [U-Boot] SPL framework re-design In-Reply-To: <4DFA0BE1.4060608@ti.com> References: <4DF9B9E0.8020206@ti.com> <20110616104716.762DD19E5AC3@gemini.denx.de> <4DFA0BE1.4060608@ti.com> 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 On Thu, Jun 16, 2011 at 3:57 PM, Aneesh V wrote: > Hi Daniel, > > This looks like an interesting alternative. > > On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote: >> >> Hi all, >> >> for my MIPS based boards I tested a approach similar to Wolfgang's one >> in the last weeks. >> My goal was to create a SPL image, that is able to boot from a SPI flash. >> >> The basic idea is to have a spl directory that is used as remote build >> directory for all object files >> needed for the SPL image. It contains only the Makefile and nothing >> else. This Makefile is >> a strongly simplified version of the TOPDIR/Makefile, uses >> TOPDIR/config.mk and creates >> a u-boot-spl.bin. The SPL build can be enabled by defining >> CONFIG_UBOOT_SPL in the board config file. > > In the last few mails Wolfgang was suggesting re-use of object files > themselves, not the source files. In this respect his approach may be > different from yours. But I think his objective was to avoid the > symbolic link business, which this approach achieves. I guess this requires more changes in the build system. But I wanted to keep the diff as minimal as possible. And some files like start.S must be recompiled with different flags. If running from SRAM you need another monitor base address, stack pointer offset and you must disable the relocate_code stuff. To reduce the SPL footprint you have to disable the whole printf and console stuff, so maybe you must recompile some drivers too. > >> >> If the spl/Makefiles becomes active, an additional variable name >> CONFIG_UBOOT_SPL_BUILD wiil be >> exported in the make environment. Additionally >> -DCONFIG_UBOOT_SPL_BUILD will be added >> to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse >> almost of the arch, SoC and >> board code. > > So, you are essentially re-using the make infrastructure of normal > U-Boot with a different top-level Makefile and the additional flags, > right? yes, but mainly the config.mk > > With this scheme can you build two different SPLs for a given board, > let's say a NAND spl and another MMC spl. I don't know if this is a > valid case, but just wondering. I guess you have a unique u-boot- > spl.bin much like you have single u-boot.bin, right? I have a single u-boot.bin and a single u-boot-spl.bin. To create images for different boot media, I use different board configs. For example BOARDNAME_nor or BOARDNAME_sf to boot from NOR flash or SPI flash. The NOR image currently builds without SPL. But there is a use case to combine a SPL image and a compressed U-Boot image to reduce the overall flash footprint. > > Will you be sending your patches to the list? > I've pushed some sample code to https://github.com/danielschwierzeck/u-boot-spl/commits/spl Best regards, Daniel