Hi Tor,
Did I ever respond to your email, I forgot. Anyway it's nice to see others have the same problem also.
The root cause of this has been found, did you see this:
It's a CPU memory cache problem (I could have known).
details: 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)
#define CONFIG_SYS_IBAT7L (0)
Tor Krill wrote:
Hi Norbert,
I missed the start of this thread. So my apologies if im barking up the wrong tree :)
We had problems uncompressing zImages on our 8313 board. But always suspected some memory timing issues, or perhaps some strangeness in 8313.
I tracked our problems down to a specific line in lib_generic/zlib.c And by adding a small delay there our problems went away. (I know this is not good practice. But with time limited that is what you do.)
Inlined (Pasted) is our patch that solved our problem:
----8<------------------------------------------------------------- --- [74f22482c362bbc50f1188bd5d31203e7995a9b4] zlib.c +++ [88e71e289d0241baaa9db0624b98f00b5f1774b5] zlib.c @@ -1604,6 +1604,7 @@ while (p != Z_NULL) { q = (--p)->next;
udelay(10);----8<-------------------------------------------------------------
/Tor
On Tue, 2009-01-27 at 11:05 +0100, Norbert van Bolhuis wrote:
This is a MPC8313E-RDB board problem. We have 2 REV A4 boards.
I can reproduce this problem on both of the MPC8313E-RDB boards with any version of u-boot with a compressed file which contains 1 or more dynamic codes blocks and a final fixed codes block.
I have a 5k gzipped file for which the problem (already) occurs.
I could test on a PQ2FADS board. The problem doesn't occur on this board.
I did some memory tests (which I should've done a bit earlier) and the same problem (soft reset due to checkstop) occurs.
I'll make a new thread for this.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot