Subject: Re: CL7500FE Kernel Image

From: Vikas Datta <[email-masked]>
Date: Wed, 7 Jun 2000 18:40:00 +0530 (IST)

Hello,

On Tue, 6 Jun 2000, Jason Gunthorpe wrote:

> Try  to increase the stack size maybe? In the vmlinux.lds.in file.
> 

I tried increasing the stack size....but no change....

I then wrote a small code in misc.c that adds up all 32-bit ARM words in
the kernel from the DRAM and displays their sum....similar to the EEPROM
checksum!

The checksum is added in the zImage and checked seperately. Care is taken
that both the programs add the same ARM words. I get 

zImage       Feedback from DRAM

7065f500     7064f50e             trial one with entry point in bank 2

bc45e689     bc44e687             trial two with entry point in bank 0

Atleast two nibbles seem to get corrupted during the download to DRAM. Is
it because angelboot is doing something wrong ?

Or is my inflate.c compiled using binutils 2.95.2 for the kernel
2.3.99-pre8 incorrect. 

I have also independently checked the DRAM using a memory test program
running over SDT. When i compared the hexdump of the whole image, i find
that errors occur inconsistently at different places each time....
sometimes in the middle of the kernel and sometimes towards the end.
However the kernel always gets stuck in the huft_build function in
/linux/lib/inflate.c

What could be going wrong.....? There does seem to be file corruption
somewhere.....

Thanks,

Regards,
Vikas 

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

---

From: Jason Gunthorpe <[email-masked]>
Date: Wed, 7 Jun 2000 09:05:03 -0600 (MDT)

> sometimes in the middle of the kernel and sometimes towards the end.

Can you try running checksum multiple times? See if it stays the same over
each run. AFAIK the angel protocol has per block checksums so data should
not be getting corrupted while it is in transit. However.. it may be that
the angelboot program does not understand a CRC failure reply, try a lower
baud rate maybe?

Jason

---

From: Lavu Sridhar <[email-masked]>
Date: Thu, 8 Jun 2000 03:41:55 +0530 (IST)

The checksum seems fine. I have also checked the hardware side, it seems
fine. Tried with lower baud rates also. 

The error message of comes from the function DEBG("huft3 ") in
lib/inflate.c which has the following comment line:
"bad input: more codes than bits"

I want to know if an uncompressed linux image using the '1.5MB vmlinux'
can be made and downloaded into the DRAM.

Regards,
Lavu Sridhar

---------------------------------------------------------------------

---

From: Jason Gunthorpe <[email-masked]>
Date: Wed, 7 Jun 2000 23:09:48 -0600 (MDT)

> "bad input: more codes than bits"

I think you need to determine if the data is corrupted in memory before
compression or during decompression.
 
> can be made and downloaded into the DRAM.

I don't think that is wise.. if you cannot even get a compressed image
into ram OK then you will probably have problems with uncompressed images
as well. Likely random kernel oops :<

I've been using this board and another using angel and the zImages for two
weeks now, never once has anything like this happened..

I just had another thought.. What if there is a bug in your compiler that
is producing funny code? I have placed the image I am using up at
http://amber.deltatee.com/~jgg/cl-ps7500fe/zImage

I used these options to download it:

base 0x208000
entry 0x208000
device /dev/ttyS1
options "9600 8N1"
baud 115200

Jason

---

From: Vikas Datta <[email-masked]>
Date: Thu, 8 Jun 2000 13:53:06 +0530 (IST)

Hello,

Your idea worked.......the compiler was faulty and was indeed producing
funny code. With the zImage on your site, my board now boots upto the
kernel panic...........it looks really great !!

We were using the arm-linux cross Tool Chain.  The Tool Chain is made up of:

        binutils-2.9.5.0.22,
        gcc-2.95.2 - C, C++, f77, CHILL,        java and objc.
        glibc-2.1.2. with the International crypt library.

Which one are you using?

Thanks,

Regards,
Vikas

On Wed, 7 Jun 2000, Jason Gunthorpe wrote:

> is producing funny code?

---

From: Jason Gunthorpe <[email-masked]>
Date: Thu, 8 Jun 2000 09:30:52 -0600 (MDT)

> kernel panic...........it looks really great !!

Hm.. That doesn't mean it is a compiler problem, but it sure is something
to do with how your image is being built..
 
>         glibc-2.1.2. with the International crypt library.

I hand compiled my own, binutils 2.9.5.0.41, gcc
2.95.2+arm-patch+debian-patch, glibc-2.1.3

You can grab it and try my build if you want, same place as the zImage,
unpack the tarball into /opt (so that /opt/arm-linux/bin is created)

Jason