On Monday 22 June 2009, Øyvind Harboe wrote: > My favourite is to introduce a serialized protocol for JTAG that > can work over TCP/IP, pipes, even fn calls...
Such a thing would be useful for a more functional USB interface to JTAG adapters. Consider some microcontroller using a (high speed!) USB interface and accepting those serialized JTAG messages. TMS transitions; shift this data in, return (or discard) the data shifted out; and some GPIO-ish commands for SRST and TRST. That'd be the bare minimum. Such a protocol should also provide two more things: - The immediately-useful one would be offloaded polling. As in: issue this command; if F(result) do this else do that; continue for more commands. And the "do..." would involve reporting some data back. Yes, that involves limited programmability... - The less-immediately-useful one would be collecting such data for non-JTAG signals, in support of debug instrumentation and event triggering. EMU0/EMU1/... on TI's JTAG connectors. Or, more fully documented, ARM or Nexus trace connectors. Another way to think of this is as an *OPEN* protocol for talking with JTAG adapters. A soft one, which could more easily evolve over time (e.g. to deal with the upcoming 2-wire JTAG flavors.) The FT2232 is one vendor-specific flavor of "open" ... and this thread highlights problems derived from that vendor. Downside: current tools vendors might prefer to have closed protocols there, as aids to vendor lockin. It's easier to sell "Our Adapter(s) + Our Software = $$$$$". > This has been discussed before and could be *very* useful > for other stuff, including remote access to targets for debug > purposes... > > OpenOCD would itself also implement this as a server > to forwarding it to the underlying driver, acting as the server. That's a second model though. Draw a line, if you will, between a "smart JTAG" level server, and a target level service which understands how to single step ARM9TDMI versus Cortex-M3, etc; or provides good boundary scan debugging/diagnostic tools; etc. Today's OpenOCD handles both services (and more). If you split out "Smart JTAG", would OpenOCD be the split-out part ... or the target level service? I'd lean towards the latter. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
