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

[Dennis Gilmore]

On Thu, 8 Aug 2013 20:48:24 +0200
Dirk Müller <dirk at dmllr.de> wrote:

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

you are free to make that choice. I don't want to close doors or force
people to do things only one way.

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

I've seen the patch and it is a start but it needs a bit of work to
support all the options people could want from it.

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

Right that is the ultimate goal. 

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

my proposal should enable you to use one boot.scr with variables.
however my goal is to use a extlinux.conf file that is exactly the same
format as those used for years in syslinux on install cd/dvds. I would
love all distros to move this way as it gives you a nice menu and a
simple interface with the option to select any installed kernel.

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

sure, some of it is definitely things that are down the road nice to
haves.

Dennis