robert lazarski wrote:
On Nov 20, 2007 12:47 PM, Jerry Van Baren gerald.vanbaren@ge.com wrote:
robert lazarski wrote:
On Nov 20, 2007 9:54 AM, Jerry Van Baren gerald.vanbaren@ge.com wrote:
robert lazarski wrote:
Hi all,
I'm trying to track down problems loading a linux kernel on my custom 8548 board off of 1.3RC3 - it loads sometimes via a ramdisk and gives me a bash shell - but most times it crashes in unusual, different places.
You could also try running caching disabled (start with both data and instruction disabled, then the other 3 combinations) - it slows the boot down substantially, but if it runs, it is an indication that you likely have a configuration problem.
Instruction cache disabled fixes the problem, thanks!!! I called icache_disable() right before spd_sdram () . What does this mean? What configuration do you think could be wrong, spd ?
EXCELLENT! The good news: you just won the hardware lottery. :-) The bad news: you lost the "read the manual" lottery. :-/
Something is wrong with your SDRAM initialization. There is no way I can give any useful advice other than read the user's manuals for both the SDRAM and the processor SDRAM configuration.
Note that there is a u-boot i2c sdram command will dump the SDRAM SDP configuration which often is helpful (you need to define CONFIG_CMD_SDRAM). http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=common/cmd_i2c.c;h=a684a580e6edc24f54f057ad0a93de8d40659d95;hb=HEAD#l657
Your Kingston memory sticks should be good (they are a reputable outfit). My suggestion of trying different speed grades and different suppliers is that you may get lucky and find one that works. This helps in two ways: 1) It gets your manager/customer off your back because you can show him *something* that works and 2) the difference between the working ones and "broken" ones may help point out where the brokenness lies.
What likely is happening is that the SDRAM is being configured with one set of clocking criteria and the processor is being configured with a slightly different set. The way SDRAM works (in an ideal world) is that the processor launches an address, the SDRAM goes and finds that address internally, and some time later they get back together to exchange the data (read/write). While the first address is being looked up, the processor can launch another address or complete a previous r/w operation (or open pages or close pages or do refreshes or...). There actually can be a lot of operations "in flight" at any given time (possibly in the double digits). In a misconfigured world, the SDRAM and the processor don't get back together on the *exact same* clock cycle and things go crash.
The key is that the SDRAM and the processor are independently but *S*ynchronously running identically configured, very complex, state machines which track addresses, commands, and data.
The problem generally is that the processor and the SDRAM state machines are *not* identically configured, somewhere there are different clock cycle value(s) in their respective state machines. Figuratively speaking, one is doing the Zamba and the other is doing the Samba. http://en.wikipedia.org/wiki/Samba As a result, instead of dancing with the stars, the one steps on his partner's toes and they both fall down.
The cache disable test is leveraging on the fact that, when caching is disabled, the processor (tends to?) launches only one address at a time and waits for the result before going on to the next address. This "papers over" the SDRAM configuration error.
Incidently, I couldn't call icache_disable() and get it to return before or after spd_sdram ().
Robert
HTH & good luck, gvb