[U-Boot-Users] Problems writing to memory with mw

robert lazarski robertlazarski at gmail.com
Tue Nov 20 21:50:31 CET 2007


On Nov 20, 2007 12:47 PM, Jerry Van Baren <gerald.vanbaren at 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




More information about the U-Boot mailing list