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

[Scott Wood]

On 03/22/2013 09:29:04 AM, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/22/2013 10:03 AM, Wolfgang Denk wrote:
> > Dear Tom,
> >
> > In message <514C4BE8.10508 at ti.com> you wrote:
> >>
> >> It seems like we're going around and around with one point not
> >> being addressed.  When using 'go', how do you know the size to
> >> flush?  And since Scott is talking about performance testing
> >> apps, the cache should not be disabled (unless we expect all
> >> standalone apps to enable the cache, in which case we need to
> >> provide something in the jump table to make that easy and
> >> document this change).
> >
> > I also wonder about this. To me it appears much easier to use a
> > IH_TYPE_STANDALONE image, which 1) provides the needed size
> > information and 2) can be used with bootm, so the required
> > additional steps (flush caches, release CPU) can be handled in
> > bootm subcommands.
> 
> But that then circles us back to Scott's other point of "go" is broken
> then and it is the recommended way to start standalone applications.
> 
> Now, if we want to change things and say that no, you can't just run
> totally raw binaries reliably with "go" but instead need to throw some
> form of header on top of them, how portable, really, is mkimage?
> We've just made that a required part of the work-flow for anyone doing
> development that's not producing ELF or something else already
> boot*'able.  That might be a rather large pool I suspect.
> 
> Scott, part of the problem here is that we have multiple cores, yes?
> Say core0 is the one that read things in from NOR to DDR, core1 is the
> one that will be running things.  How about we make flush_cache depend
> on CONFIG_MP || CONFIG_CMD_CACHE_FLUSH ?  It's a likely required often
> thing for CONFIG_MP systems and anyone else that needs it can opt-in.

Multiple CPUs may make it more likely to see problems on some hardware,  
but architecturally on PPC the flush is required even with a single  
CPU.  Icache fetches won't snoop the dcache.

Can we have it depend on a new config symbol, so it's not bloating  
anyone's U-Boot who doesn't want it, and deal with improvements to  
recommended standalone app workflow as a separate issue?  We're not  
talking about a huge amount of code here, just exposing functionality  
that U-Boot already has internally.

-Scott