[U-Boot] Some thoughts on SPL
jonsmirl at gmail.com
jonsmirl at gmail.com
Fri Dec 16 18:20:32 CET 2011
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.
The concept is to remove SPL as a special class and turn it into the
base layer that everything builds on. Changing the model in this was
should make the config files easier to understand. Instead of having a
single file combining SPL and full u-boot you'd have two independent
ones. In my case I'd build one u-boot config that fits into 96K and
another full 250K one. Of course the two config files could each
include a common base config.
Thoughts?
--
Jon Smirl
jonsmirl at gmail.com
More information about the U-Boot
mailing list