From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 16 Dec 2011 15:49:33 -0600 Subject: [U-Boot] Some thoughts on SPL In-Reply-To: References: Message-ID: <4EEBBCED.8080602@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/16/2011 11:20 AM, 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 16K? Luxury! :-) Many boards have only 4K, and IIRC some have only 2K. > 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. All the SPL model is really supposed to be is makefile infrastructure for building the two stages. What code you pull in is configurable. > One example of a conflict with SPL is NAND support. With SPL you hard > code in the NAND type. This is only required with nand_spl_simple.c. You could provide an alternate SPL driver, or even pull in the standard SPL stack if you want. No need to hack up nand_spl_simple.c. > 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. A while back I suggested tracking a fully separate config for SPL, but Wolfgang didn't like it. Maybe a larger set of concrete use cases (and what it looks like to deal with each one manually as would currently be needed) would be convincing -- at the time it was just about having a separate CONFIG_SYS_TEXT_BASE_SPL. -Scott