[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 03:27 PM, Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201111072204.41980.marek.vasut@gmail.com> you wrote:
>>
>> 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?
> 
> Relative to the start of the system RAM.
> 
> See
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/117512/focus=119281
> 
> There are to interesting pieces of information nicely summarized:
> 
> 1) zImages are are relocatable. They should be loaded and started at
>    offsets between 32 KiB and 128 MiB in system RAM.
> 
> 2) Raw images (without the preloader) have to be started at a fixed
>    address, virt_to_phys(PAGE_OFFSET + TEXT_OFFSET), which usually is
>    at an offset of 32 KiB in system RAM (with very few exzceptions).
> 
> Both sitations can be handled perfectly find with offset addresses in
> the images.
> 
> When building the images from the kernel Makefiles, we can also make
> sure that such architecture specific addresses are correctly set.
> 
> This allows to boot such images without additional configuration or
> adjustment of load and start addresses in the boot loader.
> 
> 
> With Stephen's new approach, we could only use the zImage approach,

You can continue to use raw images; they just may not benefit from the
feature that allows them to be loaded at arbitrary addresses.

But, given your description of them, that isn't an issue, since they
need to be loaded at the specific absolute address they were built for
anyway. And if the description isn't true or becomes untrue later, and
raw images can be loaded at arbitrary locations, the "-1 load address"
technique will end up working just fine for raw images too.

> and we have to add additional configuration information to the boot
> loader.

Sorry, I'm unclear what "additional configuration information" needs to
be added to the boot-loader, and which of cases (1) and (2) that
statement applies to.

-- 
nvpublic