Dear Stephen Warren,
In message 4EBBF894.2000409@nvidia.com you wrote:
I don't like this name. "ANYLOAD" doesn't really make sense to me; I would interpet this as "U-Boot is free to load the image to any address it likes" - which is not what I think you mean.
I think ANYLOAD describes the situation correctly:
Sorry about the nitpicking, but I disagree.
For IH_TYPE_KERNEL, the image is physically loaded to whatever address the U-Boot environment/script loads it to, and then U-Boot relocates the image to the load address in the header if it's not already there (for uncompressed images).
In principle you are right, butthe terms you are using are not really correct. "Relocate" has a well-defined meaning, and includes the modification of addresses to adapt the relocated code to it's now position in memory. This is not what's going on.
U-Boot is given an image that is stored somewhere in memory (that's the "M" in "bootm": boot an image in memory), and it _copies_ (or loads) it to the "load address", eventually uncompressing it in this process.
With ANYLOAD, there is still a load address (wherever the U-Boot environment/script placed the image), yet any load address is accepted
No. In the zImage case, U-Boot does exactly NOT perform the loading (= copying) to the address given in the "load adress" header entry. It just leaves the image wherever it happens to bein memory. This is why I would like to call this "NO LOAD" - because no loading is done.
without relocation rather than just the one specified in the image header, so U-Boot always just skips the relocation.
In no case any relocation is ever done by the "bootm" command.
Put another way: extload/fatload load the image, and bootm just relocates/copies the image rather than loads it.
Wrong. "bootm" loads the image from it's original location in memory to the address given in the "load address" entry of the image header. That's why this field is named ih_load : "Data Load Address".
I guess "IH_TYPE_KERNEL_NOLOAD" would better match what the code is supposed to do.
I did consider that name too, but decided not to use it given my explanation above. I can rename it if you want though.
Please reconsider.
I deliberately didn't pick ZIMAGE, since I can't say for certain that only zImages are relocatable across all kernel image formats across all architectures. And note that ANYLOAD could well be applicable to non-Linux OSs for all I know; bootm appears to be able to boot a whole variety of other OSs, and I wouldn't be entirely surprised if at least one of them had fully relocatable images like ARM Linux kernel zImages.
No. "bootm" follows exactly the Linux kernel calling conventions in all details from passing specific values in specific registers, putting specific data at certain addresses / address ranges, etc. "bootm" is to boot Linux. I am not aware of any other OS that can be successfully booted with the "bootm" command (and ifso, it probably gould be started with "go" as well).
- if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) {
images.os.load = images.os.image_start;images.ep += images.os.load;- }
I'm not sure if we give up flexibility here without need.
Suggestion: IH_TYPE_KERNEL_NOLOAD images should read the entry point address from the image header, and interpret it as an offset relative to the image_start.
Isn't that exactly what the code is doing; note ep is calculated as += not just =.
Oops. I have to admit that I overlooked the +=. But that - where is the value set that you are adding to?
...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ?
Perhaps "(no relocation)"?
Definitely not. There is no relocation involved anywhere here.
Best regards,
Wolfgang Denk