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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot