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 <scottw...@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); > ZFREE(z, p, p->word.Nalloc * sizeof(inflate_huft)); > p = q; > } > ----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 >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot