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
