Dear Nicolas Pitre, In message <alpine.lfd.2.02.1111080847540.3...@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.3...@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: w...@denx.de In C we had to code our own bugs, in C++ we can inherit them. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
