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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Scott,

On Wed, 20 Mar 2013 11:43:15 -0500, Scott Wood
<scottwood@freescale.com> 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.

Hence my "and the like".

> > Full agrement.
> > 
> > > Is there an ARM multi-core target in U-Boot where U-Boot runs on
> > > one core but its payload shall be started on another, "un-booted",
> > > core, and which experiences issues due to the first core not  
> > flushing
> > > cache? If no existing target needs this, then this patch is  
> > useless. If
> > > there exists such a target and issue, then the right fix is not a  
> > shell
> > > command, it is a programmatic flush before the other core is  
> > enabled,
> > > so that it always sees correct RAM.
> > 
> > Agreed again.  As is, the patch was only adding dead code, as there
> > are no users of the feature.
> 
> 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...

But as I stated, you can, and should, include at least one board that
will need this command. So far, apparently, no board needs it.

> > <nitpick>
> > Also, it was added unconditionally which is a strict no-no as it just
> > adds code-bloat to everyone, without benefit.
> > </nitpick>
> 
> Only for boards which select CONFIG_CMD_CACHE... not sure how  
> fine-grained it makes sense to make it.

As a command, and useful at most to a few boards, it should have its
own option so that only the board(s) that will need it will have the
command list entry and associated code.

> -Scott


Amicalement,
-- 
Albert.