[U-Boot-Users] Uncompressing uImage: inflate() returned -3
Hi,
I now have u-boot working properly on my single PPC750GX on MV64360; it turned out to be SDRAM init issues, which were sorted out by some trial and error.
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 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.
So while generating the vmlinux.gz, I byteswapped it.. before feeding it to mkimage. So the CRCs are matched, and gunzip on the board tries to gunzip the image... However, it complains about 'bad gzipped data'.
Hmm, so setting 'verify' to 'n' also doesn't work; gunzip says 'inflate returned -3'.. which is some Z_DATA_ERROR.
I'm obviously doing something wrong here, since this should've worked...
I'm right now using an uncompressed image and working with it, that's working fine, except the kernel's bombing out after some initializations...
Amit.
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.
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.
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?
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.
Best regards,
Wolfgang Denk
On Mon, 23 Aug 2004 19:14:55 +0200, Wolfgang Denk wd@denx.de 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...
participants (2)
-
Amit Shah -
Wolfgang Denk