bdm Tools

M68K BDM GDB Server

Introduction

The BDM package contains a GDB Server that operates as a separate processes interfacing to GDB using the GDB Remote Protocol. The GDB server code included in the BDM package is based on the code in the GDB package. The code has been changed to:

allow the GDB server to use the pipe interface on Windows and Unix.
additional flags for registers to allow the definition of non-cachable, read only and write only flags.
support to allow the low level code detect a processor and return the XML file that matches.

The intention is to submit these changes back into the GDB project.

Using a GDB server allows you to use a binary GDB from a range of tool vendors to access your target hardware using the BDM pods this projects supports. You will be using an open source BDM solution with the open source GDB. We can also update the BDM server with new features and bug fixes and your GDB tools do not need to change.

Using the M68K BDM GDB Server

The M68K BDM GDB server is best used as a back ground process started within a running GDB. The GDB target remote command allows you to start a back-ground process using:


(gdb) target remote | command

Build the BDM package and install it. The install procedure will install the command m68k-bdm-gdbserver. Make sure this command is in your current path or reference the command with an absolute path. The command to start the GDB server with the default options with a TBLCF USB pod is:


(gdb) target remote | m68k-bdm-gdbserver pipe /dev/tblcf2

trying kernel driver: /dev/tblcf2

trying bdm server: localhost:/dev/tblcf2

m68k-bdm: detected MCF5235

m68k-bdm: architecture CF5235 connected to /dev/tblcf2

m68k-bdm: Coldfire debug module version is 0 (5206(e)/5235/5272/5282)

Process /dev/tblcf2 created; pid = 0

You can operate GDB normally from this point on.

The M68K BDM GDB Server can also be manually started outside of the GDB on another machine and GDB can connect using the TCP protocol command of:


(gdb) target remote host:port

The start the M68K BDM GDB Server using:


$ m68k-bdm-gdbserver :7777 /dev/tblcf2

trying kernel driver: /dev/tblcf2

trying bdm server: localhost:/dev/tblcf2

m68k-bdm: detected MCF52223 (MCF52235)

m68k-bdm: architecture CF52223 connected to /dev/tblcf2

m68k-bdm: Coldfire debug module version is 9 (52223/52235)

Process /dev/tblcf2 created; pid = 0

gdbserver: Listening on port 7777

The TCP mode is supported because the original code is provides this support but it is of limited value and the BDM server can provide a better way to perform remote BDM debugging. The BDM server does not require you log into the remote machine. The BDM server runs from the xinetd daemon automatically. The TCP mode of operation does provide a useful way to debug the BDM GDB Server.

M68K BDM GDB Server Options

The M68K BDM GDB Server has two levels of options. The first is the standard GDB Server options and you can see them using the -h options:


$ m68k-bdm-gdbserver -h

gdb: Usage:     m68k-bdm-gdbserver COMM PROG [ARGS ...]

        m68k-bdm-gdbserver COMM --attach PID



COMM may either be a tty device (for serial debugging), or

HOST:PORT to listen for a TCP connection.

The first argument is the COMM and it can be a host and port for a TCP connect or pipe for back ground operation with GDB. Using a serial device is not really needed with the M68K BDM GDB server.

The second level of options are specific to the M68K BDM part of the GDB server. You can access these options using:


$ m68k-bdm-gdbserver pipe -h

m68k-bdm 1.4.0

m68k-bdm -vVhBDd -t <time> <device>

 -v      Verbose. More than one the more verbose.

 -V      Version.

 -h      This help.

 -B      Treat all breakpoints as hardware breakpoints. Useful for flash.

 -D      Driver debug level. More than one for more debug.

 -d      BDM Library debug level. More than one for more debug.

 -t time Delay timing for the parallel ports.

 device  The device to connect to such as /dev/bdmcf0.

no device path found

m68k-bdm-gdbserver: Exiting

The <device> option is required and defined the BDM device to use to debug. This can be a remote BDM server. For example m68k-bdm-gdbserver pipe lab:/dev/tblcf2.

The other useful option is -B. This makes all breakpoints requests from GDB use hardware breakpoints. Use this option when debugging code in flash. It will allow you to use GDB's next command. The number of hardware breakpoints your target uses will define what you can do with this options. If you have only one hardware breakpoint register on the target you will be only be able to set one breakpoint and next will not work.

The remaining options help debug the M68K BDM Server.

Debugging the M68K BDM GDB Server

Debugging the M68K BDM GDB Server requires using the -v, -D, and -d options. These will output a range of error messages and will appear on the standard output of the GDB server process or the console of GDB. You can have more than one on the command line to obtain more debug information.

The driver debugging messages will depend on this GDB server using a BDM server or not. If a BDM server is being used the driver messages will be generated by that processes.

If you need to run GDB in the M68K BDM GDB server you can connect to it once it is running.

It often pays to run the M68K BDM GDB Server with the TCP remote protocol as root to see all the possible error messages.

Adding Registers to the M68K BDM GDB Server

The M68K BDM GDB Server contains the register definitions for all supported processors. It transfers the definitions to GDB when it requested after it detects the type of Coldfire we are connected to.

GDB expects the register definition as XML. The XML information is held in files that are built into the M68K BDM GDB Server. The low level BDM back end contains an internal table of the registers that matches the XML definition sent to GDB. To add new support you must create the XML file and the internal table of registers.

The XML files used include the base 68000 register definitions plus any processor specific registers. A register definitions has:

reg name	The name of the register as viewed from GDB.
bitsize	The number of bits in the register.
group	The type of the register. Use debug to hide registers from GDB.
regnum	The register number GDB uses for this register.

The internal tables are held in separate C files that are linked into the server. Create a new file and name for the table based on the Coldfire variant you wish to add support for. The table's fields are:

reg name	The name of the register as viewed from GDB.
reg type	The type of the register. Check the source code for details.
regnum	The register number as defined in the XML file.
code	The register code used to obtain the register from the Coldfire.
flags	The register flags used to control the register cache in the server.

To add files to the server edit the Makefile.am file. It is easy to add files so just take a look and have a go.

Finaly the processor needs to be detected. This is performed in the file m68k-bdm-low.c and the function m68k_bdm_create_inferior. There is a range of ways to detect the processor. The first level is based on the version of the BDM debug hardware. If more than processor uses the same version of the BDM debug hardware and has different registers you have to determine a way to detect the processor. An example is the 5235 and 5282 processors. The 5235 is detected by trying to access the XCSR register. If present it is a 5235 processor.

Please submit any additions back to the BDM project.

debugging for the Freescale Coldfire processor family