[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

Hi Wolfgang,

On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A at mail.gmail.com> you wrote:
>>
>> > If SPL was to determing the relocation address, it would also have to
>> > read the environment, because there are a number of environment
>> > variables which can cause (dynamically) the relocation address to
>> > change.
>>
>> But this is not neccessarily the case for every board (or even every arch)
>
> Not neccessarily, but possible.
>
>> For those boards/arches which CAN calculate the relocation address (either
>> because it is fixed do to npn-variable RAM size, or fixed in relation to
>> the maximum RAM address) why should we prohibit a method of skipping the
>> redundant copy operation in a way which is 100% transparent to everyone
>> else?
>
> Can we please focus on unifying the boot process first, before we try
> to come up with micro-optimizations?

Agreed - And as I have stated before, this capability will come about as
a natural side-effect of the boot process unification (see current x86
repo ready for pull for illustrative example plus the INIT_CALL code I
am currently working on). So there is no need to look at hackish ways
to sidestep 'relocation' until then (at which point they won't be
needed anyway)

> Most of the people who complain here that they need to skip
> relocation are probably wrong in at least two accounts:
>
> - They are not actually talking about relocation at all.

Correct - The 'issue' is the additional in-RAM copy

> - They don't base their accessment on any real, measured timings, or
>  otherwise they would start optimizing completely different areas of
>  the code.

Yes - x86 achieved a not insignificant performance boost after I added the
ability to enable the SDRAM cache before copying U-Boot to RAM :)

Regards,

Graeme