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

[Loïc Minier]

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