[U-Boot] u-boot fails to uncompress a "gzip'ed -9" kernel
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@lists.denx.de/msg06709.html it makes no difference.
I also applied this patch: http://www.mail-archive.com/u-boot@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.
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
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.
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.
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.
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
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);----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
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
participants (5)
-
André Schwarz -
N. van Bolhuis -
Norbert van Bolhuis
-
Tor Krill -
Wolfgang Denk