From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amit Shah Date: Mon, 23 Aug 2004 23:10:46 +0530 Subject: [U-Boot-Users] Uncompressing uImage: inflate() returned -3 In-Reply-To: <20040823171500.629D1C109F@atlas.denx.de> References: <20040823171500.629D1C109F@atlas.denx.de> Message-ID: <877aabc4040823104044a663a6@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, 23 Aug 2004 19:14:55 +0200, Wolfgang Denk wrote: > In message <877aabc4040823073962e725a8@mail.gmail.com> you wrote: > > > > Okay, so now there are issues when it's loading uImage: The uImage > > built fails on the CRC. This is due to inconsistencies in the byte > > In the subject you write about "inflate() returned -3" whis sounds > like a different issue to me. > > > order of vmlinux.gz. When built on i386, it is CRC'ed in little > > endian, while when it's being checked on the board, it gets CRC'ed in > > big endian... so there will definitely be a mismatch in the two CRCs. > > Or I'm overlooking something. > > Yes, you are overlooking something. Both the CRC code in gzip and in > the mkimage tool takes care of endianess issues. This is NOT your > problem. Yep, shouldn't be. > > So while generating the vmlinux.gz, I byteswapped it.. before feeding > > Don't do this. This cannot work. > > > Hmm, so setting 'verify' to 'n' also doesn't work; gunzip says > > 'inflate returned -3'.. which is some Z_DATA_ERROR. > > This just turns off the image CRC ch3ecking, but not the gunzip > verification. Yes. But if it really was the CRC going bad due to endian issues, the gunzip should've worked well... > > I'm obviously doing something wrong here, since this should've worked... > > Did you simply try increasing your TFTP download address to something > like 0x400000 or so? I don't have an Ethernet interface. I transfer the uImage (as well as u-boot) via PCI. The uImage is dumped to SDRAM, whereas u-boot is put into flash. > > Unfortunately you don't give any information how you are trying to > boot Linux; if you had given the exact command and the exact output I > might have been able to provide better help. Some output: Top of RAM usable for U-Boot at: 00800000 Reserving 130k for U-Boot at: 007df000 Reserving 260k for malloc() at: 0079e000 Reserving 56 Bytes for Board Info at: 0079dfc8 Reserving 48 Bytes for Global Data at: 0079df98 Stack Pointer at: 0079df78 New Stack Pointer is: 0079df78 U-Boot relocated to 007df000 => setenv verify n => printenv verify verify=n => imi 40000 ## Checking Image at 00040000 ... Image Name: Linux-2.6.7 Created: 2004-08-23 11:56:08 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1007143 Bytes = 983.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... Bad Data CRC => bootm 40000 ## Booting image at 00040000 ... Image Name: Linux-2.6.7 Created: 2004-08-23 11:56:08 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1007143 Bytes = 983.5 kB Load Address: 00000000 Entry Point: 00000000 Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP ERROR - must RESET board to recover *** This is when I set 'verify' to 'n'. => bootm 40000 ## Booting image at 00040000 ... Image Name: Linux-2.6.7 Created: 2004-08-23 11:15:57 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1007140 Bytes = 983.5 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... Error: Bad gzipped data GUNZIP ERROR - must RESET board to recover *** And this output is when I have vmlinux.gz byteswapped before feeding to mkimage. I'll mention what I'm doing right now in reply to your next mail... -- Amit Shah http://amitshah.nav.to/