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

[Tom Rini]

On Fri, May 23, 2014 at 03:57:34PM -1000, Simon Glass wrote:
> Hi Tom,
> 
> On 21 May 2014 10:46, Tom Rini <trini at ti.com> wrote:
> > 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.
> 
> Unless I'm imagining it, some years ago I could type 'make fit_image'
> or similar for the kernel and get an image ready to boot. Did someone
> remove that feature from Linux and expect the number of steps needed
> to build a kernel to stay the same?

It wasn't in mainline, I'm fairly certain.  Or maybe it was an arch/ppc
thing that got dropped along the way.

> It surprises me the lengths to which people are going to try to
> shoehorn .dtbs, compression, multiple dtbs, multi-arch etc. into the
> kenel zImage format. The decompression header is ugly, plus it is
> slower than doing these things in U-Boot.

Well, with arm64 the kernel is just getting out of the business, hence
booti (or however we add Image support) and not do the zImage dance.

-- 
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/20140524/96dcde0c/attachment.pgp>