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

[Dirk Behme <dirk.behme@de.bosch.com>]

On 08.02.2012 08:12, Simon Glass wrote:
> Hi Dirk,
> 
> On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> On 08.02.2012 00:36, Wolfgang Denk wrote:
>>> Dear Graeme Russ,
>>>
>>> In message
>>> <CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@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?
>>>
>>> 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.
>>> - They don't base their accessment on any real, measured timings, or
>>>  otherwise they would start optimizing completely different areas of
>>>  the code.
>>
>> Maybe they are looking at all areas (including the different ones) of
>> possible optimizations. And this thread is only one topic (note 1).
>>
>> Best regards
>>
>> Dirk
>>
>> note 1: I agree that the different topics will give more improvement. E.g.
>> [1]. Looking at that thread, unfortunately there is less discussion than
>> here while it will give more improvement :(
>>
>> [1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html
> 
> But turning on the cache should be trivial - it is already supported
> so you just need to implement the enable_dcache() function(?)

As I understand it, the issue seems to be the non-cache-aware drivers.

Best regards

Dirk

Btw.: If possible, let's discuss the cache topic in the cache thread ;)