On Wednesday 06 March 2002 05:51 am, Aradhana Prasad (OCS-BLRSJP-PEG) wrote: > Hi Everybody, --snip-- > 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.
Assuming that you have got the memory timings, cas latency, and the rest of the memory config registers right, you're most likely facing a hardware problem due to poor signal integrity. Try running the cpu and memory at some ridiculously slow speeds to see if this makes any difference. If it will boot and sort of run at 59MHz CPU with memclk set to 1/2 or 1/4 but no faster then it's probably SI. You should use the latest BLOB- it has some memory testing facilities. Since it copies itself to SDRAM and runs there with the Icache turned on, if its memory test passes then you probably need to look elsewhere for your troubles. If it fails, don't bother messing with a kernel until you get the hardware straightened out. FWIW no matter how crappy the board layout or layer structuring I've always been able to get a SA1110-based system to run, one way or another. Sometimes the cpu and memory speed settings are just pure magic (due to crosstalk or other gross SI problems) but usually there is a sweet spot where the system will at least run and execute code more or less reliably. Also if you're hacking hardware, a high speed digitizing oscilloscope is absolutely necessary. Find out what's happening with SDCLK- this is the fastest and most critical signal in the system. Sometimes 'microsurgery' needs to be performed where SDCLK is re-routed via 'banjo string' wiring to clean it up. Watch out for overloading of the addr & data bus, too (doesn't take much on an SA1110...) -- Jeff Sutherland, Accelent Systems, Inc. <http://www.accelent.com> - + - + - + - + - + - + - + - + - + - + - + - Whenever I return from a trip abroad, I'm always amazed by two things: All the wide open space we have in this country, and how bad the roads are. _______________________________________________ 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.
