[U-Boot] zImage on ARM

[Wolfgang Denk]

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 can come up with position independent payload, you still need
> > > > the entry point (then probably in terms of offset relative to the
> > > > current image address).
> 
> The entry point for an ARM kernel image is always at an offset of 0.

Fine.

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


> We are working on the ability for a single kernel binary image to work 
> on different SOCs.  However, on one SOC, the RAM is physically located 
> at 0xc0000000, on another that might be 0x02000000, on another it is 
> 0x00000000, etc.  While zImage could be loaded at any of those addresses 
> and executed there, in the uImage case the load address has to be 
> provided at mkimage time.  That makes the distribution of a single 
> uImage impossible for varied targets while distributing the 
> corresponding zImage would just work.

Understood.  But a relative load address and relative entry point
could solve this issue?

> We need to be able to provide the load address at _load_ time instead of 
> at _mkimage_ time.  In all cases, the entry point for the ARM kernel is 
> always at offset 0 from the load address as mentioned above.

Would that still be needed if the load address war relative to the
start of system RAM?

> > >  My understanding of the ARM zImage uncompress code is that the entry
> > >  point would basically be at offset zero once loaded in memory, for all
> > >  targets/boards.
> > 
> > Can we not omit that code, and use the one we already have in U-Boot?
> > Why increasing the Linux kernel image size (and thus flash footprint,
> > load time, etc.) without need?
> 
> Sorry, I'm not following you here.

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.

> > >  I don't know enough about the ARM kernel's ramdisk code to comment on
> > >  whether or not it could be uncompressed directly from flash into RAM;
> > 
> > It can. We've been doing this for many years. Just never managed to
> > get the patches accepted for mainline.
> 
> 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.

> > The most recent attempt can be seen here:
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/53969
> > 
> > As before, RMK smashed this with his "I don't see any reason for this."
> 
> And I agree with him.  You don't need it because you may achieve better 
> system resource usage by mapping an MTD block device onto a squashfs 
> image instead.  And that would work for either NOR or NAND flash which 
> is not the case for the patch referenced above.

Just because there is methods that work well in most of the cases is
IMOP not a reason to ban support for a use case that is useful in some
other cases, especially if the code needed to support it is trivial
and does not hurt anybody.


Right now I am spending time trying to understand your requirements
and trying to come up with solutions that satisfy your needs. Note
that I do not try to argue that "you may achieve better system
resource usage" by using uImage files as they were designed, i. e.
with omitting the kernel's copy and uncomress code from the images.
At least I do not try to use this argument to kill alternative
approaches without even trying to understand why they might be useful.


> > You need a command that does not do this, but eventually receives
> > these parameters from somewhere else (command line?), but still passes
> > all required information like ATAGs and/or device tree, kernel command
> > line etc. to the image.
> 
> Exact!

I think separating image-specific information from the image is a bad
idea.  If we could agree to use relative addresses (offsets) I'd feel
much better.

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
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.