From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Tue, 28 Jun 2011 10:55:53 +1000
Subject: [U-Boot] SPL framework re-design
In-Reply-To: <4DF9B9E0.8020206@ti.com>
References: <4DF9B9E0.8020206@ti.com>
Message-ID: <BANLkTinAPvRprePfnsOyPJERTu6hZGA-Pg@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi All,

Just thought I'd throw in a left-field idea...

Could we make the loading of U-Boot into a generic multi-stage framework
with each stage bootstrapping the next stage? OK, I know this is how IPL,
SPL etc work already, but I'm thinking something more formal and arch
independent.

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

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?

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

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

Just a few wild ideas...

Regards,

Graeme