[U-Boot-Users] help with gdb-bdi2000

[Sharad Gupta]

Hi All,

I have got a new bdi2000 to help me in debugging linux kernel. I have 
been able to successfully run u-boot on MPC7455 based custom board. My 
problem is that I am not able to get bdi2000 to work properly with my 
system. To help me shortlist candidates for the errors I am getting, I 
would like your help in understanding what I am doing wrong here.

I reset the processor using bdi command line, the processor remains in 
halted state until I ask it to "go"

BDI>info
     Target CPU        : MPC7455 Rev.2
     Target state      : debug mode
     Debug entry cause : COP freeze (startup)
     Current PC        : 0xfff00100
     Current CR        : 0x00000000
     Current MSR       : 0x00000000
     Current LR        : 0x00000000
BDI>go

After some secs, I could see U-Boot messages on the serial port on the 
board. At some point in time, I halt the processor.
BDI>halt
     Target CPU        : MPC7455 Rev.2
     Target state      : debug mode
     Debug entry cause : COP halt
     Current PC        : 0x00fe51bc
     Current CR        : 0x24000000
     Current MSR       : 0x00000030
     Current LR        : 0x00fe4f60

Then, on my host machine I startup the gdb, discard the symbol file. 
U-Boot was linked at 0x1ff0000, after relocation it runs at 0xfe0000. So 
I reload the symbol file with the offset 0xfe0000.

simpod:[~/develop/u-boot]$ powerpc-linux-gdb u-boot
GNU gdb 6.0
This GDB was configured as "--host=i686-pc-linux-gnu 
--target=powerpc-linux"...
(gdb) symbol-file
Discard symbol table from `/home/sharad/develop/u-boot/u-boot'? (y or n) y
No symbol file now.
(gdb) add
add-shared-symbol-files  add-symbol-file
(gdb) add-symbol-file u
u-boot       u-boot.bin   u-boot.dump  u-boot.map   u-boot.memh 
u-boot.mif   u-boot.srec
(gdb) add-symbol-file u-boot 0xfe0000
add symbol table from file "u-boot" at
         .text_addr = 0xfe0000
(y or n) y
Reading symbols from u-boot...done.

Case I ->
I attach it to the bdi ... It tells me where exactly is the processor 
halted. I set the breakpoint at do_bootm ... I say continue to gdb ... 
go to my serial port on the board, ask it to do "bootm 3000000 4000000" 
... but I never see the breakpoint becoming active on gdb .... it just 
continues loading the linux ...

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0x00fe51bc in NS16550_getc (com_port=0x60000000) at ns16550.c:53
53              while ((com_port->lsr & LSR_DR) == 0);
(gdb) mon break
Breakpoint mode is SOFT
(gdb) b do_boot
do_bootm         do_bootm_linux   do_bootm_netbsd  do_bootm_rtems
(gdb) b do_bootm
Breakpoint 1 at 0xfe6488: file cmd_bootm.c, line 149.
(gdb) c
Continuing.

Case II ->
In another instance, I get the following error when I insert breakpoint 
at NS16550_getc routine:

(gdb) target remote bdi:2001
Remote debugging using bdi:2001
0x00fe51c4 in NS16550_getc (com_port=0x60000000) at ns16550.c:53
53              while ((com_port->lsr & LSR_DR) == 0);
(gdb) b NS
NS16550         NS16550_init    NS16550_reinit  NS16550_tstc
NS16550_getc    NS16550_putc    NS16550_t
(gdb) b NS16550_getc
Breakpoint 1 at 0xfe51b8: file ns16550.c, line 53.
(gdb) mon break
Breakpoint mode is SOFT
(gdb) c
Continuing.

Breakpoint 1, NS16550_getc (com_port=0x60000000) at ns16550.c:53
53              while ((com_port->lsr & LSR_DR) == 0);
(gdb) step

Program received signal SIGSTOP, Stopped (signal).
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00fe51c0 in NS16550_getc (com_port=Cannot access memory at address 
0xfbee48
) at ns16550.c:53
53              while ((com_port->lsr & LSR_DR) == 0);
(gdb) step

Program received signal ?, Unknown signal.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00fe51c0 in NS16550_getc (com_port=Cannot access memory at address 
0xfbee48
) at ns16550.c:53
53              while ((com_port->lsr & LSR_DR) == 0);




Any help would be highly appreciated.
Thanks
Sharad.