[U-Boot-Users] best way to debug memory address problems?

[Jerry Van Baren <vanbargw@gmail.com>]

Jerry Van Baren wrote:
> Alan Bennett wrote:
>> Help;  I'm trying to figure out if these errors are hardware or
>> software.  And of course, this is our first ppc/uboot system, so I'm
>> still stepping through a lot of learning as I go.
>>
>> I'm supposed to have a memory region from 0 to 7fff_ffff assigned to
> 
> Looks like 07ff_ffff to me, although it doesn't matter for this discussion.
> 
>> our 128MB memory.  However, I run into several issues when trying to
>> run mtest.  I end up with an large sections  mis-behaving.  I don't
>> see any conflicts in the BRx registers, and I believe my OR1 is set up
>> properly, so I'm not sure how to proceed.
>>
>> good:
>> #> md  0x00100000 1; mw  0x00100000 0xfff0000f ; md  0x00100000 1;
>> 00100000: ffffffff    ....
>> 00100000: fff0000f    ....
>>
>> bad:
>> #> md  0x00b8ac98 1; mw  0x00b8ac98 0xffff0000 ; md  0x00b8ac98 1;
>> 00b8ac98: 61633938    ac98
>> 00b8ac98: 61633938    ac98
> 
> OK, the *data bits* in the memory are the *ASCII* values that form the 
> lower half of the address 0x61 = 'a', 0x63 = 'c', 0x39 = '9', 0x38 = 
> '8'.  There is *no way* this can be a coincidence unless you wrote those 
> values in intentionally before doing the above example "mw" command. 
> Going down that decision tree...
> 
> a) If you put 0x61633938 in that location of memory, how did you do it 
> when it worked as opposed to the above illustration where it failed?
> 
> b) If you *didn't* put 0x61633938 in that memory location, who did? 
> There is no way hardware mis-wrote half the address as *ASCII* values as 
> part of the "mw" command which means either there is a software bug 
> involved or your hardware is seriously sick (does u-boot run reliably?). 
>   If this is the case, what happens when you use capital letter addresses?
> md 0x00b8AC98 1; mw  0x00b8AC98 0xffff0000 ; md  0x00b8AC98 1;

Hi Alan,

[snip]

The above symptoms could be because your u-boot scratchpad memory (.data 
and/or .bss) resides in the memory locations you are trying to test - 
0x00b8xxxx - either intentionally or unintentionally.  If 
unintentionally, you have either a hardware problem or a software 
misconfiguration.

Is your memory space clean or does it get replicated?  If you write a 
unique pattern (say 0xcafeface) to address 0x0000_0000, do you see it 
again at an address related by one address bit - e.g. 0x0400_0000, 
0x0200_0000, 0x0100_0000, ... 0x0000_0010, 0x0000_0008, 0x0000_0004?

Hardware problems would tend to be miswiring or shorts/opens on the 
address bus.  That would be Very Bad. :-(

Software problems would tend to be errors in SDRAM (DDR/DDR2) 
configuration - if, for instance, you have your processor initialized 
with the wrong address split on the bank select, you will be sending the 
wrong number of bits for RAS and CAS, causing a memory "duplication" 
problem.  That would not be good, but *NOT* Very Bad since it is dead 
simple to fix (once you figure out what the configuration _should_ be, 
that is ;-).

Good luck,
gvb