Hi Tiju,
On Mon, Apr 07, 2008 at 09:09:36PM +0530, Tiju wrote:
Please see my other e-mail response about this. I still believe there might be some wrong memory / bus / core clock timing and or voltage issues.
We changed the memory clock to a lower frequency(90MHz to 67MHz) and the the "Bad Data CRC" error has gone. Thanks alot.
ok, this most likely means that you have some problems with your hardware design, probably exceeding the maximum permitted capacitive bus load.
We are writing the kernel image directly to the ram to 33000000. Therefore as for now it is not copied from the flash.
well, how do you copy the image into ram? It doesn't really matter from where the image is copied. What matters is that apparently the source of the copy is not equal to the destination of the copy. Even if you copy 'directly' via JTAG there is a source and a destination. and the destination will suffer through corruption if SDRAM timing or bus clock are wrong.
Is the hardware a prototype of a new board, or is it proven, verified hardware?
Yes, the hardware is a new prototype.
Well, then I suppose most of your problems are not u-boot problems but problems related to your hardware. You should verify your u-boot version with a known-working hardware (such as a smdk development board). Only if it fails on the known-good hardware, I believe there is sufficient reason to assume that the problem is actually a u-boot problem.
and it keeps on resetting. We further reduced the SDRAM frequency to 45 Mhz, but still the problem persist. Is it still the problem with the u-boot frequency or with the linux kernel?
* there is no u-boot frequency * the pll config done by u-boot is not the source of the problem, but rather some faulty hardware. lowering the clock is merely a workaround and not a fix.
I think any further debugging would be very specific to your hardware design.