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