[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

[davis mcpherson]

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

[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

[Wolfgang Denk]

Dear davis mcpherson,

In message <4D3B0525.4080107@gmail.com> you wrote:
> 
> 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 

Sorry, but I don't even continue reading. v1.3.4 is 2.5 years old,
i. e. hopelessly obsolete.  Any efforts on this old stuff are only a
waste of time.

Do yourself (and us) a favour and use current code instead (at least
v2010.12, or bettter current top of tree from the git repository).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"No problem is so formidable that you can't walk away from it."
- C. Schulz

[U-Boot] Cannot access memory at address 0xd8013fa8 when using gdb/BDI3000 to debug u-boot

[davis mcpherson]

Ok, I'm updated my u-boot source code to the v2010.12 release and i'm 
still seeing the same behaviour as with the earlier version...

in summary:

early in the boot process, in the start.S file, the L1 DCache is 
configured for use as some initial RAM, the stack is located there, and 
the global data structure, gd_t,  is located there... when I debug my 
u-boot build i can set breakpoints, e.g. in cpu_init_f, and the 
breakpoint is hit and I can single step thru the code, but when the 
return from the function is executed i get the 'Cannot access memory at 
address..." error,  but  apparently the call does return, because I can 
single step on to the next function that is call, board_init_f...

Additionally, if I set a breakpoint in board_init_f, after the 
statement  that initializes the gd_t pointer variable 'gd', and then try 
to print the structure or just examine the memory locations i get the 
same "Cannot access memory at address..." error...

so i'm assuming gdb working with a bdi3000 should be able to access this 
L1Dcache when configured to be used as this initial RAM area for u-boot, 
is this assumption correct?

the code in start.S is coded to be common for all mpc85xx boards (its in 
the arch/powerpc/cpu/mpc85xx directory) with some config options from 
the board specific <board>_config.h file.
My board is custom but modeled after the MPC8548CDS and at least at this 
point of execution I think components common to any MPC8548 board are 
being set up... I left the #define that specifies the address for this 
initial RAM unchanged, 0xe4010000  ( i had changed it to 0xd8010000 when 
i was using 1.3.4, but could see a reason that was required...)

could my bdi3000 config file affect this in any way?  i've attached it 
for reference...

my thanks for your time and any ideas or suggestions are greatly 
appreciated...

davis mcpherson


On 01/22/2011 12:39 PM, Wolfgang Denk wrote:
> Dear davis mcpherson,
>
> In message<4D3B0525.4080107@gmail.com>  you wrote:
>    
>> 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
>>      
> Sorry, but I don't even continue reading. v1.3.4 is 2.5 years old,
> i. e. hopelessly obsolete.  Any efforts on this old stuff are only a
> waste of time.
>
> Do yourself (and us) a favour and use current code instead (at least
> v2010.12, or bettter current top of tree from the git repository).
>
> Best regards,
>
> Wolfgang Denk
>
>    

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: o3b_bdi3000_v1.0.cfg
Url: http://lists.denx.de/pipermail/u-boot/attachments/20110123/01a3b45f/attachment.txt