On Tue, Apr 28, 2009 at 11:01 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: > On Tue, Apr 28, 2009 at 10:48 PM, Dick Hollenbeck <d...@softplc.com> wrote: >> Michael Bruck wrote: >>> >>> So my question would be: does anyone know if the drivers produce >>> different state transitions (except for idling on stable states) for >>> the jtag_* calls, including more complex stuff that involves >>> jtag_add_ir_scan etc. ? >>> >> >> This is a superbly excellent question. > > To which the application code should assume "yes". Different drivers > *will* do different things. Use jtag_add_pathmove() when specific > behaviour is required. > > I've updated the documentation of jtag_add_pathmove() to > explain this a bit.
Ok, I checked that. It seems, to have predictable behavior the complex operations should end with the pause state and everything else should be done via pathmove. I don't have time immediately to rewrite that since the modified algorithms need checking. >> One that is related to my question >> about WTF is the tap machine even doing while I am programming an FPGA. >> This is precisely why I felt it absolutely necessary to implement state >> transition logging. That exists in its earliest form on the ft2232.c patch >> I just submitted. Once we have this in place for *all* drivers, then it >> might actually be possible to ANSWER your most excellent question, which is >> related to mine. >> >> You could then compare the paths taken between two cables. > > So each interface driver must be responsible for logging transitions as > only the interface driver could possibly know(even the driver might not > actually know the precise path if this is somehow implemented by > lower level hardware/firmware). I thought the logging idea is helpful, but it seems in the end the arm11 driver needs a general re-write as I would rather not have to worry about non-deterministic behavior of the JTAG interface driver at all. And the way to guarantee that is via the pathmove-for-everything approach. Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
