[U-Boot] zImage on ARM

[Wolfgang Denk]

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.

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

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

Because there is a plethora of requirements out there, including
systems that require to stroe not only a single, but two (or sometimes
even more) kernel images, and resources are expensive.


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

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

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HR Manager to job candidate "I see you've had no  computer  training.
Although  that  qualifies  you  for upper management, it means you're
under-qualified for our entry level positions."