[U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support

[Aneesh V]

Hi Wolfgang,

On Tuesday 17 May 2011 04:44 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4DD24BD6.5060608 at ti.com>  you wrote:
>>
>>> Would it be possible to do this even _before_ relocation, so to speed
>>> up memory accesses during relocation?  Of course, proper invalidates/
>>> flushes will be needed before jumping to the RAM address, but I guess
>>> this would save a bit of boot times?
>>
>> I intentionally kept it after  relocation to avoid un-necessary
>> complexities.
>
> Yes, I can understand this.  Do you plean to extend this to include
> relocation n a later step?
>
>> Relocation is a case of self-modifying code. In Harvard architectures
>> like armv7 there will be coherency issues unless we flush the entire
>> D-cache(range based operation may be equally or more expensive) and
>> invalidate the entire I-cache.
>
> I would not call this self-modifying code.

In ARM literature this kind of situations are also referred to as "self-
modifying". Here is an excerpt from ARM manual gloassary:

Self-modifying code
Is code that writes one or more instructions to memory and then executes 
them.

>
> Regarding the need to flush/invalidate caches when jumping to RAM:
> yes, we have to flush the D-cache to make sure all data actually has
> hit the memory. But there should be no need to invalidate the I-cache
> as we have never been fetching any instructions from this address
> range, so there cannot be any incorrect entries in cache.
>
> Or am I missing something?

This should be largely ok, but not fool-proof for all processors. For
processors such as Cortex-A9 that have speculative and out-of-order
execution there is no guarantee that any given memory location is not
cached at any given point of time as long as the cache is enabled. Here
is an excerpt from the ARMv7 manual(section B2.2.2):

"If a memory location is marked as Cacheable there is no mechanism by 
which it can be guaranteed
not to be allocated to an enabled cache at any time. Any application 
must assume that any Cacheable
memory location can be allocated to any enabled cache at any time."

>
>> So, in effect everything has to be flushed to memory before you jump to
>> the new location. There may be a small advantage because flushing from
>> cache allows for bursting to the DDR where as bursting is not possible
>> when d-cache is disabled. But I think this is not worth the trouble.
>
> Well, all the data copy will also use cached writes, which are much

You mean, you will do a range-flush on only the .text section's area?

> faster.  I think this will result in measurable time differences.

Relocation itself was not taking a huge amount of time in my
measurement sometime back. It was about 16 ms for OMAP4.

best regards,
Aneesh