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

[Dirk Müller]

Hi Dennis,

> right or wrong we want things to be simple for the user and to largely
> look like a linux system on x86 would. The user and distro should never
> need to worry about memory locations
>
> so this would mean similar partitioning. i.e. /boot on ext4 root and
> swap  on lvm or as raw partitions. people should be able to have
> just / on ext4 also. Down the road xfs /boot support would be a nice to
> have.

I personally don't see a reason for xfs on /boot (or the journalling
nature of ext4, but thats besides the point). I agree though that a
filesystem that supports symlinks is a must for being able to
reasonably well install a regular kernel image (or multiple parallel)
on /boot.

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.

We've not always received love for this patch, given that all the
people who "know how to do things" where confused because our way of
building an image was so different than what is documented on the net
everywhere, but it makes the layout feel more natural for somebody
coming from non-ARM architectures.

> when it comes to memory addressing a distro and user shouldn't need to
> know anything. Ideally u-boot will auto allocate addresses based on the
> size of loaded objects. starting with a base address internal to u-boot
> you load a kernel, when loading an initramfs u-boot automatically
> calculates an address that ensures it does not overlap with the kernel.
> same for a fdt if loaded. I say auto calculated because what we think
> today will be enough room may not be tomorrow, dynamically calculating
> gives the flexibility for whatever may come.

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).

> output and input should happen on all possible devices and not just the
> serial console. If a user has a trimslice with only a HDMI monitor and
> usb keyboard they should be able to see the menu listing their possible
> kernels and be able to choose which one they want to boot.

True. not easy to detect though which input/outputs are connected. We
have issues due to that as well.

Greetings,
Dirk