[U-Boot] Some thoughts on SPL

[jonsmirl at gmail.com]

The old lpc3130 port works the way you describe. The problem with it
is that it is on a three year old u-boot.
http://git.lpclinux.com/

It builds a single u-boot image and then slices the SPL piece off from
the front of it.

On Sat, Dec 17, 2011 at 12:38 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi,
>
> On Fri, Dec 16, 2011 at 9: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.
>>
>> 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?
>
> That's one way to do it, and makes more and more sense as the amount
> of available SRAM increases. Of course some SOCs can even set up their
> SDRAM and read entire programs in, so there are no restrictions. But
> for those with limitations, it makes sense to me to make SPL more a
> cut down build of U-Boot than a special program that pulls in #ifdefed
> code from various places.
>
> Another approach is to just have one U-Boot, but keep everything you
> need to get started in the first 96KB.
>
> I have the beginnings of a patch which allows you to split U-Boot into
> two parts: an initial part which is loaded first, and another part
> which can be loaded later if needed.
>
> It works by telling the linker where to put the code and arranging
> that everything you need early is at the start of the image. During my
> recent forays into SPL I formed the view that it might be another way
> to implement the SPL functionality. It is controlled by a config file
> which specifies function symbols, object files or libraries to include
> in the initial region. It can also work from a run-time profile.
>
> There are problems though. It is normally pretty easy to work out (or
> profile) which code is executed, but it is harder to know which data
> is needed. SPL solves this by linking and the resulting link errors
> when you get it wrong are easy to spot. But I don't have a tool that
> checks that all the code and data you need is within a certain region.
> Static inline functions can be a pain since they appear repeated all
> over the text area. Relocation data needs to stored with the loaded
> section.
>
> In short this 'postload' feature is more complex, but more general.
> Might be useful one day.
>
> Regards,
> Simon
>
>>
>> --
>> Jon Smirl
>> jonsmirl at gmail.com
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Jon Smirl
jonsmirl at gmail.com