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

[Stephen Warren <swarren@nvidia.com>]

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.

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.

-- 
nvpublic