From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 21 Mar 2013 13:07:55 -0500
Subject: [U-Boot] [RFC] command/cache: Add flush_cache command
In-Reply-To: <20130321185837.668395b9@lilith> (from
	albert.u.boot@aribaud.net on Thu Mar 21 12:58:37 2013)
References: <20130320191519.GO25919@bill-the-cat>
	<1363808165.25034.14@snotra> <20130320231157.4f312493@lilith>
	<1363818951.25034.28@snotra> <20130321185837.668395b9@lilith>
Message-ID: <1363889275.31522.12@snotra>
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/21/2013 12:58:37 PM, Albert ARIBAUD wrote:
> Hi Scott,
> 
> On Wed, 20 Mar 2013 17:35:51 -0500, Scott Wood
> <scottwood@freescale.com> wrote:
> 
> > On 03/20/2013 05:11:57 PM, Albert ARIBAUD wrote:
> > > Hi Scott,
> > >
> > > On Wed, 20 Mar 2013 14:36:05 -0500, Scott Wood
> > > <scottwood@freescale.com> wrote:
> > >
> > > > On 03/20/2013 02:15:19 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.
> > > >
> > > > It's also an issue with using the "cpu <n> release" command.
> > > >
> > > > > And in this case you aren't better served by say bootelf ?
> > > >
> > > > That wouldn't handle the "cpu release" case.  In any case, "go"
> > > exists
> > > > and is currently the recommended way to launch a standalone
> > > application
> > > > in doc/README.standalone.
> > > >
> > > > > > It's a user command!  How can it be dead code?  I don't  
> know of
> > > a
> > > > > > way to include a human user in a patchset...
> > > > >
> > > > > Can you hightlight what exactly causes the world today to go  
> off
> > > and
> > > > > fail?  Is the hello_world example app sufficient in this case  
> or
> > > do we
> > > > > need something much larger?
> > > >
> > > > A user inside Freescale is running standalone performance test  
> apps,
> > > > using both "go" and "cpu <n> release" (since the test needs to  
> run
> > > on
> > > > all CPUs).  They are seeing cache problems running on a T4240 if
> > > they
> > > > don't have this flush.  This flush is architecturally required
> > > between
> > > > modifying/loading code and running it.
> > >
> > > Still, why make it a shell command? Since this user needs a flush  
> with
> > > "go" and "cpu release", then we should add a programmatic global  
> cache
> > > flush in the "go" and "cpu release" commands.
> >
> > Why add any new commands?  They could all be subcommands of bootm!  
> :-)
> 
> I did not say "subcommand", I said "programmatic" -- precisely, I  
> don't
> like the idea that a specific command or command form is needed to
> avoid a situation that can be avoided automatically.

bootm subcommands are programmatic in normal use cases.

> > Really, instead of adding one command, you want to modify *two*
> > commands to do the same thing separately, which involves changing  
> the
> > syntax of both commands to accept memory range information?
> 
> There is no need to change any syntax.

Then how would we know what range to flush?

-Scott