[U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/08/2013 12:48 PM, Dirk M?ller wrote:
...
> Therefore, the openSUSE on ARM team has a locally patched version of
> u-boot that handles booting from extX directly, because we did not
> like to use FAT or anything similar for /boot, and didn't see the need
> for adding a special /load (or similar) partition that is only there
> to make u-boot happy.

Could you expand upon what "handles booting from extX directly" means?
Upstream U-Boot has supported ext2/3 for as long as I've been involved
with it (which admittedly isn't that long), and ext4 support was added
recently. This allows U-Boot commands "extload" or "load" to access ext*
just like any other file-system. Is there something more involved when
you say "booting from extX directly" beyond just the extload/load commands?

...
> on openSUSE for ARM, we're converging to using only one boot.scr
> template, that is
> only templatized on the various addresses that are needed to be passed
> down and the flavor name (mostly for being able to print the right
> information during boot).
> 
> If it is reasonably possible to avoid the templatisation of the
> addresses, I'm all for it. I don't know if it is feasible, and for us
> it is not really an issue (unless it is a board supported by the
> zimage flavor).

I think it's reasonable to require that boards supported by generic
distros have upgraded/recent U-Boots that export a standard set of
environment variables that define the various addresses, so that
boot.scr authors don't have to care about platform differences, but
rather simply use those variables. For example, kernel_addr_r,
ramdisk_addr_r, fdt_addr_r, etc.