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

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

A certain powerpc 2.6.28 kernel (which is by default compressed with
gzip -9) fails to load with u-boot v2008.10. It results in a machine
check stop. I'm testing on a MPC8313-RDB.

Btw. the linux-2.6.28/arch/powerpc/boot/wrapper script takes care of
compressing with "gzip -9".
On my host linux pc I'm using gzip 1.3.5 (2002-09-30).

If I manually compress that same kernel with "gzip -8" and generate a
uImage, it *does* work.

As far as I know my start/load memory addresses are ok.

If anybody has any clues, please let me know.

more details follow.
Here's the full output of when the problem occurs:

U-Boot 2008.10 (Jan 19 2009 - 12:21:43) MPC83XX

Reset Status: Software Hard, External/Internal Soft, External/Internal Hard

CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
Board: Freescale MPC8313ERDB
I2C:   ready
DRAM:  128 MB
Top of RAM usable for U-Boot at: 08000000
Reserving 307k for U-Boot at: 07fb3000
Reserving 520k for malloc() at: 07f31000
Reserving 68 Bytes for Board Info at: 07f30fbc
Reserving 104 Bytes for Global Data at: 07f30f54
Stack Pointer at: 07f30f38
New Stack Pointer is: 07f30f38
Now running in RAM - U-Boot at: 07fb3000
FLASH:  8 MB
NAND:  32 MiB
In:    serial
Out:   serial
Err:   serial
U-Boot relocated to 07fb3000
Net:   TSEC0, TSEC1 [PRIME]
=> run tird
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 10.10.4.142; our IP address is 10.10.77.77
Filename 'uImage'.
Load address: 0x2000000
Loading: #################################################################
          #####################################################
done
Bytes transferred = 1717604 (1a3564 hex)
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 10.10.4.142; our IP address is 10.10.77.77
Filename 'initramfs.igz.uboot'.
Load address: 0x1000000
Loading: #################################################################
          #################################################################
          ##########
done
Bytes transferred = 2051722 (1f4e8a hex)
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 10.10.4.142; our IP address is 10.10.77.77
Filename 'mpc8313erdb.dtb'.
Load address: 0x400000
Loading: #
done
Bytes transferred = 11130 (2b7a hex)
## Current stack ends at 0x07f30c00
*  kernel: cmdline image address = 0x02000000
## Booting kernel from Legacy Image at 02000000 ...
    Image Name:   Linux-2.6.28wa2
    Created:      2009-01-19  11:36:09 UTC
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    1717540 Bytes =  1.6 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    kernel data at 0x02000040, len = 0x001a3524 (1717540)
*  ramdisk: cmdline image address = 0x01000000
## Loading init Ramdisk from Legacy Image at 01000000 ...
    Image Name:   uboot initramfs
    Created:      2009-01-12  14:56:02 UTC
    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
    Data Size:    2051658 Bytes =  2 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    ramdisk start = 0x01000040, ramdisk end = 0x011f4e8a
*  fdt: cmdline image address = 0x00400000
## Checking for 'FDT'/'FDT Image' at 00400000
*  fdt: raw FDT blob
## Flattened Device Tree blob at 00400000
    Booting using the fdt blob at 0x400000
    of_flat_tree at 0x00400000 size 0x00002b7a
    Uncompressing Kernel Image ...

U-Boot 2008.10 (Jan 19 2009 - 12:21:43) MPC83XX

Reset Status: Check Stop, External/Internal Soft, External/Internal Hard



I already applied this patch:
http://www.mail-archive.com/u-boot at lists.denx.de/msg06709.html
it makes no difference.

I also applied this patch:
http://www.mail-archive.com/u-boot at lists.denx.de/msg04544.html
it makes no difference either.

Using "bzip2 --best" gives:
    Uncompressing Kernel Image ... BUNZIP2: uncompress or overwrite 
error -3 - must RESET board to recover

Using "bzip2 --fast" works, but it takes a long time for u-boot to
uncompress the kernel.

What's also strange is that some other 2.6.28 kernels (compressed with 
gzip -9) do work.

I probably have some kind of memory error, I don't see it though.

Unfortunately the problem doesn't occur when I start debugging it with a 
jtag debugger (lauterbach).

if anybody has any clues, please let me know.