[U-Boot] SPL framework re-design

[Wolfgang Denk]

Dear Graeme Russ,

In message <BANLkTinAPvRprePfnsOyPJERTu6hZGA-Pg at mail.gmail.com> you wrote:
> 
> I can think of three disctinct phases which are relatively commong across
> most arch's (especially NAND Flash arches)
> 
> 1) An intial page (say 256 bytes for example) which loads a second stage
>    into the CPU's cache
> 2) A second phase running in the CPU cache which initialises SDRAM and
>    loads the remainder into main memory (performs relocations etc)
> 3) A final phase which is U-Boot proper, running at the final target
>    address in SDRAM

The thing is that we have many different architectures, and NAND
booting systems are just one configuration out of many.

Depending on your architecture, the initialization of the RAM may be
semi-automatic (with just very few parameters needed), or data-driven
(you have to provide some magic data blob that gets interpreted by
some ROM code), or completely manual (where you have to pay close
attentian to insert the correct N microseconds delay here and there in
your code, as required by the RAM data sheet).

If you look back at the trouble reports from people who ported U-Boot
(and Linux) to their platforms you can see that RAM initialization
problems have always been a major problem area.

This experience, collected over many years, has led to the design we
have now:
http://www.denx.de/wiki/view/U-Boot/DesignPrinciples#6_Keep_it_Debuggable

Having debug output on the console as soon as possible is a pretty
important design goal; if technically possible, we do want to have
debug output long before initializing the RAM.  Unfortunately, this
pulls in a lot of dependencies: bigger parts of the code like printf()
and friends, access to the environment (to read the baudrate settings,
etc.)

> Now what I'm thinking is that if we formalise these loader stages, we
> could actually add a little more flexibility by, say, allowing the final
> U-Boot binary to reside on a file-system. And even break the final binary
> up into smaller 'run-once-and-discard' chunks. For example, a lot of the
> low level init is only ever done once, but it stays in SDRAM as a
> permanent piece of the U-Boot image - What if the second stage loader
> could instead load an low-level init blob and run it before loading the
> final U-Boot blob?

You would most probably lose the capability to have early debug
messages.

> This then opens the door for all sort of options - What if U-Boot commands
> were build into stand-alone binary blobs and only loaded when needed. Same
> with device drivers

Device drivers clearly need a rework.  But I'm not sure if dynamic
loading is as easy as you imagine it - we have a large number of
architectures here, and you need some support (drivers, file system
[or other structured storage space]) to koads objects from external
storage.

> So a lot of what is now build-time configuration could be reduced to
> run-time configuration

It sounds like a nice idea, but I fear there are a lots of devils in
the details.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A memorandum is written not to inform the reader, but to protect  the
writer.                                               -- Dean Acheson