GDB: Remote debugging via BDM via gdb/gdbserver.
Mark Powell
medp@primag.co.uk
Thu Feb 25 03:33:00 GMT 1999
On 25-Feb-99 Brendan Simon wrote:
> I wish to debug code targeted for a PowerPC embedded target, which is
> compiled with GCC configured as a cross compiler hosted on a Linux box.
> I have a Wiggler BDM device which I want to use for debugging.
--snip--
> Alternatively (and preferably), is there a Linux device driver for the
> Wiggler yet ???
The following (rather long) message was posted to the ColdFire list. The
example is running on a ColdFire, but the patches and Linux driver are
AFAIK general.
I hope it's useful...
>
> Could you point me to some information on using GDB from Linux?
>
You are not first to ask this question, so here is some info I hope you
and other find useful. Sorry if this mail is a little long.
The driver currently uses the P&E BDM interface. For the driver and gdb
patch you can get the archive from:
ftp://skatter.usask.ca/pub/eric/BDM-Linux-gdb/gdb-4.17-bdm-990115.tar.gz
or
http://www.calm.hw.ac.uk/davidf/coldfire/gdb-4.17-bdm-990115.tar.gz
Unpack with a command like :
$ cd somewhere; tar zxf gdb-4.17-bdm-990115.tar.gz
Then look at the README file contained in the archive. This has the
detailed steps you need to follow. Comments and corrects are welcome.
Compile the driver, and library module and install. You will need to run
the MAKEDEV script in the `local_scripts' directory as root to create
the device nodes in the /dev directory.
Compile the test program and run it. The command line argument in the
release is not quite correct. Try :
./chk /dev/bdmcf0
If your BDM module is not connected to parallel port 0 you need to use a
different number at the end of the device filename. If you get failures
try :
./chk -d /dev/bdmcf0
On RedHat this should place debug info into `/var/log/messages' and the
console. The chk program only raises the driver debug level to 1. It can
go higher for more info. High numbers can get quite verbose so watch
out. Send me any info or questions if you have problems.
The chk test covers most critical areas in the driver.
Patch gdb then build and install.
The driver is a kernel module and currently only supports 2.0.x kernels.
The driver breaks on 2.2.x kernels. I have not received any 2.2.x
patches. They are welcome.
To test gdb, start it with :
$ m68k-bdm-coff-gdb
GNU gdb 4.17
Copyright 1998 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=i686-pc-linux-gnulibc1
--target=m68k-bdm-coff".
(gdb)
Once you have the gdb prompt, connect to the target with the gdb command
:
(gdb) target bdm /dev/bdmcf0
Remote bdm connected to /dev/bdmcf0
Again change the last number to be the parallel port you are connected
to.
The driver and gdb patch also supports the cpu32 core as found in the
68360. You connect using another device, eg /dev/bdmcpu320.
Your target will have been reset and halted. You can now look at the
ROM. To dump the vector table try :
(gdb) x /12w 0
0x0: 0x000071c8 0xffe00400 0xffe00518 0xffe00518
0x10: 0xffe00518 0xffe00518 0xffe00518 0xffe00518
0x20: 0xffe00518 0xffe00518 0xffe00518 0xffe00518
This is from my 5206 eval board. GDB has no stack history at this point
so dumping all the registers will fail. You can select a frame then gdb
will dump the registers.
(gdb) p /x $pc
$4 = 0xffe0c860
(gdb) info reg
No selected frame.
(gdb) select-frame 0
(gdb) info reg
d0 0x0 0
d1 0x0 0
d2 0xfb9e6ec2 -73503038
d3 0xbd85fe43 -1115292093
d4 0x0 0
d5 0xbd3931fd -1120325123
d6 0xbf3a28d0 -1086707504
d7 0x0 0
a0 0x30000000 0x30000000
a1 0xffe08391 0xffe08391
a2 0x9b1b2fd3 0x9b1b2fd3
a3 0x33ef6c49 0x33ef6c49
a4 0x7fea5983 0x7fea5983
a5 0x2fabcbcf 0x2fabcbcf
fp 0x70fc 0x70fc
sp 0x70fc 0x70fc
ps 0x2704 0x2704
pc 0xffe0c860 0xffe0c860
vbr 0x3fc 0x3fc
cacr 0x0 0x0
acr0 0x300f6000 0x300f6000
acr1 0x300f6000 0x300f6000
rambar 0x20000000 0x20000000
mbar 0x10000000 0x10000000
csr 0x1000000 0x1000000
aatr 0x5 0x5
tdr 0x0 0x0
pbr 0x0 0x0
pbmr 0x0 0x0
abhr 0x0 0x0
ablr 0x0 0x0
dbr 0x0 0x0
Notice MBAR is not set. This could be confusing if are expecting to look
at devices connected to chip selects. The dbug monitor ROM has not run
so no coldfire resources have been setup.
The Coldfire has a nice feature for BDM reset debugging. If you do not
change the program counter with a command such as:
(gdb) set $pc=start
or
(gdb) set $pc=0xdeaddead
The coldfire core will perform the normal stack pointer and reset vector
fetch. For the sbc5206 eval board I am connected to, to step the dbug
boot code do :
(gdb) display /i $pc
1: x/i $pc 0xffe0c860: moveb %a0@(21),%d0
(gdb) si
0xffe00404 in ?? ()
1: x/i $pc 0xffe00404: movel #-2097152,%d0
(gdb)
0xffe0040a in ?? ()
1: x/i $pc 0xffe0040a: moveal %d0,%sp
(gdb)
0xffe0040c in ?? ()
1: x/i $pc 0xffe0040c: movec %sp,%vbr
(gdb)
0xffe00410 in ?? ()
1: x/i $pc 0xffe00410: movel #16777216,%d0
(gdb)
0xffe00416 in ?? ()
1: x/i $pc 0xffe00416: movec %d0,%cacr
(gdb)
You might notice GDB repeats the last command entered if you just hit
enter.
When you run gdb connected to an embedded target like this the `run'
command is not used. The `target' command connects you to an existing
"process". The run command when used on a native system such as Linux
creates the "process" to be debugged. Your embedded target is an
existing "process" so no need to use the run command. You just step or
continue.
Now to running some code you have compiled with the -g option. The
driver has an example gdb init script. Look in `gdbScripts/5206.gdb'. I
usually copy this script to the directory where the coff file to be
debugged sits and rename it to `.gdbinit'. I am working on a boot rom
for the sbc5206 eval board. All I added to the end of the file in the
driver archive is :
dir ../../../kernel/boot/net
dir ../../../kernel/boot/net/drivers/clock
dir ../../../kernel/boot/net/drivers/net
dir ../../../kernel/boot/net/loaders
dir ../../../kernel/boot/support
dir ../../../arch/m68k/5206/boot
target bdm /dev/bdmcf0
addresses
setup-cs
setup-dram
load
set print pretty
set print asm-demangle
I then run :
$ m68k-bdm-coff-gdb sbc5206.coff
GNU gdb 4.17
Copyright 1998 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=i686-pc-linux-gnulibc1
--target=m68k-bdm-coff"...
(gdb) si
0x404 in start ()
(gdb) x /20i $pc
0x404 <start+4>: lea 0x0 <V___ISSP>,%sp
0x40a <start+10>: movec %sp,%vbr
0x40e <start+14>: movel #536870913,%d0
0x414 <start+20>: movec %d0,3076
0x418 <start+24>: moveal #536871420,%sp
0x41e <start+30>: nop
0x420 <start+32>: nop
0x422 <start+34>: moveal #536870912,%a0
0x428 <start+40>: moveq #51,%d0
0x42a <start+42>: moveq #0,%d1
0x42c <start+44>: moveb %d0,%a0@
0x42e <start+46>: moveb %a0@,%d1
0x430 <start+48>: cmpl %d1,%d0
0x432 <start+50>: bnew 0x518 <_stop_cf>
0x436 <start+54>: notl %d0
0x438 <start+56>: andil #255,%d0
0x43e <start+62>: moveb %d0,%a0@
0x440 <start+64>: moveb %a0@,%d1
0x442 <start+66>: cmpl %d1,%d0
0x444 <start+68>: bnew 0x518 <_stop_cf>
(gdb) b boot_cpu
Breakpoint 1 at 0x522: file cpuboot.c, line 63.
(gdb) c
Continuing.
Breakpoint 1, boot_cpu () at cpuboot.c:63
63 CF_DISABLE_AND_INVALIDATE_CACHE();
(gdb) l
58 UINT32 i;
59 #endif
60
61 /* disable and invalidate the instruction cache */
62
63 CF_DISABLE_AND_INVALIDATE_CACHE();
64
65 /* program the system protection register */
66
67 CF_SIM_WRITE_SYPCR(CF5206_BASE,
(gdb)
What happens here is the .gdbinit script programs the MBAR, chip selects
and enables the DRAM. DRAM is at 0. My linker command file places
`.text', '.data', and '.bss' one after each other at address 0. The
first part of the text seciton is the vector table. This how-ever is
moving away from gdb to the other tools and this mail is long enough at
it is.
--
Chris Johns Networks, Plessey Asia Pacfic Pty. Ltd.
mailto:ccj@acm.org mailto:cjohns@plessey.com.au
________________________________________________________________________
ColdFire Discussion List
See: < http://www.WildRice.com/ColdFire/ >
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.
More information about the crossgcc
mailing list