It seems like the root cause of this problem: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/53025/ match=nasty+gunzip+problem+mpc8313e+rdb
As a MPC8313E(-RDB) user I'm happy no more checkstops will occur for some kernels. I'm even more happy I took over the BAT settings from MPC8315ERDB.h for our custom MPC8313 board (MPC8315ERDB.h doesn't have this problem as far as i can tell)
[snip]
Scott Wood wrote:
This board currently sets DBAT6 to cover all of the final 256MiB of address space; however, not all of this space is covered by
a device.
In particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is mapped at the far end of the address space.
In zlib, there is a loop that references p[-1] if p is non-NULL. Under some circumstances, this leads to the CPU
speculatively loading
from 0xfffffff8 if p is NULL. This leads to a machine check.
Signed-off-by: Scott Wood scottwood@freescale.com
Note that there are likely other board with the same issue.
include/configs/MPC8313ERDB.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index 0ef4eba..21aedee 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -544,7 +544,7 @@ #define CONFIG_SYS_IBAT5U (CONFIG_SYS_IMMR | BATU_BL_256M
| BATU_VS | BATU_VP)
/* SDRAM @ 0xF0000000, stack in DCACHE 0xFDF00000 & FLASH
@ 0xFE000000 */
-#define CONFIG_SYS_IBAT6L (0xF0000000 | BATL_PP_10) +#define CONFIG_SYS_IBAT6L (0xF0000000 | BATL_PP_10 |
BATL_GUARDEDSTORAGE)
#define CONFIG_SYS_IBAT6U (0xF0000000 | BATU_BL_256M |
BATU_VS | BATU_VP)
Scott/Kim,
We still have the same issue on MPC8349EMDS, MPC8349ITX and sbc8349, But the 8360EMDS, 8315ERDB, 837xEMDS(RDB) have not this issue. It is strange we leave the Flash as non-guarded attribute at 8349 board and 8313ERDB, When did we leave them to non-guarded?
Thanks, Dave