Re: XUPV2P, Kernel 2.6.17 boot problem

On Mon Aug  7 2006 04:46:43 AM CDT, Benjamin Heyne wrote:

Peter Korsgaard [off-list ref] wrote as thus:

quoted

quoted

quoted

quoted

quoted

quoted

"David" == David H Lynch [off-list ref] 

David>     Have you tried 2.6.18.x to see if your stuff works with it
David> ?

Yes, 2.6.18-rc3 + my zlib fix
(http://thread.gmane.org/gmane.linux.kernel/428436) or -rc4 once it
hits kernel.org works fine on my v2p-based board.

Well, unfortunately I am still getting the inflate error
as soon as the image grows >2MB (about). Have you tried with
images of this size? If the image is smaller, everything works
fine...

My first reaction when I saw this thread was that you didn't allocate 
something in memory and overlapped something.  However, looking
at your original post again, I think your kernel is growing larger than
4MB, which is the link address of the zImage.  This is based on the 
kernel is decompressed to address 0 in
ppc/boot/simple/misc-embedded.c, and a 50% compression factor 
and 2MB compressed image.

You can look at the file size of vmlinux to see if this is close.

milton

And so it came to pass, that on Fri, 11 Aug 2006 23:37:25 -0500
Milton Miller [off-list ref] wrote as thus:

On Mon Aug  7 2006 04:46:43 AM CDT, Benjamin Heyne wrote:

quoted

Peter Korsgaard [off-list ref] wrote as thus:

quoted

quoted

quoted

quoted

quoted

quoted

"David" == David H Lynch [off-list ref] 

David>     Have you tried 2.6.18.x to see if your stuff works with it
David> ?

Yes, 2.6.18-rc3 + my zlib fix
(http://thread.gmane.org/gmane.linux.kernel/428436) or -rc4 once it
hits kernel.org works fine on my v2p-based board.

Well, unfortunately I am still getting the inflate error
as soon as the image grows >2MB (about). Have you tried with
images of this size? If the image is smaller, everything works
fine...

My first reaction when I saw this thread was that you didn't allocate 
something in memory and overlapped something.  However, looking
at your original post again, I think your kernel is growing larger than
4MB, which is the link address of the zImage.  This is based on the 
kernel is decompressed to address 0 in
ppc/boot/simple/misc-embedded.c, and a 50% compression factor 
and 2MB compressed image.

You can look at the file size of vmlinux to see if this is close.

milton

Well - That's exactly the case. But looking into misc-embedded.c, I noticed
that the load address for gunzip is fixed to 0x400000...shouldn't this
be dependent on CONFIG_BOOT_LOAD_BOOL and CONFIG_BOOT_LOAD?

I've changed the line to


#ifdef CONFIG_BOOT_LOAD_BOOL
	gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
#else	
	gunzip(0, 0x400000, zimage_start, &zimage_size);
#endif


and now it seems to work fine for big images (if CONFIG_BOOT_LOAD 
is set large enough of course...) - which wasn't the case before.


Best regards
-- 
Benjamin Heyne

On Aug 14, 2006, at 4:10 AM, Benjamin Heyne wrote:

And so it came to pass, that on Fri, 11 Aug 2006 23:37:25 -0500
Milton Miller [off-list ref] wrote as thus:

quoted

On Mon Aug  7 2006 04:46:43 AM CDT, Benjamin Heyne wrote:

quoted

Peter Korsgaard [off-list ref] wrote as thus:

quoted

quoted

quoted

quoted

quoted

quoted

"David" == David H Lynch [off-list ref]

David>     Have you tried 2.6.18.x to see if your stuff works with 
it

Well, unfortunately I am still getting the inflate error
as soon as the image grows >2MB (about). Have you tried with
images of this size? If the image is smaller, everything works
fine...

I think your kernel is growing larger than
4MB, which is the link address of the zImage.

Well - That's exactly the case. But looking into misc-embedded.c, I 
noticed
that the load address for gunzip is fixed to 0x400000...shouldn't this
be dependent on CONFIG_BOOT_LOAD_BOOL and CONFIG_BOOT_LOAD?

I've changed the line to

#ifdef CONFIG_BOOT_LOAD_BOOL
	gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
#else	
	gunzip(0, 0x400000, zimage_start, &zimage_size);
#endif

and now it seems to work fine for big images (if CONFIG_BOOT_LOAD
is set large enough of course...) - which wasn't the case before.

It shouldn't depend on CONFIG_BOOT_LOAD_BOOL.   CONFIG_BOOT_LOAD is
set all the time (the question is dependent on _BOOL not the variable
and the default is used).

milton

And so it came to pass, that on Mon, 14 Aug 2006 09:00:33 -0500
Milton Miller [off-list ref] wrote as thus:

quoted

quoted

I think your kernel is growing larger than
4MB, which is the link address of the zImage.

Well - That's exactly the case. But looking into misc-embedded.c, I 
noticed
that the load address for gunzip is fixed to 0x400000...shouldn't this
be dependent on CONFIG_BOOT_LOAD_BOOL and CONFIG_BOOT_LOAD?

I've changed the line to

#ifdef CONFIG_BOOT_LOAD_BOOL
	gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
#else	
	gunzip(0, 0x400000, zimage_start, &zimage_size);
#endif

and now it seems to work fine for big images (if CONFIG_BOOT_LOAD
is set large enough of course...) - which wasn't the case before.

It shouldn't depend on CONFIG_BOOT_LOAD_BOOL.   CONFIG_BOOT_LOAD is
set all the time (the question is dependent on _BOOL not the variable
and the default is used).

milton

OK - Thanks. So replacing

	gunzip(0, 0x400000, zimage_start, &zimage_size);
with
	gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);

should do the trick. Maybe we should report this to the file maintainer,
if you'd consider this to be a bug, too....

Best regards
-- 
Benjamin Heyne