Subject: GDB bdi2000 and mpc85xx

From: Stuart Hodgson <[email-masked]>
Date: Fri, 02 Nov 2007 17:17:48 +0000

Hi,

I am attempting to get Kernel debugging working on our mpc8541 based 
board via a BDI2000. The various components in use are

kernel - 2.6.19.2
BDI firmware - 1.08
U-Boot - 1.2.0
ppc_85xx-gdb - from eldk4.1 (6.3.0.0-1.21_3rh)

Kernel is configured with `-g` in CFLAGS and not with CONFIG_BDI_SWITCH, 
from the information I have read around the subject this seem to be 
correct. I also have `MMU  XLAT`, and `PTBASE 0xF0` set in by BDI 
configuration file. The default value for XLAT of `0xc0000000` matches 
the kernel our kernel config.

Steps that I done so far

1. Power on BDI
2. Power on the board
3. BDI> reset run
4. Enter u-boot environment to stop linux booting immediately.
5. BDI> HALT
6. BDI> BREAK HARD
7. BDI> BI 0xc025a51c   (this is the address of start_kernel for my build)
8. BDI> GO
9. From U-boot prompt `bootm`, kernel is copied from flash and loading 
begins
10. Kernel does not halt at start_kernel and continues to the login

If I attempt to break at an address later in the boot sequence, such as 
qmx19_ata_input_data (this is the area that I am trying to investigate) 
I get

- TARGET: core #0 has entered debug mode

So from here I attempt to connect to the BDI from gdb

linux> cd ~/linux-2.6.19.2
linux> ppc_85xx-gdb vmlimux

"
GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
The target architecture is set automatically (currently powerpc:603)
"

I noticed here that the last line does not match the e500 core I am 
using, but there does not seem to a change if I change this using `set 
architecture powerpc:e500`

(gdb) tar rem <bdi_ip>:2001
Remote debugging using <bdi_ip>:2001
0x00000000 in ?? ()

What I don't understand here is why 0x00000000 is shown as the address, 
further on the BDI the following error is shown then the connection is made

"
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
"

If I then clear the breakpoint from the BDI

BDI> CI

I can then from gdb set breakpoints

(gdb) b qmx19_ata_input_data
Breakpoint 1 at 0xc014ecb4: file drivers/ide/ppc/qmx19-ide.c, line 139.
(gdb) c
Continuing.

And all seems well with resolving the symbol names and and source files. 
When the breakpoint is hit next

"
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x00000000 in ?? ()
"

But as expected I can not do any debugging since the address's are not 
being resolved by GDB/BDI. Trying to single step now results in gdb showing

(gdb) s
Cannot find bounds of current function

and BDI showing
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed

So my problem would seem to be with address translation. If I ask the 
BDI to translate the address for me it seems fine though

BDI> PHYS 0xc014ecb4
PHYS = 0x0_0014ecb4

So in summary is seem to me that there is a problem with the address 
translation to from BDI GDB, most likely the result of a missing 
configuration parameter or setting. I should also add that there there 
is not an inherent problem with the build of Linux as it boots fine and 
is operational but I would like to step though our CF card driver when 
the kernel is loading.

I have seen a couple of similar questions asked regarding the mpc85xx 
series but not any answers that have shed any light, by all accounts the 
steps I have done would seem to just work for other people, such as the 
BDI manual.

Does anyone have some insights into this.

thanks

Stuart Hodgson