On Fri, Dec 16, 2011 at 10:20 AM, jonsm...@gmail.com <jonsm...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
