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

[Tom Rini <trini@ti.com>]

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 ?

Assuming that no, it's not, we have a real example where we need this.
So please make sure to update the README with the new command
CONFIG_CMD_CACHE sets.

> 
> >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...

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130320/42471f00/attachment.pgp>