Øyvind Harboe wrote: >> - Changing JTAG state transitions to use shortest path rather than 7 clocks >> - Fixing all the drivers that assumed 7 clocks per transition >> > > Why would you want to change this? We've got pathmove for those cases > where the path matters...? > > Said another way, this is tantamount to using the new tms_seq table in jtag.c. One cannot simply use the shorter bit vectors without adding calls to tap_get_tms_path_len() in the cable driver. So it is to be considered an atomic operation that:
1) when a driver switches over to the new tms_seq table, that it also 2) add calls to tap_get_tms_path_len() so it can determine how many clocks to issue for each tms bit vector, and that it also 3) add rigorous tap_set_state() calls anytime a new tms bit is clocked out. Doing this transition for all drivers will take some time, maybe a month. Also, there is non-driver code in openocd that will break when using the new tms_seq table. I found some in xsvf.c, and there could be more elsewhere, maybe svf.c. I am fixing the xsvf.c stuff along with my current work. The interesting thing is, that once the above items 1), 2) and 3) are done, those changes should make it possible to switch back to the old tms_seq table. This makes it nice while doing the work of 1) and 2) for each driver, that you have another test case to test your driver changes against. When using the old table, tap_get_tms_path_len() simply returns 7, for all entries and the driver should work exactly as before. Then you get to the point where you can bounce back and forth between the two tables, and use the nice tap_set_state() logging to see the shorter number of clocks. In theory the paths taken are usually the same (some questionable exceptions), but the "clock consumption" stops are then gone. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
