Hi Everybody,

I need your help in cracking down the problem that I am facing, which is now
beyond my understanding, I have tried whatever I could think of.
As per the problem that I had posted earlier, Russell had suggested me to
check the region in the memory where I am putting the kernel, well I have
checked that properly, it is fine. Earlier the serial port on our board was
not working, so we had put the kernel through JTAG and as per blob's offsets
we put the kernel at an offset of 512, the method I was using was

dd  if=blob of=myblob bs=1024
dd  if=zImage of=myblob bs=1024 seek=512

Then I would flash "myblob" through the JTAG.

I even checked the hex values of the kernel using od -x command on zImage
and compared the same with the data stored in the region of the flash as
well as the RAM where I presume the kernel to be, they came out to be the
same.

The problem that I am facing now is

If I use an uncompressed image of the kernel, which I make by making a
binary of the vmlinux file, my board has booted a number of times, but again
that is not very consistent (the booting happens all of a sudden and that
too once in a blue moon), otherwise I used printascii statements to find
that the board gets stuck up in a loop in cpu_idle()  in
arch/arm/kernel/process.c.

The reason I went in for an uncompressed kernel was that with a compressed
image I always end up having a CRC error (which is very consistent). I was
going through the mailing list for February and I found a similar problem
being faced by somebody else as well, for which Erik had asked to make
memory timing changes in blob. So last two days I am trying on changing the
memory timings in blob after getting a set of configurations from Intel's
"SA1110 Memory Configuration Application" site, but have not been able to
get any rewards to my efforts. As per the SDRAM that we are using and as per
the configuration we got from Intel's site we have made some changes in
include/blob/arch/assabet.h because of which my whole 32MB of RAM is
detected.

Now I really don't know how to look further into the whole problem. So it
will be great if somebody could guide me on this.

Thanking in advance,

Regds...aradhana.


-----Original Message-----
From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 12, 2002 4:55 AM
To: Aradhana Prasad (OCS-BLRSJP-PEG)
Cc: '[EMAIL PROTECTED]'
Subject: Re: Problem with kernel booting on SA1110 based design.

On Mon, Feb 11, 2002 at 11:22:09AM +0530, Aradhana Prasad (OCS-BLRSJP-PEG)
wrote:
> We are using kernel 2.4.16 with patch-2.4.16-rmk2. We were able to see the
> flow of the init kernel through print statements and our board reaches
till
> init/main.c after which it stalls.

Where abouts in init/main.c?

It could be related to the location you're trying to run the kernel at.
This has come up several times in the past.  This is a good starting
point for checking things:

http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.ht
ml

> What we were doubting was that probably the CPU goes into some exception
> state and simply stalls or may be the compiler we are using might not be
> supporting this revision of the CPU i.e. B4 or may be there might be some
> driver issue.

Unlikely - the compiler implements a range of ARM architecture versions.
A CPU is targetted to one ARM architecture version.  Different revisions
do not target different architecture versions, and therefore the
compiler should be fine.




        Disclaimer 

                Information contained in this E-MAIL being proprietary to
Wipro Limited is 'privileged' and 'confidential' and intended for use only
by the individual or entity to which it is addressed. You are notified that
any use, copying or dissemination of the information contained in the E-MAIL
in any manner whatsoever is strictly prohibited.



_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
http://www.arm.linux.org.uk/armlinux/mailinglists.php
Please visit the above addresses for information on this list.

Reply via email to