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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
