public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: davis mcpherson <davis.mcpherson@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot
Date: Sat, 22 Jan 2011 11:26:13 -0500	[thread overview]
Message-ID: <4D3B0525.4080107@gmail.com> (raw)


I'm trying to get u-boot version 1.3.4 working a custom MPC8548 based 
board (version 1.1.4 currently works fine on this board so the hardware 
is known to be good).  I'm encountering the following problem during the 
early stages of the u-boot initialization and any insights as to what 
the problem may be would be greatly appreciated:

I have a BDI3000 and i'm using gdb for debug sessions.  I started with 
the MPC8548CDS.h as my template for the build configuration file for 
this board.

1) in the start.S file the L1 DCache is configured to be used for 
initial RAM, this occurs in the code at the 'switch_as:' label.  I set 
the CFG_INIT_RAM_ADDR to the value 0xd8010000 and this value is used to 
configure the L1CFG0 register.
2) execution soon jumps to the '_start_cont:' label and the stack is set 
up in this initial RAM area
3) I set a breakpoint at '_start_cont' and tried to examine the initial 
RAM memory with the gdb 'x' command:
(gdb) x/16x 0xd8010000
0xd8010000:    Cannot access memory at address 0xd8010000

So at this point should gdb be able to examine this memory area?

I compared the code in start.S for 1.3.4 with the code from 1.1.4 and 
although not identical the instructions to setup the L1 cache and use it 
for initial RAM end up using the same values and doing the same 
operations...

I can continue to execute code and soon we jump into the c routines 
where the global data pointer is initialized,  attempts to display this 
gd_t structure give the same error message (no surprise there), so I'm 
guessing this structure does not get initialized properly and function 
using it read bogus values...

but I can continue stepping thru the initialzation functions, and for 
example when the console is initialized a long string of garbage shows 
up in the console terminal window, the baudrate comes from the gd_t 
struct so its not what I configured...

so i think this is close to working but something seems broken with 
using the L1 Dcache for initial ram...

thanks in advance for any ideas and suggestion and please let me know if 
there is additional info that might be useful for you to understand the 
problem...

davis mcpherson

             reply	other threads:[~2011-01-22 16:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-22 16:26 davis mcpherson [this message]
2011-01-22 17:39 ` [U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot Wolfgang Denk
2011-01-23 12:16   ` davis mcpherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3B0525.4080107@gmail.com \
    --to=davis.mcpherson@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox