[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Hi, 

Apologies for asking what I suspect is a very simple problem, I am
attempting 
to debug u-boot after relocation and have followed the simple instructions 
previously posted on this mailing-list, however I am having difficulty in 
getting the abatron to do as it is told!

First up is the target section of the bdi2000 config file :

[TARGET]
CPUTYPE	8260
BDIMODE	AGENT
STARTUP	RESET
JTAGCLOCK	0
BOOTADDR 	0x00000100
;WORKSPACE	0x00000000
BREAKMODE	HARD
STEPMODE 	HWBP
;VECTOR	CATCH
;DCACHE	NOFLUSH
;MMU		XLAT 0xC0000000
;PTBASE	0x000000F0

I'd like to be able to step through the eth_init routine and I am invoking
it 
through a tftpboot command on the console. A trace from gdb illustrates my 
problem, (note that I have some shortcuts programmed into my .gdbinit
routine 
to set the $pc and to load the symbol file). When the program has loaded
into 
RAM I stop the debugger (hence the SIGSTOP) to insert my breakpoint, for
some 
reason I have problems if I attempt to insert the breakpoint before the code

is in RAM (?).

$ ppc-linux-gdb
GNU gdb 5.1.1
Copyright 2002 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".
(gdb) bdi
0x00000100 in ?? ()
(gdb) resethi
(gdb) ram
add symbol table from file "u-boot" at
        .text_addr = 0x7fc0000
(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x07fdbb18 in serial_getc () at serial_scc.c:242
242             while (rbdf->cbd_sc & BD_SC_EMPTY)
(gdb) b eth_init
Breakpoint 1 at 0x7fdc278: file ether_fcc.c, line 201.
(gdb) c
Continuing.

Breakpoint 1, eth_init (bis=0x7fa0220) at ether_fcc.c:201
201         volatile cpm8260_t *cp = &(immr->im_cpm);
(gdb) step
227         rxIdx = 0;
(gdb) step
198     {
(gdb) step
212         immr->im_cpmux.cmx_uar = 0;
(gdb) step
228         txIdx = 0;
(gdb) step
212         immr->im_cpmux.cmx_uar = 0;
(gdb) step
221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
FCC_PSMR_ENCRC;
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb) step
221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
FCC_PSMR_ENCRC;
(gdb) step
227         rxIdx = 0;
(gdb) step
201         volatile cpm8260_t *cp = &(immr->im_cpm);
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb) step
228         txIdx = 0;
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb)

As you can see the code appears to jump around aimlessly, though the program

still appears to run ok. Just to finish off I am able to configure the ram 
such that I can debug the application in ram up to the point where
relocation 
occurs so I am fairly confident in my SDRAM setup.

Any thoughts or comments welcome, 

thanks

Mark.