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

Simon Glass sjg at chromium.org
Sat May 24 03:57:34 CEST 2014


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 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.

Regards,
Simon


More information about the U-Boot mailing list