[U-Boot] zImage on ARM

[Nicolas Pitre]

On Mon, 13 Sep 2010, Wolfgang Denk wrote:

> Dear Nicolas,
> 
> In message <alpine.LFD.2.00.1009122338310.19366 at xanadu.home> you wrote:
> > 
> > > Maybe this should/could be addressed on the Linux side then? We don't
> > > have such problems on PwerPC, for example.
> > 
> > On the Linux side, we currently have a fully position independent 
> > zImage.  So you already can load it anywhere in RAM and branch to it 
> > with an offset of 0 from where it is loaded.
> 
> It has to be started in RAM, i. e. we cannmot run it from a ROM
> location?

If you want a ROMable zImage then you need to configure the kernel build 
for that case.  So it's either zImage in ROM with a fixed address, or 
position independent zImage in RAM.

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

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

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?

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.

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


Nicolas