Nasty gunzip problem on MPC8313E-RDB

[Norbert van Bolhuis]

We have 2 MPC8313E-RDB REVA4 boards.

u-boot always fails to uncompress certain compressed files.
Either the board will hang or a checkstop occurs.
The problem occurs on both our MPC8313E-RDB REVA4 boards.
Probably memory is overwritten at the end of RAM (where
u-boot is relocated to). When using a jtag debugger no
problem occurs.

The stock u-boot (shipped by Freescale) has the problem,
any custom built u-boot (v2008.10 or v2009-rc3) also
has the problem.

I tested with u-boot.v2009-rc3 on another board (a PQ2FADS
board). The problem doesn't occur on this board.

I would like to find this problem and I could use all the
help I can get. I'm a bit stuck at the moment.

It's not the watchdog, nor the compiler toolchain. The
watchdog is completely disabled anyway and other compiler
toolchains (including the ones from Freescale) make no
difference.
I already tried to raise the u-boot malloc() area, it makes no
difference either.

when compressing using bzip2 (either --best or --fast) no problem
occurs.
The problem occurs only for gzip compressed files which have
one or more dynamic codes blocks and a final fixed codes block.
I made a very small one, it's attached. It's only 5802 bytes and
md5sum = d5e5a4c95451d256520f1b2a7ace8fa5
Btw. mostly gzip compressed files have dynamic codes blocks only.

This file is in fact a collection of random bytes compressed
with "gzip -9" and a u-boot header in front. If I load this
file into RAM (with tftp) and try to uncompress it (by trying to
bootm it) the problem always occurs.

If anybody is willing to try this file on a MPC8313E-RDB
and/or help me with this problem please reply.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: uImage
Type: application/octet-stream
Size: 5802 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090127/b3d8f843/attachment.obj>