quoted
quoted
quoted
quoted
"Rolf" == Rolf Fiedler [off-list ref] writes:
Rolf> Hi there,
Rolf> currently we are looking for a solution to debug gcc generated
Rolf> code on the PPC405GP target. All debuggers I have found so far
Rolf> are hosted on Win9x/NT. This is sub-optimal, since our
Rolf> tool-chain is hosted on linux.
Rolf> I know that I can use gdb with a gdb-server running on the
Rolf> target, however I prefer access to the JTAG debug port of the
Rolf> PPC405GP. The Macraigor Wiggler devices support JTAG debugging
I don't think this would work (or at least not easily). When you
access the target through a wiggler it's at a very low level (on the
CPU, basically - you don't communicate with software in the
target).
For debugging an application you need to communicate with gdbserver -
ethernet is the optimal solution, if your board has
ethernet. Otherwise you have to use serial.
You may be able to make the wiggler work as a regular serial
connection, but I don't see what you gain by that over using a
standard ethernet/serial connection (except if the only interface on
the board is the wiggler one).
Jesper
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Jesper Skov wrote:
quoted
quoted
quoted
quoted
quoted
"Rolf" == Rolf Fiedler [off-list ref] writes:
Rolf> Hi there,
Rolf> currently we are looking for a solution to debug gcc generated
Rolf> code on the PPC405GP target. All debuggers I have found so far
Rolf> are hosted on Win9x/NT. This is sub-optimal, since our
Rolf> tool-chain is hosted on linux.
Rolf> I know that I can use gdb with a gdb-server running on the
Rolf> target, however I prefer access to the JTAG debug port of the
Rolf> PPC405GP. The Macraigor Wiggler devices support JTAG debugging
I don't think this would work (or at least not easily). When you
access the target through a wiggler it's at a very low level (on the
CPU, basically - you don't communicate with software in the
target).
You are right here, very low level... I need so send a bitstream
containing
commands and register values etc. It has been done for a number of gdb
targets (CPU32, Coldfire, MPC8xx).
There a different types of gdb targets - remote targets that communicate
the gdb remote protocol with a gdbserver AND "native" remote targets
that have the ability to control the target (via hardware) directly.
I have done a gdb target for Motorolas coldfire processors using BDM
on the parallel port. gdb talks with a linux kernel driver that toggles
the bits in the parallel-port dongle that start/stop/control the CPU.
For debugging an application you need to communicate with gdbserver -
ethernet is the optimal solution, if your board has
ethernet. Otherwise you have to use serial.
this is plain wrong. I do not have to use gdbserver, gdbserver is just
one possiblity. How can I use the hardware breakpoints in the
debug-hardware
on the target or have breakpoints in ROM when I use a low-tech debug
approach like gdbserver?
You are right about ethernet being optimal, but only in one domain. If
you have the hardware up and running an are a software type of guy that
has to develop firmware, then the improved download speeds of the
ethernet/
gdbserver solution make you forget about the reduced debugging
capabilities.
You may be able to make the wiggler work as a regular serial
connection, but I don't see what you gain by that over using a
standard ethernet/serial connection (except if the only interface on
the board is the wiggler one).
It would be not very smart to reduce the wiggler to a regular serial
connection, since I have more features then I can address with the
gdb remote protocol. The advantages are:
- no software on the target (bootstrapping)
- use of 4 hw address and 2 hw data breakpoints (try to use a watchpoint
with gdbserver and you'll learn what performance really means :-)
--
+-----------------+-------------------------------------------------+
| _____ | Rolf Fiedler (Electronic Design Engineer) |
| / ___/ | Ferrari electronic AG |
| / _/ | phone: +49 3328 4559 0 fax: +49 3328 4559 60 |
| /_/e/r/r/a/r/i/ | <http://www.Ferrari.DE> |
| electronic AG | <mailto:Rolf.Fiedler@Ferrari.DE> |
+-----------------+-------------------------------------------------+
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/