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

[Aneesh V]

Hi Wolfgang,

On Tuesday 17 May 2011 05:58 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4DD264B7.9060304 at ti.com>  you wrote:
>>
>> In ARM literature this kind of situations are also referred to as "self-
>> modifying". Here is an excerpt from ARM manual gloassary:
>
> I see. Thanks.
>
>>> 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?
>
> That should indeed be sufficient.
>
>>> 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.
>
> I was especially talking about the loading from external storage, not
> primarily relocation.  This will even be mnore important if we had
> (much) bigger images - like when loading an OS kernel as second stage
> payload instead of U-Boot.

Are you talking about enabling D-cache in SPL? Technically, this should
be possible as soon as DRAM is initialized(because internal RAMs
typically do not have enough memory for page-tables(16KB) in addition
to the SPL itself). But you might want to consider these.

1. We need to setup the page tables, invalidate the cache, enable it
and before jumping to kernel flush and disable it again. Is that all
worth just for speeding up the loading part? I think one must consider
DMA for loading the image instead.

2. What happens if the payload is U-Boot? You still have the problem of
flushing. Besides after reaching U-Boot do we setup MMU again or
not? If we decide to retain the page-tables setup by SPL then U-Boot
and SPL needs to align on the location of page-tables. This is
difficult because U-Boot dynamically determines the memory for
page-tables where as SPL doesn't have such intelligence.  If we decide
to do the MMU setup again, then it means setting up the page-tables
twice in the bootloaders!

best regards,
Aneesh