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'?