> 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.

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.

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.

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.

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.

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?

-- Chris Caudle


