[U-Boot] Uncompress error with LZO
Hi
I get some misterious errors from time to time when decompressing an LZO compressed image. The output is as follows
zmx25> bootm 0x82000000 ## Booting kernel from Legacy Image at 82000000 ... Image Name: zmx25-gfx ifs Image Type: ARM QNX Kernel Image (lzo compressed) Data Size: 8181868 Bytes = 7.8 MiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 - must RESET board to recover resetting ...
RAM is from 0x80000000 to 0x83ffffff. The image was transfered using TFTP and has an uncompressed size of about 20MB. If I change something in the image so that the compressed data is different it works. If an image is "broken" it is always broken so the behavior is reproducable. I compress the image under windows using:
lzop.exe -f -9 zmx25-gfx-codesys.ifs lzop.exe -V
Lempel-Ziv-Oberhumer Packer Copyright (C) 1996 - 2010 lzop v1.03 Markus Franz Xaver Johannes Oberhumer Nov 1st 2010
lzop version: v1.03, Nov 1st 2010 lzop build date: Nov 1 2010 12:45:58
The image is then created with
mkimage.exe -A ARM -O QNX -T kernel -C lzo -n "zmx25-gfx-codesys
ifs" -a 0x80000000 -e 0x80000000 -d zmx25-gfx-codesys.ifs.lzo zmx25-gfx-codesys.lzo.img
Is someone out there who have observed similar behavior? Am I doing something wrong?
Regards Matthias
On Thu, Oct 18, 2012 at 02:24:20PM +0200, Matthias Wei?er wrote:
Hi
I get some misterious errors from time to time when decompressing an LZO compressed image. The output is as follows
zmx25> bootm 0x82000000 ## Booting kernel from Legacy Image at 82000000 ... Image Name: zmx25-gfx ifs Image Type: ARM QNX Kernel Image (lzo compressed) Data Size: 8181868 Bytes = 7.8 MiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 - must RESET board to recover resetting ...
RAM is from 0x80000000 to 0x83ffffff. The image was transfered using TFTP and has an uncompressed size of about 20MB. If I change something in the image so that the compressed data is different it works. If an image is "broken" it is always broken so the behavior is reproducable. I compress the image under windows using:
So you're saying that changing the source image results in good, or bad, behavior correct? Can you try taking a bad source image and using lzop on Linux instead?
On Thu, Oct 18, 2012 at 10:21:32AM -0700, Tom Rini wrote:
On Thu, Oct 18, 2012 at 02:24:20PM +0200, Matthias Wei?er wrote:
Hi
I get some misterious errors from time to time when decompressing an LZO compressed image. The output is as follows
zmx25> bootm 0x82000000 ## Booting kernel from Legacy Image at 82000000 ... Image Name: zmx25-gfx ifs Image Type: ARM QNX Kernel Image (lzo compressed) Data Size: 8181868 Bytes = 7.8 MiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 - must RESET board to recover resetting ...
RAM is from 0x80000000 to 0x83ffffff. The image was transfered using TFTP and has an uncompressed size of about 20MB. If I change something in the image so that the compressed data is different it works. If an image is "broken" it is always broken so the behavior is reproducable. I compress the image under windows using:
So you're saying that changing the source image results in good, or bad, behavior correct? Can you try taking a bad source image and using lzop on Linux instead?
There is one other possibility here which is that our lzop_decompress function and the kernel's lib/decompress_unlzo.c have diverged a bit and we could have a bug there.
18.10.2012 19:21, schrieb Tom Rini:
On Thu, Oct 18, 2012 at 02:24:20PM +0200, Matthias Wei?er wrote:
Hi
I get some misterious errors from time to time when decompressing an LZO compressed image. The output is as follows
zmx25> bootm 0x82000000 ## Booting kernel from Legacy Image at 82000000 ... Image Name: zmx25-gfx ifs Image Type: ARM QNX Kernel Image (lzo compressed) Data Size: 8181868 Bytes = 7.8 MiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 - must RESET board to recover resetting ...
RAM is from 0x80000000 to 0x83ffffff. The image was transfered using TFTP and has an uncompressed size of about 20MB. If I change something in the image so that the compressed data is different it works. If an image is "broken" it is always broken so the behavior is reproducable. I compress the image under windows using:
So you're saying that changing the source image results in good, or bad, behavior correct? Can you try taking a bad source image and using lzop on Linux instead?
Right. Small changes in the source image (which is not a linux kernel) can lead to a corrupted image. lzop under linux can decompress the image successfully. I also checked if it is possible to compress the image and make an u-boot image out of the compressed data under linux. This also worked without problems but when decompressing that image the error is the same.
lzo1x_decompress_safe from the current linux kernel is the same as that one used in u-boot.
Any ideas?
Regards Matthias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/19/12 00:43, Matthias Weißer wrote:
18.10.2012 19:21, schrieb Tom Rini:
On Thu, Oct 18, 2012 at 02:24:20PM +0200, Matthias Wei?er wrote:
Hi
I get some misterious errors from time to time when decompressing an LZO compressed image. The output is as follows
zmx25> bootm 0x82000000 ## Booting kernel from Legacy Image at 82000000 ... Image Name: zmx25-gfx ifs Image Type: ARM QNX Kernel Image (lzo compressed) Data Size: 8181868 Bytes = 7.8 MiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5 - must RESET board to recover resetting ...
RAM is from 0x80000000 to 0x83ffffff. The image was transfered using TFTP and has an uncompressed size of about 20MB. If I change something in the image so that the compressed data is different it works. If an image is "broken" it is always broken so the behavior is reproducable. I compress the image under windows using:
So you're saying that changing the source image results in good, or bad, behavior correct? Can you try taking a bad source image and using lzop on Linux instead?
Right. Small changes in the source image (which is not a linux kernel) can lead to a corrupted image. lzop under linux can decompress the image successfully. I also checked if it is possible to compress the image and make an u-boot image out of the compressed data under linux. This also worked without problems but when decompressing that image the error is the same.
lzo1x_decompress_safe from the current linux kernel is the same as that one used in u-boot.
_safe is the same, but what calls _safe is not the same, see lib/decompress_unlzop.c. My thought is that we have a bug in how we deal with the data and call lzo1x_decompress_safe.
- -- Tom
participants (2)
-
Matthias Weißer -
Tom Rini