From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 18 Oct 2012 10:31:45 -0700 Subject: [U-Boot] Uncompress error with LZO In-Reply-To: <20121018172132.GU27770@bill-the-cat> References: <507FF4F4.1080805@arcor.de> <20121018172132.GU27770@bill-the-cat> Message-ID: <20121018173145.GV27770@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: