On Nov 20, 2007 12:47 PM, Jerry Van Baren gerald.vanbaren@ge.com wrote:
Hi Robert,
The configuration SDRAM problems typically show up when cache is enabled because that is when the pipelining really becomes active and config errors show up. There isn't a good way to debug this that I'm aware of, other than reading the users manuals/data sheets repeatedly (!!!) and working out the numbers (painfully!). My recollection of SPD is that mapping SPD values to SDRAM controller configuration is not nearly as straight forward as you would expect.
You could try different memory sticks to see if a different manufacturer and/or speed rating stops the crashing.
Good idea, any DDR2 manufacturer known to work well? We've gotten this far with kingston.
You could also try running caching disabled (start with both data and instruction disabled, then the other 3 combinations) - it slows the boot down substantially, but if it runs, it is an indication that you likely have a configuration problem.
The monitor no longer seems to have the icache and dcache commands. I tried this in my board config but it seemed to have no effect:
#undef CONFIG_CMD_CACHE
cpu/mpc85xx/cpu.c has this but it didn't seem clear to me how to disable it:
141 142 puts("L1: D-cache 32 kB enabled\n I-cache 32 kB enabled\n"); 143
Is disabling i-cache and d-cache valid in u-boot for 85xx? How do I do that?
WRT hardware problems, probably you can dial back the speed of your bus. If disabling caching doesn't fix the problem but dialing back the speed does, it would indicate a hardware problem.
For hardware problems, I would suspect trace problems: perhaps the traces are not acceptably close to equal length (outside of the spec) or if they are routed poorly (through a noisy part of the board). Looking at the layout may show up something. I've seen poor routing cause problems that were "solved" by slowing down the bus.
We are looking in to this, thanks, Robert