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

[Marek Vasut]

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