[U-Boot] zImage on ARM

Thu Sep 9 10:57:04 CEST 2010

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20100908232753.GA20336 at bee.dooz.org> you wrote:
>
>  These are indeed nice features of uImages (checksums +
>  build date information); but they are not needed in all use cases for
>  U-Boot.  Distributions are shipping zImage for ARM nowadays and when
>  shipping zImage files withing packages (.deb for instance), there are
>  already checksums, file timestamps, public build logs etc. as part of
>  the distro toolkit.

Hm... the checksum of the distributyed poackage gives you zero help
when it comes to check the image after a download to the target.

Keep in mind that the uImage format was invented to address typical
problems of embedded systems:

You have a device with some data in flash. You don't know what
happened to the device. Now quickly check:
  - Is it a kernel? Is it a file system?
  - Has the image been corrupted / partially overwritten?
  - Which version / production ID / production time is this image
    from?

Please also note that what most people refer to when talking about
"uImage" files (data payload with prepended 64 byte header) is
considered to be the old, obsolete legacy image format. The officially
recommended image format for U-Boot is FIT images, which allow for
very powerful extensions; see doc/uImage.FIT/

>    Also, this means end-user systems need mkimage installed (because
>  uImage differ slightly across boards).  Not a problem for an embedded
>  developer obviously, but would prefer avoiding this need on an end-user
>  system.

I don't see why uImages differ across boards - if the same kernel
image can be used (i. e. the same zImage file use to generate the
uImages) on these boards?

>  (Nitpick: if you want an accurate time for the kernel build, them this
>  should rather be recorded during the upstream linux kernel build rather
>  than at the time the uImage is created, which could be quite some time
>  later!)

This is not a bug, but a feature. We don't want the time of the
kernel build, because the kernel is often just one component in an
image file, which may contain more than one kernel image, plus one or
more device tree blobs, plus one or more file system images, etc.

It is intentional to use the timestamp when the image was created.

> > >  Seems zImage is quite widespread now; would it make sense to allow
> > >  builing u-boot without that code and rely on the kernel code to unpack?
> > Why duplicating the stuff again and again and again?
> 
>  Well, I'm proposing skipping one copy   ;-)   the U-Boot one

U-Boot does not perform any additional copies on the target, if the
image was build correctly and in a sane way.

> > >  Or should u-boot just gain a new image type for zImage?
> > Why not use uImage like we do with other architectures? 
> > Why is it that ARM always has to try to reinvent the wheels?
> 
>  Eh, zImage has been around for a while!

Indeed. But has been around a decade as well.

>  I guess it's just that we don't /need/ the couple extra uImage
>  features, and would rather ship zImage directly.

You still need some information on the target when it comes to booting
the image - at least you need to know the entry point address (or it's
offset into the image).

>  It would also remove the need for maintaining the table of magic values
>  for uImage / uInitrd generation; a problem I described recently on
>  another list:
>  http://lists.linaro.org/pipermail/linaro-dev/2010-August/000493.html

In that message you write:

Actually you need load address and entry point address.

If you can come up with position independent payload, you still need
the entry point (then probably in terms of offset relative to the
current image address).

Patches to implement this (in the context of FIT images) are welcome.

|  * generate an u-boot initrd image from an initrd.gz
|    - input: initrd.gz, initrd load address
|    - output: uInitrd

This makes no sense to me. Ramdisk images don't need to be loaded
anywhere.  I consider it a bug in the ARM Linux kernel that you have
to load a compressed initrd image to RAM first, then uncompress it,
then use it. In other architectures (say PPC) we can pass the address
of the image in flash memory to the kernel, which saves one copy
operation.

Patches to support this for ARM as well have been submitted - and
rejected.

You talk about making code more efficient and saving unnecessary copy
operations - I recommend to fix this in Linux.

For PowerPC, initrd images have load address and entry point address
set to dummy values (0), which are not used anywhere in U-Boot.

>  So we'd be happy if you'd take patches to have U-Boot accept this
>  "dumber" format.

You may be aware that the implementation of the "bootm" command has
been split into small building blocks some time ago. The idea was to
allow for easy customizing, eventually even on command line level.
You should be able to craft a custom boot command this way, which
omits the header check.

But I don't think that this solves your problem - you still need
information at least about the entry point address, which then has to
be stored separate from the image file, which just shifts the problem
to another area.

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
I mean, I . . . think to understand you, I just don't know  what  you
are saying ...                        - Terry Pratchett, _Soul Music_