[U-Boot] Uncompress error with LZO

[U-Boot] Uncompress error with LZO

[Matthias Weißer]

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

[U-Boot] Uncompress error with LZO

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121018/b5824da8/attachment.pgp>

[U-Boot] Uncompress error with LZO

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121018/270425dd/attachment.pgp>

[U-Boot] Uncompress error with LZO

[Matthias Weißer]

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

[U-Boot] Uncompress error with LZO

[Tom Rini]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQgXLtAAoJENk4IS6UOR1WlIkP+gMYCF2diseyHeP3+xYn3Dma
4Fax9ljT/I0lshhGSHa4xtcIurBOWRk4S5D8ICnI87zNnN1z8O8KuEx/mMH5VkG3
gpf1KW7XsEjvdt5h21eF0nUT925d418IjbLCtyhGP5luEURaY7Xuqb73JNZhZYbu
Rb5ySvvOZPpRzc0z8vDPugutgGWMBRornBKg60WMrxzqTzq+4OoNSM8c1zgX8TnI
dSsS02RuNWh5qa995hbY1uOQIJooBg1D5NNePZ8fE8upo5gtW7HTow3xnP3eDHws
91b6yWPcSmKKNJV8/FaggVPY43m7dmPrvDX+P8wWFObS02sxjNaQLMhhc+aavPjo
cnUSF3vsSu0u56S7wxBe55hOzf8PR/+DYB3+8h/VcfK0VTl7sE93chM/jvvzqh6a
A4VT0hvMnxg+eyvlrLLzX63lK4plvXMDMlHbAjuY0ln3RSATh0J3sO3r9OwyuvDG
HxlFyW0/BGAJpoOIv5grawv55FBr2FY1V4XDVbDFJU0Dl+x6qT2YX431r1/FzsbD
ipUYdEfwkuguvJtmCRsRAoewGLcY5idJXc671UJnB+wr2gJsLcvKfsXw+1T5dIFF
Eb4/ApIHpl4eKWwxbC+9UzZA5zi47keCvO4mI3ZmWCC2OAGX8o9qa0w6faIgqA+r
ltsgJyvxk+1AmV+FHym8
=Zajm
-----END PGP SIGNATURE-----