[U-Boot-Users] U-Boot-NG ?

[Andrew Dyer]

A few comments -

I very much like the separation of first and second stage and
relocation of u-boot.  The idea of 'get to ram first' makes a lot of
sense to me.

For the first stage loader, it seems like a printf is overkill.  If I
can print strings, 32-bit hex numbers and maybe decimals that should
be enough.

One of the things I like about eCos/RedBoot is the way they divide up
code into architecture, variant, and platform.  I think u-boot would
benefit from making these distinctions clearer.

In eCos they allow the variant to override the architecture and the
platform can override either variant or architecture.  The thing I
hate about eCos is the configtool and preprocessor nightmare they use
to achieve this.  It sounds like we could achieve similar things with
weak functions.

I would like to see the 'second stage' of u-boot be made more modular.
 I imagine a set of basic code (console, environment, loader, storage
driver) would get loaded first and additional commands and drivers
could be stored as compressed uImages and loaded as needed and chained
onto the list of valid commands/functions.  This shouldn't be allowed
to get too out of hand (no automatic dependency resolution,
autoloading, or anything like that :-)

It might be nice to have something like tinderbox - a machine churning
through building all of the supported platforms based on a top of git
stable and/or testing branch and have a
web status.  It would make it easier to test system wide changes if
the developer doesn't have all of the toolchains on their machines and
would help keep platforms code from getting 'stale'.

Is u-boot big enough to have a 'janitor'?


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.