[U-Boot] [RFC] Extend 'bootm' to support Linux kernel generated images

[Tom Rini]

On Wed, May 21, 2014 at 10:10:50PM +0200, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20140521195824.GE1752 at bill-the-cat> you wrote:
> > 
> > Something that Rob mentioned to me at ELC, and others have mentioned
> > before is that it would be nice if 'bootm' (which says "boot application
> > image stored in memory" in the help, even) would just work with zImage
> > or Image or whatever is spit directly out of the kernel.
> 
> I don;t think this is a good idea.  "application image" is supposed to
> mean "one of the U-Boot image formats", which means the old legacy
> image format (with the 64 byte header), or FIT images.  To boot a
> zImage file, we have the "bootz" command.

Yes, it's historically meant something with an essentially (technically
no, practically, yes) U-Boot centric header on it.  But that's not what
the help text says.  And yes we have bootz for zImages and I added booti
for Image images.  That resulted in "You mean I have to type different
things for arm and arm64? *sigh*" when explaining this in person.

> I also think such a patch is pushing into the wrong direction.  We
> should rather try and improve the kernel support for FIT images.

That's neither here nor there.  You can create and boot FIT images
today, anywhere it's enabled (including arm64).  You can do the same
with legacy images (which also resulted in sighs when I mentioned this).
The kernel doesn't want any of this in the kernel tree.  Developers want
to have as few steps between "build my kernel" and "now I'm testing my
kernel".  Adding in "create / grab stub FIT file, run mkimage" results
in more unhappy developers.

> > +	zi = (struct zimage_header *)map_sysmem(image, 0);
> > +	if (zi->zi_magic == LINUX_ARM_ZIMAGE_MAGIC)
> > +		return 0;
> 
> I smell endianess issues here?

We don't do BE ARM atm anyhow, so one more in the pile of many, most
likely.

> > +#ifdef CONFIG_BOOTM_LINUX_RAW
> 
> LINUX_RAW ?

Yeah.  We can grab the color wheel for the bikeshed later, if we go down
this path :)

> >  /* Image format types, returned by _get_format() routine */
> >  #define IMAGE_FORMAT_INVALID	0x00
> > +#define IMAGE_FORMAT_LINUX	0xFF	/* Linux kernel defined formats */
> >  #define IMAGE_FORMAT_LEGACY	0x01	/* legacy image_header based format */
> >  #define IMAGE_FORMAT_FIT	0x02	/* new, libfdt based format */
> 
> This does not look clean to me.

I could call it 0x03 too.  I was trying to signify that it's basically a
lack of well defined header.  A legacy image is a legacy image, a FIT
image is a FIT image, a Linux image depends on what arch you're talking
about.

> > It of course doesn't work and just shows where I think we would need to
> > fill things in and probably provide some __weak functions for other
> > arches.  Looking over how we do bootz today, and how I wrote booti for
> > arm64, it should be possible to do the correct callouts at the correct
> > places for "oh, we don't have a legacy or FIT header, we have a per
> > Linux architecture defined header".
> >
> > What does everyone think about extending things in this direction?
> 
> I am no real friend of trying to be clever and automatically guess
> image formats.  In my opinion it is more reliable to be able to verify
> if an image os OK or corrupted, instead of passing a corrupted image
> on to guesswork which might then belive it could be some other image
> format (without checksums or such) and try to run it.

It is not impossible that a FIT image could become corrupt in just the
wrong way to have the zImage (or Image or whatever the arch supports)
magic value and then go horribly awry.  It seems exceedingly unlikely
however.

> The user should give U-Boot a clear hint which image format to expect,
> and allow U-Boot to complain otherwise.
> 
> If someone really wants such a trial and error approach, he can still
> do this without adding code that affects everybody with just a little
> scripting - like "bootm $addr || bootz $addr || ...".

That's not the usecase really.  The usecase is roughly "I just want to
boot what the kernel build spit out and not have to guess the command".

How about if we added a new command, 'boota[uto]' to make a few stabs at
guessing the format?  The first problem that pops to mind here is
passing around some flag to make sure that bootm doesn't get this new
behaviour.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140521/0fa01f6e/attachment.pgp>