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

[Wolfgang Denk]

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.

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


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

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.

However, your statements have been repeatedly on the edge of being
insulting.


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

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


> > And what I'm telling you is that you could probably have that for free
> > if you dropped the preloader.
> 
> But that is not what I want.

OK.  It's your decision.


> > I already NAKed these patches, and this discussion has made it clear
> > to me that this was a correct decision.  What you want is not uImages.
> 
> You are therefore denying me the ability to use the kernel according to 
> the use case I care about.  Maybe I should reconsider my willingness to 
> let you use raw kernel image then?  Because if you are not willing to 
> collaborate for the case I care about, why should I care about yours?


May I ask why exactly you cut off here, and NOT comment at all about
the following part I wrote:

| 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.
| 
| - It would be appreciated if we could get support for real uImages
|   (wrapping a raw kernel image) into Linux, then.
| 
| This way those who want to use zImages can do so, and those who prefer
| a different approach can have their ways, too.


Here I offered you exactly what you are asking for above.

But when I offer it, you just cut it off and continue to complain and
threaden and insult.

You tell me I was not willing to collaborate.

How do you describe your own attitude then?


Anyway.  My proposal is up.


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
In C we had to code our own bugs, in C++ we can inherit them.