On Fri, May 23, 2014 at 03:57:34PM -1000, Simon Glass wrote:
Hi Tom,
On 21 May 2014 10:46, Tom Rini trini@ti.com wrote:
On Wed, May 21, 2014 at 10:10:50PM +0200, Wolfgang Denk wrote:
Dear Tom Rini,
In message 20140521195824.GE1752@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.