[U-Boot] u-boot fails to uncompress a "gzip'ed -9" kernel

[Norbert van Bolhuis <nvbolhuis@aimvalley.nl>]

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);
>      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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>