Dick Hollenbeck wrote:
> Just a heads up on this table. Because the old table had an implicit
> length of 7 bits understood, often there are "clock consumption" stages
> in the old path, enough to consume 7 clock cycles and still get to the
> final destination.
>
> That is, if the transition needed less than 7 clocks, there still had to
> be combos of states in which to spend all 7 clocks, and sometimes this
> looks like it was at the first train station stop, a middle train
> station stop, or at the final destination. Each path combo could be
> different. So I think this this makes using the old hex values as a
> reference potentially misleading without these goggles on.
>
And with this understanding in place, it means that drivers cannot use
the new table without also using the new call to
int tap_get_tms_path_len( tap_state_t from, tap_state_t to )
So this makes the migration more difficult. One thought that could
enable a graceful migration is to have two tables in there, but compile
the needed one depending on which driver is in play. One of the two
tables is the old table, and one is the new table. Then as each driver
is updated, we just remove another #if defined() test from jtag.c
#if defined(<driver1>) || defined(<driver2>) || defined(<driver3>)
/* drivers needing the old table */
... old table declaration here
#else
.. new table
#endif
There may be another way, but I don't see it.
Dick
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
