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

[Wolfgang Denk]

Dear Dennis Gilmore,

In message <20130803021104.1fecaf5a at adria.ausil.us> you wrote:
> 
> I wanted to start a discussion on defining a unified feature set that
> makes it simpler for the different distros to support ARM systems using
> u-boot. I have based a lot of my thoughts on how calxeda ship their

When talking about simplifying and unifying things, you should not
start with the mistake of an architecture specific view.  ARM may be
what you are interested in, and where most of the current development
is happening, but it is not the only architecture around.

Also, it may make sense to start with leaning back a bit and looking
how other architectures solved some of the issues ARM is having.  My
feeling is that some of them are actually home-made.

> 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 

Actually it is a horror thought to me that U-Boot could degrade into
such a horrible envrionment as the boot loaders (BIOS, UEFI etc.)
provide, both to the developer and to the end user.

No, this is definitely NOT where we waht to head for.

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

This may be interesting for you, but faci it: the majority of boards
are not using ext4 based root file systems, nor xfs.  Most of them are
strictly embedded devices, and the use of JFFS2 (yes, still!) and
UBI/UBIFS on NOR and NAND flash is far more common.

> pxe boot suport, two reasons, one is to be able to easily network boot
> the distro installer, the other is to use sysboot support post install
> with a extlinux.conf file to specify the kernel, initrd and bootargs

PXE may be interesting for a very small percentage of applications,
but it is nothing to unify on.  Existing DHCP / TFTP / NFS support is
much more commonly used.

> bootz and raw initrd support. not having to wrap kernels and initrds
> really is a must. raw initrd support means that its much simpler for a

Actually this is strictly an ARM issue. No other architecture has such
problems.  U-Boot images (both the old, legacy uImage format, and much
more so the FIT imagesformat) have a large number of advantages,
especially for software management on embedded systems.

Also, a pretty common requirement in U-Boot land is boot time
optimization.  The common approach of standard distros with a
multi-stage intialization sequence including booting from an intial
ramdisk before mounting the real root file system is usually
prohibitive in such szenarios.

> user to rebuild an initramfs if needed and bootz means we do not need
> to worry about making sure that we specify the correct addresses to
> load the kernel to when calling mkimage.

Again, this is a problem home-made by ARM Linux.  I am not ware of any
such issues with other 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.

This is easy to say, but difficult to impossible to implement in the
general case.  The problem of dealing with compressed images where you
usually don't know in advance how big they will become when
uncompressed) has already been mentioned.  The property especially of
the ARM Linux kernel (in default setup) to copy itself around if it
deems fit and some other such issues make things really complicated.

When you talk of unifying, this must be done on both sides - the boot
loader cannot solve or fix up all the issues caused elsewhere.

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

Such a requirement can never be fulfilled.  For example, there are
many embedded systems which have all kind of devices attached which
would go haywire if you start sending console output to them.

> Fedora Boot Options.
> 1:	Fedora (3.9.9-302.fc19.armv7hl) 19 (Schrödinger’s Cat)
> 2:	Fedora (3.9.4-301.fc19.armv7hl) 19 (Schrödinger’s Cat)
> Enter choice: 
> """
> is the output on boot, the user can then enter 1 or 2 to select a
> kernel to boot. if nothing is selected the first option is booted after
> the timeout expires.

You always assume that there is a user, who provides manual input, and
such.  This is simply not true.  Actually this is not even true on x86
systems, and if you ever try running any standard x86 board in a
remote-operated way, you will quickly realize what I mean.  Yes, there
are versions of boot loaders available that support some kind of
serial console interface.  But then - there are all kinds of PCI cards
which require things like pressing "ALT + 3" to enter specific modes.
Ever tried that on a serial console?


> What this gets us in the end is that with a unified kernel, device tree
> and u-boot implementing the system specific knowledge, supporting new
> ARM systems is along the same lines as supporting new x86 systems. Get

As mentioned before, this requires not only work on the U-Boot side.
And you have to keep in mind that your vision is actually for a small
sector of the market, for one specific application case, while
embedded devices have totally different requirements.  And last but
not least, let's keep the head up so we can see over the rim of our
plate: not all the world's an ARM box, and any such unification should
be done in an architecture-independent way.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of all the things I've lost, I miss my mind the most.