gdb with Riscwatch (PPC JTAG debugger)?

[Smith, Gene]

Chris Caudle wrote, On 8/30/2004 1:41 PM:

>> But not sure what this all is and how it works together and with
>> gdb and rtems and with my one-of-a-kind ppc405gpr board.
> 
> 
> The short version is that the JTAG (standard IEEE 1149) test port,
> usually used for boundary scan testing in production to make sure all
> the pins were soldered down, has a test mode that supports stopping
> program execution, dumping the state of every register in the
> processor, and allowing you to continue single step instruction
> execution. Some processor families also have a trace capability which
> lets you capture a trace of program execution while running at full
> speed, which can be useful in debugging timing specific problems, or
> timer handling, etc.

You can also load your program to ram via JTAG, right?

> 
> The Macraigor debugger linked to is one type of device which connects
> to the PowerPC JTAG port on one end, and a development machine on the
> other side, to allow debugging of the target system.

I assume you can use gdb (or ddd or whatever) talking the Macraigor box 
via ethernet and fully debug your system (including download to ram). 
And you don't need a rom monitor in the target?

> 
> My problem is that we have a large number of IBM Riscwatch JTAG
> debuggers, probably more than 50, and I would really like to make gdb
> work with those, rather than replace all of the JTAG debuggers at a
> couple thousand US$ per.

When you say you have 50, you mean you have the jtag adapter boxes, right?

> 
> We are just starting firmware development for a new project based on
> PPC440SP (was IBM, but now AMCC bought that line).  The most similar
> current product in that family lineage had been based on ATI Nucleus
> (now owned by  Mentor Graphics), built with a Diab compiler (now
> owned by Wind River) and debugged using SDS Single Step (now owned by
> Wind River) through the IBM Riscwatch JTAG debugger.

This is where I get a bit confused. From what I read, the Riscwatch 
product (s/w and hardware) is a standalone debugger. I don't see any 
mention of it containing a 3rd party debugger (Single Step). But I might 
have missed something in reading about it.

Or you must mean gdb would be talking to the Riscwatch hardware (with no 
Riscwatch debugger software involved).

> 
> All those corporate acquisition in the tool chain have been causing
> big license headaches, and the vendors are not supporting the new
> processors very well.  The firmware team is nearly ready to chuck the
> whole mess overboard.
> 
> I've been dropping hints that they should really move to an open
> source model for tools and RTOS, which would allow us to just pay for
> support and code improvements.  I think I would have a chance to
> convince the firmware team to try RTEMS if, and a big IF, the tool
> set can support our debugging hardware.

Where (Debugging hardware == Riscwatch hardware component), right.

> 
> Anyone know if the Cygnus guys at Red Hat are still doing gcc and gdb
> maintenance work on contract? If I wanted to pay someone to make sure
> gcc supported the 440 processors well, and to make gdb support
> Riscwatch debuggers, who would I go to?

So I guess someone would need to reverse engineer the protocol between 
the Riscwatch s/w and its hardware and incorporate it in gdb, like these 
debuggers apparently have for the E5900B you mentioned in your next message,
IBM RISCWatch 4.7
Mentor XRAY V4.3b
Green Hills Multi v3.0
WRS SingleStep 7.62
(no mention of gdb)

The macraigor use something called OCDLibRemote to translate gdb to jtag 
as described here. But probably only works with their h/w, not riscwatch 
h/w I would assume. Not sure if it is free s/w.
http://www.macraigor.com/full_gnu.htm

Sorry if I am just re-stating the obvious or completely misunderstand 
the original question.
-gene

> 
> -- Chris Caudle
>