[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Michael Bendzick]

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 at gmail.com]
Sent: Monday, August 23, 2004 9:40 AM
To: u-boot-users at 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/


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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 at gmail.com]
> Sent: Monday, August 23, 2004 9:40 AM
> To: u-boot-users at 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/

-- 
Amit Shah
http://amitshah.nav.to/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!"                                               -- Turkish proverb

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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.
-- 
Amit Shah
http://amitshah.nav.to/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If all you have is a hammer, everything looks like a nail.

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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.
-- 
Amit Shah
http://amitshah.nav.to/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Blast medicine anyway!  We've learned to tie into every organ in the
human body but one.  The brain!  The brain is what life is all about.
	-- McCoy, "The Menagerie", stardate 3012.4

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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.
-- 
Amit Shah
http://amitshah.nav.to/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Wolfgang Denk]

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 at gmail.com]
> Sent: Monday, August 23, 2004 9:40 AM
> To: u-boot-users at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[RUSSELL PETERSON]

I would run the mtest on a large region of memory to make
sure the memory controller is configured correctly.  If not,
you could be aliasing memory.  Been there.  Done that.

Regards,

Russell

>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20040823/11c5ec55/attachment.htm 

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

Hi Russell,

Russell wrote:
> I would run the mtest on a large region of memory to make 
> sure the memory controller is configured correctly.  If not, 
> you could be aliasing memory.  Been there.  Done that. 

[wow, gmail just broke its interface or you have a broken client...
replying didn't quote properly.]

Yes, I had SDRAM issues.. but they're now sorted out. In fact, u-boot
behavior was flaky till I enabled the SDRAM tests each time. The SDRAM
had to be initialized somewhat differently from what the standard
MV64360 port does.

Thanks,
Amit.
-- 
Amit Shah
http://amitshah.nav.to/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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/

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_

[U-Boot-Users] Uncompressing uImage: inflate() returned -3

[Amit Shah]

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...

-- 
Amit Shah
http://amitshah.nav.to/