[U-Boot] zImage on ARM

[Nicolas Pitre]

On Mon, 13 Sep 2010, Wolfgang Denk wrote:

> Dear Nicolas Pitre,
> 
> In message <alpine.LFD.2.00.1009130917470.19366 at xanadu.home> you wrote:
> > 
> > > So your problem could be solved if we were able to specify a relative
> > > load address (relative to the start of system RAM), and relative
> > > entry point address (offset into image) ?
> > 
> > Yes, that would work.
> 
> Then let's discuss how we can get there.

Fine with me.

> > > Why do we have to include the uncompression and relocating code in
> > > each Linux kernel image, when we already have it in U-Boot?
> > > I would like to be able to omit this on resource-restricted systems.
> > 
> > Because U-Boot is not the only bootloader out there.  And all the other 
> > bootloaders (lilo, grub, syslinux, redboot, etc.) rely on the zImage's 
> > ability to self-decompress, and no bootloader specific tool like mkimage 
> > is required to postprocess the result.
> 
> I agree that it makes perfect sense to support all these restricted
> boot loaders. But why not allow to use the features of U-Boot,
> especially in cases where resources are tight?

I don't mind having the possibility to use U-Boot features, as long as 
U-Boot lets me use a "standard" zImage if I choose to.

And the use cases we're contemplating don't have tight resources.

> > Yet the reverse argument could be made about U-Boot: why include the 
> > decompression code in U-Boot when we already have it in zImage?
> 
> Because ARM is not the only architecture out there. And other
> architectures do not have such problems.
> 
> Because Linux is not the only operating system out there. And other
> operating systems don;t provide such fancy OS images with built-in
> decompressors.
[...]

We go in circle now.  I want a single kernel binary that multiple 
bootloaders can use.  You want a single bootloader that multiple OSes 
can use.  So it is best to simply accept that there are different yet 
still valid usage patterns.

> I kinf of feel ARM comes with a one-size-fits-all approach. This is
> not true for embedded systems in general.

Well, from my perspective it seems that ARM Linux is simply trying to be 
close to X86 Linux in this regard, and not stick to one-size-fits-all 
bootloader.  So this is another circular argument.

> > Still, you have the possibility to use the Image result (without the z) 
> > which is uncompressed and non-relocatable (has to be loaded at the 
> > appropriate address), and encapsulate that into a uImage if you wish for 
> > U-Boot to decompress.
> 
> That's fine with me. May we plase have a make target for this in the
> mainline Linux kernel tree?

I should be able to arrange that.  In exchange, may we please have the 
option for booting a zImage directly in U-Boot?

> > > > And even better: rather than decompressing a ramdisk from flash, this is 
> > > > even more efficient to set an MTD partition for it and use the ramdisk 
> > > > content directly from flash as needed through the mtdblock device and 
> > > > not pin down memory for it needlessly.
> > > 
> > > This may work in some cases. I agree that in almost all cases a
> > > classical ramdisk image is not an optimal solution. However, it has
> > > the charm that the underlying storage (the partition in flash) is not
> > > used while the system is running, so you can overwrite it with a new
> > > image.  Few other setups allow this.
> > 
> > I wouldn't trust such a setup with regards to resilience against 
> > unexpected power failure.  But that's a topic for another discussion.
> 
> Agreed.  But then, do you accept this argument as valid reason to use
> a ramdisk image in flash?

Sure, why not.  However, I'd still suggest that you access it through a 
MTD block device.  This would be cleaner and would also work with NAND 
as well as with NOR.  Right now the kernel assumes a floppy device for 
this, but modifying it to accept an MTD device in init/do_mounts.c 
should be trivial.


Nicolas