From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aneesh V <aneesh@ti.com>
Date: Fri, 12 Aug 2011 17:46:41 +0530
Subject: [U-Boot] d-cache enable
In-Reply-To: <20110812134151.46d0e47c@lmajewski.digital.local>
References: <1312197486-31712-2-git-send-email-aneesh@ti.com>
	<1312889691-22701-2-git-send-email-aneesh@ti.com>
	<20110809164107.0dd85472@lmajewski.digital.local>
	<4E45078D.4060300@ti.com>
	<20110812134151.46d0e47c@lmajewski.digital.local>
Message-ID: <4E4519A9.3080804@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Lukasz,

On Friday 12 August 2011 05:11 PM, Lukasz Majewski wrote:
> Hi Aneesh,
> 
> On Fri, 12 Aug 2011 16:29:25 +0530
> Aneesh V <aneesh@ti.com> wrote:
> 
>> Hi Lukasz,
>>
>> On Tuesday 09 August 2011 08:11 PM, Lukasz Majewski wrote:
>>> Dear all,
>>>
>>> As we know dcache is now enabled in u-boot.
>>>
>>> I'm trying to make the S5P Goni target working with d-cache enabled.
>>> There are some patches and ideas appearing on the list (e.g.
>>> http://patchwork.ozlabs.org/patch/109199/ made by Aneesh V)
>>>
>>>
>>> I'm currently using the u-boot/master branch,
>>> SHA1: d26a82023af5771462f7223241ed18cfb7965f71 
>>>
>>> After some research I can say that flush_dcache_all() and
>>> invalidate_dcache_all() are working(at least on my target).
>>>
>>> However I'm planning to use the "range" versions:
>>> 	flush_dcache_range((unsigned long) (buf), sizeof(buf));
>>> 	invalidate_dcache_range((unsigned long) (buf), sizeof(buf));
>>>
>>> Those versions are not working on the Cortex-A8 (armv7) GONI target.
>>> I'd like to ask if anybody was trying to use those functions
>>> (defined at cache_v7.c) on other armv7 targets? 
>>
>> I have tested cache on OMAP3(Cortex-A8) and OMAP4(Cortex-A9). Why do
>> you think it's not working for you. Did you run some tests? If so,
>> what was the result? Are you enabling only L1 or both L1 & L2? Can
>> you try the attached crude patch for testing caches. You might have
>> to change the addresses according to your platform. If you could run
>> it, let me know the results.
>>
>> best regards,
>> Aneesh
> 
> It is embarrassing to admit, but I've __wrongly__ assumed that *_range()
> functions are accepting the start address and range for
> invalidation/flushing. 
> 

There is already some confusion around that. As pointed out by Reinhard
some MIPS implementations actually interpret the parameters that way.
But at least for arm, it's [strat, stop).

> Yes, they are working when I've realized how to use them :-).

Good to know that.

best regards,
Aneesh