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

[Stephen Warren]

On 11/07/2011 02:59 PM, Marek Vasut wrote:
>> On 11/07/2011 02:04 PM, Marek Vasut wrote:
>> ...
>>
>>>> The problem with this new approach is that Linux kernel images are NOT
>>>> freely relocatable.  They do have a fix entry point, even if this is
>>>> not an absolute address, but a relative one.  The natural way to
>>>> handle this is exactly that:  add support for images with relative
>>>> )offset based) load and entry point addresses.
>>>
>>> You have that runtime patching stuff in linux-arm-kernel now, there
>>> should be no problem with that anymore actually. So basically I
>>> understood there was an agreement to make special uImage/fitImage which
>>> ... oh doh, here is where I'm getting lost. Is it that the kernel will
>>> still be copied to address, but a relative one to where uImage is loaded
>>> -- and the entrypoint will be relative to that same address?
>>
>> U-Boot scripts load uImages to some script-defined address.
>>
>> (At least for kernel images) when running the bootm command, U-Boot will
>> then copy the kernel image from whatever place the script loaded it to
>> whatever value the "load address" uImage header field contains.
>>
>> With my first set of patches, I created IH_TYPE_KERNEL_REL (as a pair to
>> IH_TYPE_KERNEL) where the load address in the header is not an absolute
>> address, but rather is interpreted as an offset from "the start of
>> SDRAM", whatever that is for a particular board. The idea was that while
>> there could not be a single absolute load address that was valid for all
>> ARM SoCs, perhaps there could be a single offset from SDRAM that was
>> valid for all ARM SoCs. With this scheme, U-Boot's bootm command would
>> still perform the same copy I mentioned above. This applied equally to
>> "legacy" uImages and FIT images.
>>
>> With the new set of patches I posted, I didn't add any new uImage
>> formats, but instead defined a single load address value (0xffffffff) as
>> meaning "no load address specified", or "load address irrelevant". In
>> this case, when bootm processes the kernel image, it re-writes the load
>> address of the image to be equal to wherever the script actually ended
>> up loading the image. Hence, the kernel image is already in the desired
>> location, and the copy of the kernel is avoided.
> 
> But the kernel ends at offset where uImage was loaded to + few bytes 
> (sizeof(uImage header)), right? 

I assume you meant "starts" not "ends" right?

Yes, the payload data is actual_load_addr + sizeof(uimage header).

Looking at the implementation of image_fixup_load_entry() in my patches,
I admit this is only correctly accounted for in the "ep" case, not the
"load" case.

That said, the bootm command (see file cmd_bootm.c, function
bootm_load_os(), case IH_COMP_NONE) accepts the image as already being
correctly placed if either the uImage header or the image itself is
already located at location in the uImage's headers' load address field.
I could see an argument that this is in fact a bug.

>> In my opinion, the new scheme is simpler, more correct, more flexible,
>> more efficient (fewer copies of the kernel data)..., for the reasons I
>> mentioned a couple emails back.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------