[U-Boot-Users] Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard

[Benedict, Michael]

Timur Tabi wrote:
> You'll notice in spd_sdram() that not only is it really complicated,
> with dozens of if-statements, but there's quite a bit of code to
> handle various errata.  In other words,
> it's not surprising (well, to me, at least) that you may have
> encountered a hardware bug of some kind.  Alternatively
> 
The key differences were:
DDR:timing_cfg_1=0x26242321
<snip>
DDR:sdram_mode=0x00000032

For the hard-coded RAM init / stable case and

DDR:timing_cfg_1=0x26232321
<snip>
DDR:sdram_mode=0x00000022

For the SPD RAM init / unstable case.  In other words, the CASLAT
control value.  In the default timing case (bus speeds are configurable
on the board) this is with a max_data_rate of 400 and ddrc_clk of 266.

Timur,
	I am slightly confused about the scenario you used to develop
the hardcoded timings.  The git tree from October 31 (when you commited
these definitions) did not even contain SDP support for DDR400 RAM
(unless I am not reading the code correctly).  Is it possible that 

I am really confused by this code.  Hopefully someone can explain all
the conditionals that are causing the caslat to be decremented based on
spd.clk_cycle*.  In my current configuration I could blame that
decrement by two on the difference.  Any help explaining this code is
greatly appreciated.
	Thank you!
		Michael