[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 04:25 PM, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
> 
> In message <alpine.LFD.2.02.1111071736280.3307@xanadu.home> you wrote:
>>
>>> 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.
>>
>> No.  Please, we're trying to remove _all_ hardcoded addresses from the 
>> kernel boot process, absolute or relative.  ...
> 
> I understand you are referring here to zImages only. Correct?
> 
> Or will raw images (without the preloader) be fully relocatable, too?
> 
>>                                        ...  This is why zImage can be 
>> loaded at practically any address.  If uImage insists on having a 
>> relative offset encoded into it, this is slightly better than the 
>> absolute address but not by much.  Having the ability to use the _same_ 
>> uImage file and load it at _different_ addresses as specified by an 
>> argument to the load command is highly desirable...
> 
> Why is it so important to load it at specific (different) addresses
> when it can be started from any address?
> 
> Maybe this is a key point.  I simply fail to understand this.

Yes, that's probably the key point.

The central issue is that the memory map on different SoCs is different.
Equally, the U-Boot environment on different SoCs is different. This
means that the uImage /will/ be loaded at different addresses on
different SoCs, and equally nobody can necessarily definea single
address (absolute /or/ relative) where it could then be copied to
without trashing initrd/FDT/...

The only place that has full knowledge of the board's memory layout is
the U-Boot environment for that board, and hence I assert that the
U-Boot environment should define where to load the kernel (and initrd
and FDT), and if U-Boot must copy them, where to copy them to. In
particular, the creator of the uImage can't possibly pick these values
and expect them to work everywhere.

(as an aside, why do CC's keep getting dropped from all these emails?)

-- 
nvpublic