From mboxrd@z Thu Jan  1 00:00:00 1970
From: York Sun <yorksun@freescale.com>
Date: Wed, 20 Mar 2013 12:40:05 -0700
Subject: [U-Boot] [RFC] command/cache: Add flush_cache command
In-Reply-To: <20130320191519.GO25919@bill-the-cat>
References: <1363724992-9803-1-git-send-email-yorksun@freescale.com>
	<20130319230141.72357073@lilith>
	<5148E1A5.4030502@freescale.com> <1363735959.16671.38@snotra>
	<20130320145927.2031b913@lilith>
	<20130320145836.C129020063B@gemini.denx.de>
	<1363797795.25034.0@snotra> <20130320191519.GO25919@bill-the-cat>
Message-ID: <514A1095.3010805@freescale.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

On 03/20/2013 12:15 PM, Tom Rini wrote:
> On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote:
>> On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote:
>>> Dear Albert,
>>>
>>> In message <20130320145927.2031b913@lilith> you wrote:
>>>>
>>>> I do understand what it does, but I still don't get why it should be
>>>> done, since precisely payload control transfer happens through
>>> bootm and
>>>> the like which already properly flush cache.
>>
>> It doesn't always happen through bootm.  Standalone apps use the
>> "go" command.
> 
> So, to try and be a bit more verbose about this, for U-Boot applications
> which use 'go', we still need to ensure cache coherence, which is why
> bootm does a cache flush, we need some way to flush in this case.
> 
> And in this case you aren't better served by say bootelf ?

We have a user's case to release secondary cores to run user's
application which is in main memory. The secondary cores don't
necessarily share the cache with the core u-boot is running, depends on
hardware implementation. Without flushing the cache, those cores don't
have the correct code to fetch.

York