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

Albert ARIBAUD
2013-03-20T17:38:13Z

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.