[U-Boot-Users] Problems writing to memory with mw

[Jerry Van Baren]

robert lazarski wrote:
> On Nov 20, 2007 12:47 PM, Jerry Van Baren <gerald.vanbaren at ge.com> wrote:
>> robert lazarski wrote:
>>> On Nov 20, 2007 9:54 AM, Jerry Van Baren <gerald.vanbaren at 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