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

Wolfgang Denk
2011-11-08T15:59:07Z

Dear Nicolas Pitre,

In message <alpine.LFD.2.02.1111080847540.3307@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@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.