[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 04:59 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <1320860840-6347-1-git-send-email-swarren at nvidia.com> you wrote:
>> The legacy uImage format includes an absolute load and entry-point
>> address. When bootm operates on a kernel uImage in memory that isn't
>> loaded at the address in the image's load address, U-Boot will copy
>> the image to its address in the header.
>>
>> Some kernel images can actually be loaded and used at any arbitrary
>> address. An example is an ARM Linux kernel zImage file. To represent
> 
> You write: an example is...
> 
> Are there other Linux kernel image types in addition to zImage that
> have this property?

I'm sorry, I really don't know.

Note that I even specifically said /ARM/ Linux kernel zImage, because I
have no idea if zImage on other architectures is relocatable or not.

>> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates
> 
> 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:

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

With ANYLOAD, there is still a load address (wherever the U-Boot
environment/script placed the image), yet any load address is accepted
without relocation rather than just the one specified in the image
header, so U-Boot always just skips the relocation.

Put another way: extload/fatload load the image, and bootm just
relocates/copies the image rather than loads it.

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

> But then, I'd like "IH_TYPE_ZIMAGE" even better - assuming of course
> that only zImages are used here.  Are we sure about this?

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.

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

> This adds basicly no code size, an no effort if
> you don't want to use it (when running mkimage you will probably
> always use "-a 0 -e 0" anyway), but in case you ever need a different
> EP you have it, more or less for free.
> 
>> +	{	IH_TYPE_KERNEL_ANYLOAD, "kernel_anyload",  "Kernel Image (any load address)", },
> 
> ...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ?

Perhaps "(no relocation)"?

-- 
nvpublic