[U-Boot] Some thoughts on SPL

Tom Rini tom.rini at gmail.com
Tue Dec 20 16:38:59 CET 2011


On Fri, Dec 16, 2011 at 10:20 AM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> The CPU I'm working with, the LPC3130, is kind of an in-between CPU
> for SPL. Instead of a tightly constrained RAM of 16KB or so I have
> 96KB to work with.  96KB is enough room to support all of the various
> boot modes (uart, nand, spi, USB, etc) but not enough room for the
> full uboot command set. So I'm still stuck with the SPL model, but my
> constraints are much less.
>
> One example of a conflict with SPL is NAND support. With SPL you hard
> code in the NAND type. In my case I have enough room to do NAND type
> detection. So this has me modifying the #ifdefs in the makefiles to
> include the NAND detection code in my SPL loader.
>
> I'm wondering if SPL could be designed in a more generic manner.
> Another model would be to use SPL as the base layer for all u-boot
> builds. You would then start turning on features until full uboot
> capability was reached. An example of this would be NAND support, the
> default would be hard coded NAND for all u-boot builds, but turning on
> NAND detection would increase the size of the build and disable the
> hard coded support. Another default would be SPL chaining into the
> next image, turning on the u-boot UI would again make the code larger
> and disable auto-chaining.

So, in chasing down another problem I was having (that turned out
unrelated) I just made SPL use the full NAND stack.  It wouldn't be
difficult to add CONFIG_SPL_FULL_NAND_SUPPORT (and either keep the
existing name for nand_spl_simple or rename to
CONFIG_SPL_MIN_NAND_SUPPORT).  I've even got the tree I did that hack
in around on github if you want a reference.

-- 
Tom


More information about the U-Boot mailing list