On Fri, 14 Oct 2011, Stephen Warren wrote:

Nicolas Pitre wrote at Friday, October 14, 2011 2:45 PM:

quoted

On Fri, 14 Oct 2011, Stephen Warren wrote:

...

quoted

quoted

I did originally briefly look into getting U-Boot to boot a zImage, but
that looked like a far more invasive patch. There were rumours of some
chip's custom U-Boot already having such support, but I couldn't find
it, nor any evidence of such support in mainline U-Boot.

FRom my clone of the u-Boot repo:

$ git grep -l zImage
README
arch/sh/lib/zimageboot.c
arch/x86/lib/zimage.c
...

Even the name of some of those files clearly hints zImage support.

In any case, loading zImage should be even simpler than loading uImage.
It is the same as loading uImage except that you just have to skip the
checking and relocating steps.

Just by way of background in case anyone is wondering why I wrote the
patch I did:

Those files both implement custom commands "zimageboot" and "zboot". I
was looking for integration with the existing "bootm" command.

The advantage of re-using "bootm" for this is that it already supports
all the stuff like setting up kernel command-lines, initrds, knowing how
to pass the FDT to the kernel, and whatever other OS-specific setup might
be required.

Absolutely.  And that is a must-have.

The disadvantage of adding zImage support to bootm is that I'd have to
teach a bunch of U-Boot image handling code about a new image format; it
already knows about "legacy uImage", "FIT" images, and I'd have to add a
third "zImage" format. Doing so would at least require adding a lot of
"case IMAGE_FORMAT_ZIMAGE" everywhere, but it'd probably be best to add
some kind of vtable for image formats to move all the image-format
knowledge into format-specific files, leaving the users of the images
with much smaller code.

I didn't feel like making such a large change. Hence, I chose to make a
small change to the existing uImage support.

And that change is certainly valuable.  Some people do want the extra 
feature from the uImage format.  REmoving its absolute address 
limitation is a good thing.

However, also supporting zImage directly on ARM doesn't have to be that 
hard.  Instead of adding "case IMAGE_FORMAT_ZIMAGE" everywhere, all you 
would have to do is to load zImage in memory according to the load 
address provided as an argument to the command, and then fake a uImage 
load by artificially creating the uImage header at run time with the 
data that u-Boot needs later on.


Nicolas