Calypso JTAG documented

[Mychaela Falconia]

Hi Harald!

> Wouldn't it make sense to submit that new openocd config to openocd for
> inclusion in their repository, to ensure future builds of openocd
> will have good out-of-the-box support for Calypso?

If you look at the proof-of-concept config I have created, you will
see that it goes against all of OpenOCD's guidelines, starting with
the lack of separation between the JTAG adapter (I furthermore use an
FT2232D breakout board instead of a "proper" JTAG adapter) and the
target to be debugged.  The first difficulty with shoehorning Calypso
support into OpenOCD's canonical architecture is that our XDS_RESET
line does not sensibly correspond to either SRST or TRST; one could
make it look like either SRST or TRST to OpenOCD, but neither lie is
really any good, so I couldn't decide between the two.  If I break
OpenOCD's paradigm and do away with the interface vs. target separation,
I can name the signal XDS_RESET (neither SRST nor TRST) and use my own
ad hoc Tcl procedure to produce the reset pulse, which is what I have
done, but the same approach won't be possible if the separation
paradigm is to be obeyed.  Furthermore, I was not able to hook the
necessary logic for "reset and halt" into OpenOCD's native reset
command (the provided hooks aren't flexible enough), so I went totally
brute force about it and made up my own reset_run and reset_halt
commands (Tcl procedures) replacing standard 'reset run' and
'reset halt' operations - clearly not an acceptable approach for
inclusion in mainline OpenOCD.

I can meet the wider community half-way by subscribing to the OpenOCD
mailing list and explaining to OpenOCD developers what I have done
(show them my proof of concept) and why I couldn't implement Calypso
support in a way that follows their paradigm, but if someone wishes to
have good out-of-the-box Calypso target support in mainline OpenOCD,
the bulk of the work will have to be on them, not on me.

M~