[U-Boot] Some thoughts on SPL

[Simon Glass]

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