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