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

[Scott Wood <scottwood@freescale.com>]

On 04/03/2013 09:02:15 AM, Jim Chargin wrote:
> I apologize for being so late with this question.
> 
> York Sun <yorksun <at> freescale.com> writes:
> 
> >
> > When we need the copied code/data in the main memory, we can flush  
> the
> > cache now. It uses the existing function flush_cache. Syntax is
> >
> > flush_cache <addr> <size>
> >
> > The addr and size are given in hexadecimal. Like memory command,  
> there is
> > no sanity check for the parameters.
> >
> 
> Are there symptoms for a specific system failure you can provide?

Generally you'd see code behaving in a way that is different than the  
instructions in memory (as seen by a load instruction) would suggest.   
Often it's obvious, such as an illegal instruction trap on on opcode  
that is valid, but it could be arbitrary depending on what the old  
contents of memory were (especially if there had been valid (but  
different) code there before).

> My problem is that when a stand alone application, which is copied  
> from NOR
> flash to DDR, is started with the "go" command, it sometimes  
> experiences a
> program check (illegal instruction) after a block of 32 zero bytes  
> "appears" in
> memory.

Maybe the old contents of memory contained a dcbz?  Or somehow confused  
a legimate dcbz to target the wrong address.

> I'm using a U-Boot for a custom Freescale P1022-based board,  
> currently based on
> the old 2010.12 U-Boot as patched by Freescale in their
> SDK_V1_0_20110429_ltib.iso. Unfortunately, upgrading to a more recent  
> version of
> U-Boot is not possible at this time, no more recent version is  
> available from
> Freescale and I don't have the resources to verify all their patches  
> apply
> correctly to a release directly from DENX.

You can find the latest Freescale U-Boot at:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/
git://git.freescale.com/ppc/sdk/u-boot.git

...though there's a good chance that you would not need anything from  
the SDK if you run the latest upstream U-Boot.  You'd still need to  
apply your own patches for the custom board, of course.

> (By the way, I would not leave the "flush_dcache();  
> invalidate_icache();" in
> do_go(), I merely found that for demonstrating a possible solution,  
> this change
> easier than switching to a stand alone app that starts with bootm, or  
> similar)

It seems reasonably likely that this is the cause of your problem; in  
any case, the flush is architecturally required.

-Scott