When I first looked into this topic around 2004 I spend quite some time searching for open source alternatives to software like macraigor's ocdremote/ocdcommander and high-end tools like the BDI2000. There were a few projects but none of them was in a useable state and they're all unmaintained by now, which is why I started my own project which ended up being released under the GPL as the OpenOCD. The OpenOCD may not be perfect for everyone's taste, but it's probably the best free (as in speech, just so we don't get that argument again...) solution you can get at this time. With this as my background I'll comment on your requests:
(1): There are three USB based JTAG interfaces supported by the OpenOCD available:
- FT2232 based designs (some readymade devices from commercial vendors, some free designs that can be built for little money)
- usbprog
- ASIX PRESTO All of those can be used on any of the supported platforms which include 32 and 64 bit Windows, Linux, *BSD and Mac OS-X, as long as either libusb/libftdi or FTDI's binary FTD2XX library is available.
(2): RTCK isn't supported by any of the designs currently available, but I don't think this is much of a problem. Just make sure that the JTAG adapter is set to run at less than 1/6th of the core frequency. You can later increase the JTAG frequency again after code running on your target enabled and selected the PLL. If you think that support for RTCK is really necessary then it wouldn't be hard to design a USB interface that supports RTCK yourself.
(3): The FT2232 based designs and the usbprog meet this requirement. A commercial vendor is hardly going to open up their device's specifications because that makes it easy to copy the design. There is only limited complexity in the JTAG interfaces themself, and vendors don't want counterfeit hardware to be used with their software packages. This became a problem for Macraigor with their Wiggler, and only a few weeks back someone posted schematics and firmware for a Keil ULink to the yahoo lpc2000 group. One exception is isystem's (Boudewijn Dijkstra just reminded me of them with his post) iF-DEV package, for which they even provide all documents necessary to build your own, but this comes with some strings attached (e.g. only non-commercial use). I have to admit that I didn't look too closely at their offering though, so you'd have to evaluate yourself if this suits your needs.
(4): Most/all of the logic required for ARM debugging would have to be part of that GDB server, because GDB itself isn't concerned with anything beyond "halt/resume target", "read/write registers" or "read/write memory". A vendor of non-free software certainly isn't going to open up all that knowledge to potential competitors. ARM debugging is documented in the various ARM TRM's, the XScale manuals, and various bits and pieces around the internet. The tricky part is probably those bits that are missing, but it's possible to work all these things out yourself. The only commercial player in this field that could have an interest in free debug tools for ARM cores is ARM itself, but they sell both their own RealView stuff and they own Keil, so it's quite unlikely to expect them to come up with free software to compete with their own hard- and software. Chip vendors would have to create software that could be used with their competitors products as well, so this isn't going to happen either. A vendor of JTAG debug tools would a) open up his knowledge to competitors and would b) risk the money he's making from hardware sales, once someone adds support for other hardware or if someone starts selling counterfeits of his hardware.
My point is that the situation isn't going to change because of what one vendor does, as they have little/no reason to release their stuff to the public. If you want free tools you'll have to develop them yourself. The OpenOCD is there as a starting point, but of course you're free to start over again if you don't like the approach I've taken. Additional JTAG interfaces can be added quite easily to the OpenOCD, and a solution consisting of a USB chip + CPLD/small FPGA that includes RTCK support etc. wouldn't be hard to build.
Best regards,
Dominic Rath