I definitively agree on David B. mail and would like to add a few comments.
> If I remember correctly, PPC debug (at least on the MPC5xx that I used > long ago) is done by using the JTAG interface to insert instructions > directly into the instruction stream. The concept is simple enough, > and very powerful. But the details of which instructions to send will > be hard, and as you say there are a /lot/ of variants - including > different types of compression on the instruction sets. External debugging is done by direct jtag access to debug registers, by shifting instructions in the CPU scan chain and reading/writing data at the same moment on the bus (as you are describing) and by using Nexus module for memory access. There is an interesting AN giving a good overview and many details: http://www.st.com/resource/en/application_note/dm00046345.pdf Currently I am able to read memory with the Nexus (except that I still have many problems with the RAM probably because of the MMU), and I have not dug yet stuff with the CPU scan chain, though I guess this will not be easy. Depending on the MCU variant, either the PPC VLE, the PPC 32 bits, or both instruction sets are used. I plan to go with the VLE. Fortunately I have already a working debugger and I can capture, analyse and replay its output. About the modifications in the current OpenOCD design, the main one for the moment is the ability to force or to prevent the JTAG adapter to move through the DR PAUSE state. It is possible that new constraints will be needed while development goes on. Another thing is how to separate access to the different modules (core/nexus/jtag master controller) in the source and the level of configuration through TCL script, but I do not focus on this at all for the moment. I prefer coming with one monolithic draft working for one MCU variant and rework it later once I have a better view of these MCUs and OpendOCD internals. > There are some nice industrial and automotive PPC microcontrollers, > however. These are used in the car industry and other > high-reliability systems - and are almost invariably used by bigger > development groups using expensive commercial tools (compilers from > Green Hills, debuggers from iSystem, commercial RTOS's, etc.). At the > low end you have CodeWarrior toolchain and P&E Micro debuggers. There > is little support in gcc and gdb for these kinds of devices, and I > can't see there being many people who would want to use OpenOCD with them. I think you are pretty right here. To give you more background about why I started working on the xPC56x support, it is because a part of the previous company where I was working has been bought by an automotive one, and the industry practices I discovered replaced the open source and community support I was used to work with by closed tools and expensive fees. The main goal behind this implementation is more to do something interesting than saving the cost of a few licences. I will also highlight that this situation is a bit uncertain. I do not think the implementation will reach a production-ready quality, but I hope at least to propose some code allowing basic operations. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
