RE: [U-Boot-Users] Uncompressing uImage: inflate() returned -3
Amit-
Are you making sure that you don't locate the gzipped kernel in a location of board memory that gets overwritten as the U-Boot gunzip takes place?
For instance...
If you put the gzipped kernel at 0x10008000 and the kernel load address is also 0x10008000, you will obliterate your gzipped data as you unzip to 0x10008000. I have seen this produce the -3 error. If your gzip data fits entirely before 0x10008000, you're safe. Also, if you calculate how big the gunzipped data is, and put the gzipped kernel that far after 0x10008000, you'll also be in good shape.
-Michael Bendzick
-----Original Message----- From: Amit Shah [mailto:shahamit@gmail.com] Sent: Monday, August 23, 2004 9:40 AM To: u-boot-users@lists.sourceforge.net Subject: [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.
Hi Michael,
On Mon, 23 Aug 2004 10:07:44 -0500, Michael Bendzick michaelb@logicpd.com wrote:
Amit-
Are you making sure that you don't locate the gzipped kernel in a location of board memory that gets overwritten as the U-Boot gunzip takes place?
For instance...
If you put the gzipped kernel at 0x10008000 and the kernel load address is also 0x10008000, you will obliterate your gzipped data as you unzip to 0x10008000. I have seen this produce the -3 error. If your gzip data fits entirely before 0x10008000, you're safe. Also, if you calculate how big the gunzipped data is, and put the gzipped kernel that far after 0x10008000, you'll also be in good shape.
I have 8 MB of RAM (I have more, but have configured u-boot to recognize just the first 8). Kernel is 2.3 MB (0x244086). I load it at an offset of 4 MB in the SDRAM space... should be enough for everything, I assumed. I'll have to check this again.
Thanks, Amit.
-Michael Bendzick
-----Original Message----- From: Amit Shah [mailto:shahamit@gmail.com] Sent: Monday, August 23, 2004 9:40 AM To: u-boot-users@lists.sourceforge.net Subject: [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.
Amit Shah http://amitshah.nav.to/
In message 877aabc404082309201918ede9@mail.gmail.com you wrote:
I have 8 MB of RAM (I have more, but have configured u-boot to recognize just the first 8). Kernel is 2.3 MB (0x244086). I load it at
But this is NOT the size of the _compressed_ image???
an offset of 4 MB in the SDRAM space... should be enough for everything, I assumed. I'll have to check this again.
Did you actually use 4 MB (400000) or did you use some other address by accident? What is your exact boot comand, and which output do you get?
Best regards,
Wolfgang Denk
On Mon, 23 Aug 2004 19:24:43 +0200, Wolfgang Denk wd@denx.de wrote:
In message 877aabc404082309201918ede9@mail.gmail.com you wrote:
I have 8 MB of RAM (I have more, but have configured u-boot to recognize just the first 8). Kernel is 2.3 MB (0x244086). I load it at
But this is NOT the size of the _compressed_ image???
No, this is the size of the uncompressed vmlinux.bin, that I'm putting in uImage with '-C none'. I haven't solved the gzip issue yet.
an offset of 4 MB in the SDRAM space... should be enough for everything, I assumed. I'll have to check this again.
Did you actually use 4 MB (400000) or did you use some other address by accident? What is your exact boot comand, and which output do you get?
Oh.. right! I used 0x4.0000 instead of 0x40.0000. Damn.
Okay, so CRC, gunzip are now working. Thanks Michael and WD.
But the post-Linux problem still remains: my BDI has gone for a replacement, so I have to use some early putchars with the UART that was initialized by u-boot. I place two putchars in early_init in arch/ppc/kernel/setup.c, but I just see one. So does that mean my stack's getting corrupted?
Thanks, Amit.
In message 877aabc404082310482a315b4d@mail.gmail.com you wrote:
Did you actually use 4 MB (400000) or did you use some other address by accident? What is your exact boot comand, and which output do you get?
Oh.. right! I used 0x4.0000 instead of 0x40.0000. Damn.
[Tip: type the '0's in three pairs of two; this is easy to remember and easy to type - i. e. "4...00...00...00".]
Okay, so CRC, gunzip are now working. Thanks Michael and WD.
Fine.
But the post-Linux problem still remains: my BDI has gone for a replacement, so I have to use some early putchars with the UART that was initialized by u-boot. I place two putchars in early_init in arch/ppc/kernel/setup.c, but I just see one. So does that mean my stack's getting corrupted?
Probably your second putchar is after the MMU has been turned on and it the cause for the crash. Remove this code, and use post-morthem dumps of the logbuf buffer. See the FAQ section in the DULG.
Best regards,
Wolfgang Denk
On Mon, 23 Aug 2004 20:10:12 +0200, Wolfgang Denk wd@denx.de wrote:
In message 877aabc404082310482a315b4d@mail.gmail.com you wrote:
Did you actually use 4 MB (400000) or did you use some other address by accident? What is your exact boot comand, and which output do you get?
Oh.. right! I used 0x4.0000 instead of 0x40.0000. Damn.
[Tip: type the '0's in three pairs of two; this is easy to remember and easy to type - i. e. "4...00...00...00".]
.. you meant 5 zeroes there, right?
Okay, so CRC, gunzip are now working. Thanks Michael and WD.
Fine.
But the post-Linux problem still remains: my BDI has gone for a replacement, so I have to use some early putchars with the UART that was initialized by u-boot. I place two putchars in early_init in arch/ppc/kernel/setup.c, but I just see one. So does that mean my stack's getting corrupted?
Probably your second putchar is after the MMU has been turned on and it the cause for the crash. Remove this code, and use post-morthem dumps of the logbuf buffer. See the FAQ section in the DULG.
Yep, that's the next step. Thanks.
Best regards,
Wolfgang Denk
Amit.
In message 877aabc404082311494d4fe931@mail.gmail.com you wrote:
[Tip: type the '0's in three pairs of two; this is easy to remember and easy to type - i. e. "4...00...00...00".]
.. you meant 5 zeroes there, right?
Arghh.... three pairs of two characters, i. e. 40...00...00
Probably your second putchar is after the MMU has been turned on and it the cause for the crash. Remove this code, and use post-morthem dumps of the logbuf buffer. See the FAQ section in the DULG.
Yep, that's the next step. Thanks.
Good luck.
Best regards,
Wolfgang Denk
On Mon, 23 Aug 2004 20:10:12 +0200, Wolfgang Denk wd@denx.de wrote:
In message 877aabc404082310482a315b4d@mail.gmail.com you wrote:
But the post-Linux problem still remains: my BDI has gone for a replacement, so I have to use some early putchars with the UART that was initialized by u-boot. I place two putchars in early_init in arch/ppc/kernel/setup.c, but I just see one. So does that mean my stack's getting corrupted?
Probably your second putchar is after the MMU has been turned on and it the cause for the crash. Remove this code, and use post-morthem dumps of the logbuf buffer. See the FAQ section in the DULG.
I meant 'I've put two putchars one after the other'. I see the first char printed, but not the second. That's what's making me doubt the stack.
About the log buffer: nothing in them. I'll probably have to initialize it 'earlier' in early_init and then figure out something.
In message 31ADFA827355984B9E2A161514595B561C3380@lpdsrv04.logicpd.com you wrote:
Are you making sure that you don't locate the gzipped kernel in a location of board memory that gets overwritten as the U-Boot gunzip takes place?
Excellent advice.
If you put the gzipped kernel at 0x10008000 and the kernel load address is also 0x10008000, you will obliterate your gzipped data as you unzip to
The kernel load address will always be zero in this case (as this was a PowerPC system).
-----Original Message----- From: Amit Shah [mailto:shahamit@gmail.com] Sent: Monday, August 23, 2004 9:40 AM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] Uncompressing uImage: inflate() returned -3
...
And please - don't top-post, and don't quote the whole original message.
Best regards,
Wolfgang Denk
participants (3)
-
Amit Shah -
Michael Bendzick -
Wolfgang Denk