[U-Boot-Users] SDRAM init problem? Was Re: uboot 1.1.2 problem

[Scott McNutt]

>>Your SDRAM configuration is wrong or your board
>>layout doesn't support the faster speeds.
> 
> Just wanna to confirm one thing. If one board's 
> SDRAM init was good enough but with poor layout
> (Layout design or PCB Processing), it would crash
> like this?

Yes, if your clock signals were not routed cleanly
... but re-check your SDRAM init first.

I experienced a similar problem that was caused by
the phase difference between CLKIN and the SDRAM
clock that only occurred during 8-beat burst write
cycles. In many designs there are only two things
that generate these cycles: the CPM during (burst)
writes to SDRAM, and the CPU during a dcache flush.

Since u-boot normally doesn't run with the data
cache enabled, and u-boot usually puts buffers in
the CPM shared memory (rather than SDRAM) ... you
won't see any errors ... until after the kernel
enables the data cache.

The bad part is that the data error occurs during
the write (dcache writing a line), but the kernel
crashes after reloading the (corrupted) cache line
(e.g. - reading in a pointer that was corrupted).
So it's _very_ difficult to observe this problem
when the kernel boots.

The good part is that u-boot remains stable (due to
some handy design decisions) ... and the POST cache
tests are a great starting point to determine if the
problem exists ... in a deterministic manner ;-)

Regards,
--Scott

BTW: We ended up dropping in a PLL so we could
adjust the clock phase as needed.