diff options
| author | Dave Liu <daveliu@freescale.com> | 2006-11-02 18:05:50 -0600 |
|---|---|---|
| committer | Kim Phillips <kim.phillips@freescale.com> | 2006-11-03 19:42:22 -0600 |
| commit | 90f30a710a3c619b5405860a686c4ddfc495d4b6 (patch) | |
| tree | ef3748781267f86bddbfc738294d44c583710d12 /disk | |
| parent | bf0b542d6773a5a1cbce77691f009b06d9aeb57d (diff) | |
| download | u-boot-imx-90f30a710a3c619b5405860a686c4ddfc495d4b6.zip u-boot-imx-90f30a710a3c619b5405860a686c4ddfc495d4b6.tar.gz u-boot-imx-90f30a710a3c619b5405860a686c4ddfc495d4b6.tar.bz2 | |
mpc83xx: Fix the incorrect dcbz operation
The 834x rev1.x silicon has one CPU5 errata.
The issue is when the data cache locked with
HID0[DLOCK], the dcbz instruction looks like no-op inst.
The right behavior of the data cache is when the data cache
Locked with HID0[DLOCK], the dcbz instruction allocates
new tags in cache.
The 834x rev3.0 and later and 8360 have not this bug inside.
So, when 834x rev3.0/8360 are working with ECC, the dcbz
instruction will corrupt the stack in cache, the processor will
checkstop reset.
However, the 834x rev1.x can work with ECC with these code,
because the sillicon has this cache bug. The dcbz will not
corrupt the stack in cache.
Really, it is the fault code running on fault sillicon.
This patch fix the incorrect dcbz operation. Instead of
CPU FP writing to initialise the ECC.
CHANGELOG:
* Fix the incorrect dcbz operation instead of CPU FP
writing to initialise the ECC memory. Otherwise, it
will corrupt the stack in cache, The processor will checkstop
reset.
Signed-off-by: Dave Liu <daveliu@freescale.com>
Diffstat (limited to 'disk')
0 files changed, 0 insertions, 0 deletions