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

[Dennis Gilmore]

Hi Wolfgang,

On Sun, 04 Aug 2013 21:48:00 +0200
Wolfgang Denk <wd at denx.de> wrote:

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

sure, the use cases of u-boot in generic linux that I know of today are
all ARM based but it doesn't mean it needs to be or always will be.

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

Home-made in what way? at least as I see it and I may be completely
wrong. The biggest hurdles for us a distro maker is, supporting a new
board means putting logic into the installer and the tools used in
kernel updating to understand how to detect the system, and deal with
the peculiarities of the system. I have had the anaconda guys reject
patches because they do not feel that the installer should know that.
when systems using u-boot are the only ones 

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

in embedded use yes. I realise the the use case im talking about is not
the most typical for u-boot and its not right for all targets, but its
what id like to see supported on hardware that is targeted at being
supported by generic distros.
 I
> > 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.
its interesting in the use cases im trying to target

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

Its not an ARM issue, the same thing would exist on PPC if we were
trying to use a generic Distro on it. its a difference between a
embedded where you control the whole stack and build the software
optimised for it, and the generic distro where you build it to the
lowest common denominator, and want it to run in many different ways on
different systems.

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

again its a use case issue.

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

it may well be. i suggested it because sadly things get bigger all the
time. if we hardcode in locations what gives plenty of room today may
not be enough tomorrow. 

> > 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.
again different use cases. not all use case have, need or want this.

> > 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?
yes I have, its not what I would call fun. I don't assume that there is
always a user there to provide input, I assume that when a user
needs to provide input there is a way for them to do it. We can't
assume that users have serial console access.

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

Thank you for your valuable feedback. We have two very different
use-cases and ideally need to have a sane way to support both. I do not
know if the hardware targeted for use with generic linux distros is
also used in embedded use cases. all of what I've proposed would work
just as well on systems using a generic distro regardless of the
architecture. I certainly don't want to make things harder for the
embedded use cases.

Dennis