From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 07 Sep 2007 06:26:07 -0400 Subject: [U-Boot-Users] best way to debug memory address problems? In-Reply-To: <46E0AB75.2050508@gmail.com> References: <46E0AB75.2050508@gmail.com> Message-ID: <46E1273F.5060803@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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