Subject: Re: CL7500FE Kernel Image

From: Vikas Datta <[email-masked]>
Date: Tue, 6 Jun 2000 20:03:06 +0530 (IST)

Hello,

I have tried replacing the SIMM with a good one. It still shows the same
error.  My vmlinux is 1461K and zImage is 533K. I have tried debugging the
uncompressing function. The misc.c calls inflate.c in /linux/lib. I placed
various debugpoints using error() and finally found that the program is
getting stuck at the huft_build function in /linux/lib/inflate.c

The program returns an error in DEBG("huft 3") saying : bad input; more
codes than bits !

I have used binutils 2.95.2 for building the kernel. I would be trying the
hexdump later and would compare the first 512 bytes of the zImage loaded
with the zImage on the host PC.

any different ideas?

Thanks,

Regards,
Vikas

On Mon, 5 Jun 2000, Jason Gunthorpe wrote:

> 
> On Tue, 6 Jun 2000, Vikas Datta wrote:
> 
> > Thank you for the suggestions. I have now got the minicom working.
> > While downloading the zImage using the angelbootloader at the address
> > location 0x208000, i get the leds glowing. One led then goes off and the
> > message on minicom from the cirrus COM2 port is :

>>CL-PS7500FE Loader, Verison: Jun  3 2000 08:54:09
>>Loading without relocation..
>>Output_Start: 10008000
>>free_mem_ptr: 1028C008
>>free_mem_ptr_end: 1029C008Uncompressing Linux...
>>invalid compressed format (err=2)
>>-- System halted

> 
> Hmm. In all my testing I never once got *this* message.
> 
> It can only mean one of two things, I think.
>  a) The original file, or the serial download caused file corruption
>  b) Your ram is acting flaky like mine was.
> 
> I suppose there is a faint possibility of memory corruption, or running
> off the end of ram or something.. Make certain your kernel vmlinux is <
> 2m. (Mine was 1.5meg vmlinux, 500k zImage)
> 
> Otherwise I would suggest you pull the SIMM and pop in another, see if
> that works better. Maybe write a little memory tester too.. SIMMS have to
> be or 16meg or better and I am using 60ns parts, EDO I think.
> 
> It may also be memory timings. You can adjust those with some chip
> specific registers.
> 
> > Is there a way to debug the program and see the assembly-level
> > instructions of the zImage file?
> 
> No, at this point you should be looking at using puth's and puts's to
> debug the decompressor stages. Look to see if the output pointer goes past
> the load address for the startup (Kernel > 2Meg) or if the data it is
> decompressing is valid. If you can show that there is a 1 bit error in the
> comrpessed data then it would definately point to funny RAM. If you show
> that the compressed data is totally hosed then some pointer is going out
> of bounds some how.
> 
> Maybe print out a hex dump of 512 bytes starting from the front and
> 512bytes starting from the CRC failing block. That would give some idea
> what is going on. 
>  
> > when i try using ../boot/compressed/vmlinux, i get no response on the
> > minicom and none of the leds glow either.
> 
> That is an Elf Image, you cannot use it until you use objcopy to make it
> into a flat memory dump (the zImage file).
> 
> Jason
> 

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]