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

Simon Glass sjg at chromium.org
Wed Feb 8 08:12:05 CET 2012


Hi Dirk,

On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
> On 08.02.2012 00:36, Wolfgang Denk 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?
>>
>> 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(?) I think.

Also make sure that the I-Cache is on as early as possible. Relocation
is done with the d-cache off so is slow. Takes about 40ms for me from
memory, but we do have things which can speed it up. But d-cache
matters more than just about anything.

Regards,
Simon

>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


More information about the U-Boot mailing list