summaryrefslogtreecommitdiff
path: root/config.mk
diff options
context:
space:
mode:
authorDave Liu <daveliu@freescale.com>2006-11-02 18:05:50 -0600
committerKim Phillips <kim.phillips@freescale.com>2006-11-03 19:42:22 -0600
commit90f30a710a3c619b5405860a686c4ddfc495d4b6 (patch)
treeef3748781267f86bddbfc738294d44c583710d12 /config.mk
parentbf0b542d6773a5a1cbce77691f009b06d9aeb57d (diff)
downloadu-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 'config.mk')
0 files changed, 0 insertions, 0 deletions