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

[Scott Wood]

On 03/21/2013 08:37:32 AM, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130321122923.GB26945 at bill-the-cat> you wrote:
> >
> > > Not really. Only a tiny fraction of users will ever run any  
> standalone
> > > applications, so please let's save the memory footprint for the
> > > overwhelming majority of users who do not need that.
> >
> > Well, can we run into this problem on ARM (v7 or v8) systems as  
> well?
> 
> Probably.
> 
> But I wonder what the exact usage szenario is that will trigger the
> problem.  If I understand correctly, this can only happen when you
> perform a (manual) memory copy (either between different locations in
> RAM, or from parallel NOR flash to RAM) of the code you are going to
> run.

Yes, the person who is seeing this problem is copying code from flash  
to RAM.

> As far as I understand all other ways to load any such code (over the
> network or from storage devices) already make sure to run  
> flush_cache()
> after any such load operation.

A lot of places seem to have it, but it seems not everywhere.  I'm not  
aware of such a flush for NAND reads.

We could instead try to make sure everything, including commands like  
"cp" and "mm", flush cache when they're done.  This approach is more  
user friendly, though it has a higher risk of missing some code path.

> Scott: is my understanding correct that you only need this because
> you are performing such memory copy ops manually?  From where / to
> where are you copying, and why?

As above it's from flash (I assume NOR) to RAM.  The "why" is to be  
able to run the code from RAM. :-P

> Thinking about alternatives:
> 
> - eventually we should discourage the use of "go"; it may be
>   conveniend when you know what you are doing, but if it's casuing
>   such problems we might be better off recommending to use
>   proper IH_TYPE_STANDALONE legacy images in combination with the
>   bootm command instead.

That or bootelf, sure.  I think there still should be some way to do it  
manually, though.  bootm/bootelf probably wouldn't work for this use  
case because it involves releasing other cores after the image is  
copied/flushed, but before u-boot gives up control on the boot core.

> - Also, instead of adding a new command, this could probably be
>   scripted; I guess this should be roughly equivalent?
> 
>   	setenv flush_cache 'dc off;ic off;dc on;ic on'

This assumes that we support those cache operations, that they affect  
all relevant caches (on 85xx it only flushes L1, but at least on newer  
chips L2 is relevant as well), and that there are no errata or  
architectural limitations to running with caches off.

-Scott