debugging a PPC405GP target

debugging a PPC405GP target

[Rolf Fiedler]

Hi there,

currently we are looking for a solution to debug gcc generated code
on the PPC405GP target. All debuggers I have found so far are hosted
on Win9x/NT. This is sub-optimal, since our tool-chain is hosted on
linux.

I know that I can use gdb with a gdb-server running on the target,
however I prefer access to the JTAG debug port of the PPC405GP.
The Macraigor Wiggler devices support JTAG debugging for PPC405
in the same way as for Motorola MPC8xx devices. There is a gdb
target for MPC8xx and Wigglers. What I would like to do is adapt
the source for the MPC8xx target to PPC405. My problem is that
I have no documentation about the PPC405 JTAG debug port (and couldn't
find it on ibm's web site either)
Is there anybody out there that knows of:
a) documentation for the debug port of the PPC405GP?
b) a different solution to the problem?
c) knows of somebody who has already done this?
any help is higly appreciated
kind regards,
rolf

--
+-----------------+-------------------------------------------------+
|    _____        |  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/

Re: debugging a PPC405GP target

[Jesper Skov]

>>>>> "Rolf" == Rolf Fiedler <Rolf.Fiedler@Ferrari.DE> 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/

Re: debugging a PPC405GP target

[Rolf Fiedler]

Jesper Skov wrote:
>
> >>>>> "Rolf" == Rolf Fiedler <Rolf.Fiedler@Ferrari.DE> 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/

Re: debugging a PPC405GP target

[Jesper Skov]

>>>>> "Rolf" == Rolf Fiedler <Rolf.Fiedler@Ferrari.DE> writes:

Rolf> this is plain wrong. I do not have to use gdbserver, gdbserver
Rolf> is just one possiblity. How can I use the hardware breakpoints
Rolf> in the debug-hardware on the target or have breakpoints in ROM
Rolf> when I use a low-tech debug approach like gdbserver?

I didn't make myself clear, sorry: when you use gdbserver you have a
"stub" which knows about the context in which the application runs
(the Linux operating system). You can (potentially) show thread
information, environment variables and the like [gdbserver doesn't
have thread support at the moment].

It's hard to get the same functionality from the wiggler (because it
only knows about the CPU state). But then it has other advantages as
you say.

>> 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).
Rolf> It would be not very smart to reduce the wiggler to a regular
Rolf> serial connection, since I have more features then I can address
Rolf> with the gdb remote protocol. The advantages are: - no software
Rolf> on the target (bootstrapping) - use of 4 hw address and 2 hw
Rolf> data breakpoints (try to use a watchpoint with gdbserver and
Rolf> you'll learn what performance really means :-)

There's nothing preventing you from implementing use of hardware
watchpoints and breakpoints in gdbserver. Would probably require some
kernel features to be added as well. But those debugging features are
part of the CPU, not the wiggler hardware.

As anything else OS, it's just a question of someone getting fed up
with the current state of affairs and implement the new stuff, making
the world a better place :)

Jesper

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: debugging a PPC405GP target

[Rolf Fiedler]

Jesper,

> I didn't make myself clear, sorry: when you use gdbserver you have a
> "stub" which knows about the context in which the application runs
> (the Linux operating system). You can (potentially) show thread
> information, environment variables and the like [gdbserver doesn't
> have thread support at the moment].
>
> It's hard to get the same functionality from the wiggler (because it
> only knows about the CPU state). But then it has other advantages as
> you say.
Since it is getting complicated, I start drawing pictures...

<require fixed width font>
1. traditional approach using monitor or gdb server


    +-------------------+             +----------------+
    |    host CPU       | serial or   |  Target running|
    | running cross-gdb |-------------|  gdb-server    |
    +-------------------+ thernet     +----------------+

gdbserver can store some [env, thread etc.] information, since it
runs on the target

2. simple CPU control debugging


    +--------------------+               +----------------+
    |      host CPU      | bdm, ice or   | target running |
    | running gdb and    |---------------|    nothing     |
    | device driver for  | jtag          |                |
    | wiggler            |               |                |
    +--------------------+               +----------------+

if the gdb remote stub implementing the ICE interface is implemented
smart enough, gdb has access to environement, thread etc. since it
can read any memory location in the target-system. This is not
possible, if the target runs an OS an has MMU protection for
processes, since it is hard for the debugger to figure out which
physical addresses contain the information required.

Theorem: Since the ICE link provides total control of the target CPU,
it allows to read any state in the target.
The wiggler does only toggle bits on the JTAG port, but the pen
(software) is mightier than the sword (soldering iron).

3. gdbserver on ICE

    +--------------------+               +----------------+
    |      host CPU      | bdm, ice or   | target running |
    | running gdb and    |---------------|    nothing     |
    | a gdbserver via    | jtag          |                |
    | local tcp link     |               |                |
    +--------------------+               +----------------+

same scenario as above, however no need to modify gdb, just gdbserver
must be modifed.

</require fixed width font>

> There's nothing preventing you from implementing use of hardware
> watchpoints and breakpoints in gdbserver. Would probably require some
> kernel features to be added as well. But those debugging features are
> part of the CPU, not the wiggler hardware.
you are right.
I know that the wiggler doesn't do anything but wiggle bits, however I
need access to the CPU via JTAG to use the internal debug registers like
address & data breakpoints. If I have this link, I do not need any
further links. If I was mentally insane, I could implement tcp/ip
via JTAG (write packets directly to RAM and poll memory locations)
and run gdbserver on target via this link.

the question is: what advantage does solution 3. (above) have compared
with solution 2.?

> As anything else OS, it's just a question of someone getting fed up
> with the current state of affairs and implement the new stuff, making
> the world a better place :)
I want to hack the minimal possible amount of code, I have no interest
in
making the world a better place. Since I learned that solution #2 exists
for MPC8xx, I wondered if somebody could help me change that for
PPC405GP.
The JTAG chain and commands will propably be different. I need docu for
that
part of the PPC405, and unlike Motorola IBM did not include sufficent
info
in the datasheets of the chip (will they ever learn what open is about
or
are they just making up some linux marketing hype?).

Thank you Jesper,
Rolf


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/