[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Nicolas Pitre]

On Tue, 8 Nov 2011, Wolfgang Denk wrote:

> Dear Nicolas Pitre,
> 
> In message <alpine.LFD.2.02.1111080847540.3307 at xanadu.home> you wrote:
> > 
> > > In both cases the _kernel_ image is not position independent. It must
> > > be loaded to a specific address and started at a specific entry point.
> > > The exact information where these are is known at built time, and
> > > somehow encoded in the images (here in the image header, there in the
> > > preloader code).
> > > 
> > > Is this summary correct so far?
> > 
> > No.  Your statement that says "The exact information where these are is 
> > known at built time, and somehow encoded in the images (here in the 
> > image header, there in the preloader code)" is false.  None of that 
> > information is known at build time nor encoded in the preloader as you 
> > call it.
> 
> Hm...  You wrote in <alpine.LFD.2.02.1111071840080.3307 at xanadu.home>:
> 
> | The role of the zImage code is to figure out at run time about its 
> | position in RAM, deduce where the RAM starts, relocate itself if it is 
> | in the way of the decompressed kernel, and decompress the actual kernel 
> | in its final location (RAM start + TEXT_OFFSET) without having to 
> | relocate the bigger decompressed data. ...
> 
> To me this seems as if the "final location (RAM start + TEXT_OFFSET)"
> is known at build time - ok, only in form of a _relative_ (to the
> start of system RAM) address, but nevertheless.

That is correct.  We used to encode RAM start in the kernel as well, but 
that part is now runtime determined, based on the position of the code.

> > > This is not quite correct.  The _kernel_ code has a fixed address.
> > > It is the preloader code which can be started from any address.
> > 
> > The preloader is part of the kernel, whether you like it or not, and it 
> > is not going away any time soon.  That would help the conversation if 
> > you accepted it as such.
> 
> The preloader is a part of the Linux kernel source tree, but wether I
> use it with the Linux kernel or not is my own choice.  Or is it
> mandatory to use it ?

No, it is not.

> Why the heck are you just so opinionated and not willing to even
> remotely consider that other people have other ideas or needs?

Unfortunately I feel the same way towards you.  however I never 
dismissed the fact that other people have different ideas or needs.  
I'm simply trying to convince you that I (and others) have other ideas 
or needs.  But this is going in circles.

> It seems you don't even notice that I don't ever argument against
> using zImages - my opionion is if it's useful for some and doesn;t
> hurt others so let them use it.

I'm very glad to know that.

> > OK, fine.  I don't really care about uImage if it cannot accommodate our 
> > needs.  I thought that the -1 extension was a pretty agile and 
> > non-obstrusive way to make u-Boot more flexible and versatile, and not 
> > only for Linux loading.  Failing that, can we have support for loading 
> ---------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > zImage directly then?  There are precedents in the upstream u-Boot for 
> --^^^^^^^^^^^^^^^^^^^^^
> > doing that on other architectures already.
> 
> Let's remember your question here.  Actually I answered it already in
> my previous message, explicitly and clear.  I don't understand why you
> intentionally ignore it.  See below.

This wasn't intentional.  A serious oversight on my part for sure.  In 
which case I apologize for missing your suggestion.

> > I never intended to prevent raw images from being used with uImage.  
> > This is however not the use case I'm looking after.  That doesn't 
> > mean that because I'm interested in a different usage model than 
> > yours that I'm going to actively prevent raw Image from being used.  
> > I see obvious limitations with it, but if that is what you want then 
> > by all means just use that.  We cannot say as much from the u-Boot 
> > side for the use case I'm interested in though.
> 
> Good.  So there should be room for different implementations that
> serve different needs or interests.

Indeed!

> | I suggest the following:
> | 
> | - I will apply Stephen's previous patches to support relative images
> |   as they are useful for people who want to use "proper" uImages
> |   (containing a raw kernel image as payload) on different boards /
> |   architectures.
> | 
> | - If you want to boot zImages (with the kernel wrapper included and
> |   thus fully relocatable), then please feel free and submit patches to
> |   add support for booting zImage format in U-Boot.  Then you get what
> |   you want, and you can use zImages directly, without the 64 byte
> |   uImage header that is only hindering for your usage mode.

Good Lord!  I definitively missed this.  Per a live conversation with 
Stephen, I was under the impression this would have been a quite 
intrusive change, and my impression is that such things were attempted 
in the past with no success.  I'm definitively in favor of such a 
solution.

> | - It would be appreciated if we could get support for real uImages
> |   (wrapping a raw kernel image) into Linux, then.

That certainly can be done, ideally in an architecture independent way. 
A dedicated kconfig menu for u-Boot options and flavors could be common 
to all architectures, and this could then be maintained outside of the 
ARM directory.  Someone would have to step forward and volunteer for 
that role.


Nicolas