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

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

[N. van Bolhuis]

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.

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

[Wolfgang Denk]

Dear "N. van Bolhuis",

In message <49746A3B.5070706@aimvalley.nl> you wrote:
> 
> 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.
...
> If I manually compress that same kernel with "gzip -8" and generate a
> uImage, it *does* work.

Are you sure it is only an issue of gzip compression, and not for
example of image sizes?

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

Are you sure?

> => run tird

<sarcasm>
Excellent information. Now we all know *exactly* which commands you
might be running :-(
</sarcasm>

> Filename 'uImage'.
> Load address: 0x2000000
> Loading: #################################################################
>           #####################################################
> done
> Bytes transferred = 1717604 (1a3564 hex)
...
> ## 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

So your compressed image is 1717540 bytes or 1.64 MB...

> ## Flattened Device Tree blob at 00400000
>     Booting using the fdt blob at 0x400000
>     of_flat_tree at 0x00400000 size 0x00002b7a
>     Uncompressing Kernel Image ...

And your device tree is at 4 MB. If compresses better than some 40%
than the uncompressed size of the kernel will exceed the 4 MB limit,
thus overwriting your device tree blob.

Are you *really* sure that your addresses are OK? What happens when
you move the DTB to a much higher address?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q: How do you spell "onomatopoeia"?
A: The way it sounds.

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

[N. van Bolhuis]

Hi Wolfgang,

thanks for your reply.


Wolfgang Denk wrote:
> Are you sure it is only an issue of gzip compression, and not for
> example of image sizes?
> 

The "gzip -8" compressed kernel, which does work, is obviously bigger
(vmlinux.bin.gz=1717766 (i.s.o. 1717544). Uncompressed size
is unchanged of course (vmlinux.bin=3646004)).

I have another "gzip -9" kernel which is smaller compressed
(vmlinux.bin.gz=1716893, vmlinux.bin=3646004). This one does work.

To be more sure I did some more tests:

I extended the working "gzip -9" kernel with dummy bytes, recompressed
it with "gzip -9" (now vmlinux.bin.gz=1717607, vmlinux.bin=3660385) and
it still works.

I added misc binary support to the problematic kernel, the resulting
image size are: vmlinux.bin.gz=1720890 vmlinux.bin=3654196. Now the
problem is gone.

I removed misc binary support from the above kernel, the
resulting image sizes are (again) vmlinux.bin.gz=1717544,
vmlinux.bin=3646004. The problem is there.


>> As far as I know my start/load memory addresses are ok.
> 
> Are you sure?
> 

no, therefore I included more details.

>> => run tird
> 
> <sarcasm>
> Excellent information. Now we all know *exactly* which commands you
> might be running :-(
> </sarcasm>
> 

tird=tftp 2000000 uImage;tftp 1000000 initramfs.igz.uboot;tftp 400000 
mpc8313erdb.dtb;bootm 2000000 1000000 400000

>> Filename 'uImage'.
>> Load address: 0x2000000
>> Loading: #################################################################
>>           #####################################################
>> done
>> Bytes transferred = 1717604 (1a3564 hex)
> ...
>> ## 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
> 
> So your compressed image is 1717540 bytes or 1.64 MB...
> 
>> ## Flattened Device Tree blob at 00400000
>>     Booting using the fdt blob at 0x400000
>>     of_flat_tree at 0x00400000 size 0x00002b7a
>>     Uncompressing Kernel Image ...
> 
> And your device tree is at 4 MB. If compresses better than some 40%
> than the uncompressed size of the kernel will exceed the 4 MB limit,
> thus overwriting your device tree blob.
> 
> Are you *really* sure that your addresses are OK? What happens when
> you move the DTB to a much higher address?
> 

The uncompressed size of the kernel is 3646004 bytes. I should have
mentioned that. So vmlinux.bin.gz=1717540 and vmlinuz.bin=3646004

Notice that in my new tests (see above) the vmlinux.bin.gz ends up 4
bytes more (1717544 bytes).

If the DTB is loaded at 600000 (6M) there's no difference.

In fact, if I load no DTB nor ramdisk the same problem occurs.

Regards,
Norbert.

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

[Norbert van Bolhuis]

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] 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.denx.de/pipermail/u-boot/attachments/20090127/b3d8f843/attachment-0001.obj 

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

[Tor Krill]

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@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
> 

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

[Norbert van Bolhuis]

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
>>
> 

[U-Boot] gunzip fails sometimes on MPC8343

[André Schwarz]

Scott, 

after uploading a new kernel with different size than our usual one I
now get either machine check during gunzip or gunzip fails with -3 on my
MPC8343 based MVBLM7 board.

Looks like you have already identified this problem in the past ...

Having a look a at my board config (MVBLM7.h) "git blame" tells me you
have already added BATL_GUARDEDSTORAGE to the IBAT6 entry.

I wonder if the BATL_MEMCOHERENCE makes any difference, since it is not
present on MPC8313ERDB.

When using an uncompressed kernel everything works fine - the issue is
clearly related to gunzip/inflate.

Any hints ?

Regards,
Andr?


[snip]

> 
> 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)



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich