[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

Loïc Minier
2011-11-08T14:22:18Z

On Mon, Nov 07, 2011, Simon Glass wrote:
> How can we give U-Boot what it
> wants, which is apparently the ability to decompress the kernel itself
> and arrange everything in memory at the right place? Wolfgang
> complains that patches to do this have been repeatedly rejected in the
> kernel. If this is the FIT image, how about adding a 'fitImage' make
> target?

Looking at this thread from the point of view of distributions (e.g.
Debian/Fedora/Ubuntu etc.), I see some integration disadvantages in the
FIT image approach and to uImage in general. The format itself is nice
and handy, but in an ideal world a distribution would provide a
SoC-agnostic image, and even a bootloader-agnostic image.

Currently, what Debian and Ubuntu do (didn't check Fedora) is:
* ship zImage files (vmlinuz-*) in kernel .deb packages
* when kernels or initrd related files are installed, generate:
- uImage from the right vmlinuz file with the exact load value
- an initrd.gz with initramfs-tools, then an uInitrd from it
- a boot script for that board, then a boot.scr from it which is an
U-Boot script in uImage format

This is painful in at least these ways:

a) images are not board-agnostic or even bootloader agnostic (I'd love
if a single SD card image would boot on multiple OMAP3 boards, or on
OMAP3 and OMAP4, or on i.MX51, i.MX53, OMAP3 and OMAP4, whether the
firmware uses U-Boot or is just a boot ROM, or UEFI or whatever)

b) distributors keep track of load addresses for uImage/uInitrd/boot.scr
as to generate correct uImages

c) this wastes space for multiple copies of the boot files (uImage +
uInitrd + boot.scr + vmlinuz + initrd.gz)

I can see how the proposal to use relative load addresses or to set -1
as load address in uImage help with some of the above, but for sure c)
will remain a hard issue with FIT images as some distributors will keep
generating an initrd when various packages get installed (e.g. for LVM
or mdadm support, or encrypted root etc.).

There are advantages to the uImage format such as usage in flash, or
choice of compression type (whatever you stuff into it), and these
remain valid in other use cases, but it seems sensible to support
vmlinuz directly from U-Boot to support a more generic distro image
boot protocol.

Personally, I also like the separation of layers so that vmlinuz is
kept opaque; for instance vmlinuz can embed an initrd or a DTB without
the bootloader having to care about them, or it could be compressed
with LZO or bzip2 even if the bootloader in firmware doesn't support
this or that compression type. I think distros would prefer not using
these features and having a DTB-aware bootloader though.

--
Lo?c Minier