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.