[U-Boot] Memory problems on mpc8572ds

[Rafal Jaworowski]

On 2009-05-14, at 19:22, Sebastian Andrzej Siewior wrote:

> Hello,
>
> my mpc8572ds (2x 512 MiB ram) had initially u-boot 1.3.0-rc2 and I
> haven't notice any problems. Today I updated u-boot to v2009.03  
> because
> I was not able to boot current vanilla linux kernel in smp mode.
> Since then I experience random kernel opses. I thing it has  
> something to
> do with memory setup. The settings in the ddr controller changed from
> (v1.3.0-rc2):
> - ddr->sdram_mode 0x00400a62;
> - ddr->sdram_data_init = 0x00000000;
> - ddr->sdram_cfg_2 = 0x04401000;
>
> to (v2009.03):
> - ddr->sdram_mode 0x00440a62
> - ddr->sdram_data_init 0xdeadbeef
> - ddr->sdram_cfg_2 0x24401000
>
> I cherry-picked commit 6a819783 aka "fsl-ddr: Fix two bugs in the ddr
> infrastructure" but nothing improved.
>
> Now I've picked v1.3.0-rc2 and linux v2.6.29. With that combination
> everything seems to work however I experience sometimes ICE while
> compiling. If I continue to compile from that point there is no ICE
> anymore so it does not look like a gcc bug to me.
>
> Any suggestions? Someone with similar problems?

I can confirm this. We have been suffering from instabilities of the  
main line U-Boot on MPC8572DS since a long time ago. It is strongly  
correlated with memory controller settings: the same h/w unit works  
fine with 1.3.0-rc2 (Freescale LTIB), while using anything newer from  
main line leads to hangs and/or corruptions. We tried to nail down the  
issue, but could not find anything conclusive in the given time, so  
just stick with that old (but stable) 1.3.0 derivative...

Sometimes the corruptions could be observed using U-Boot mtest,  
sometimes not, but usually everything looked fine until more memory  
intensive operations at the OS level: heavier network traffic would  
cause checksum errors showing up and other corruptions, including hangs.

Interleaved mode seemed to have *some* effect: typically disabling  
interleaved config would give somewhat less corrupt-prone behaviour  
(it takes much longer to trigger the faults, but they would pop up  
eventually).

Other data point: we observed much often the above problems with  
rev1.1 of the silicon, rev1.0 is also failing, but 1.1 is very quick  
to err.

Rafal