[U-Boot] [RFC] command/cache: Add flush_cache command

[Scott Wood]

On 03/20/2013 02:59:19 PM, Tom Rini wrote:
> On Wed, Mar 20, 2013 at 02:36:05PM -0500, Scott Wood 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 at 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.
> 
> Hadn't seen that command before, where is it?

common/cmd_mp.c

> > >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.
> 
> OK, so this does sound like a real need / use for it, and if we added
> the granularity of CONFIG_CMD_CACHE_FLUSH or similar, it would be
> reasonable to turn it on to a large number of boards for a small space
> savings (so lets not).  My next concern is that this needs build  
> testing
> (and some inspection) on say ARM where we have a weak flush_cache
> already.  But perhaps the right answer is to say it doesn't make sense
> to add CONFIG_CMD_CACHE on an architecture which doesn't already  
> provide
> flush_cache, so drop the weak one from this patch.

flush_cache() is already called from generic code, so we should be ok  
just dropping the weak function.

-Scott