Michael Bruck wrote: > On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > >> I propose some changes to the jtag subsystem >> >> - Add jtag_add_statmove( endstate ) call, the code is already in >> jtag_add_tlr() >> >> - Remove the JTAG_RUNTEST cmd type. >> >> - Implement jtag_add_runtest(n) as >> jtag_add_statemovet(TAP_IDLE) >> jtag_stableclocks(n) /* Should be n-1 if current tap state is not >> TAP_IDLE ?? */ >> >> - Implement jtag_add_tlr() as >> jtag_add_statemovet(TAP_RESET) >> jtag_stableclocks(6) /* I am not 100% sure about this here */ >> > > It might work, but it obscures what is going on. Sometimes statemove > would succeed and sometimes not but then stableclocks would do the > job, because the JTAG driver uses the then false state information > from the upper layer. Why would you add such obscure mechanisms to the > code? > No driver can ever know if the target jtag hardware is in TAP_RESET or not ( or any other state for that matter ). I think that this is a way of acknowleding this fact, not hiding it in much more obscure driver variant code. > statemove should be a move between two defined states, not a reset > from an unknown state. Especially not as long as the engine does not > allow even defining the state to be unknown. > A statemove to TAP_RESET is a very well defined move even if the current state is unknown, the jtag state engine was defined to make it so, and as far as we know it is between two known states. The problem is that after reset the tap_state is NOT well defined, even if we would like it to be. In the best of all worlds with good documentation and flawless configuration scripts it could be. > jtag_add_tlr() should be implemented as a distinct command in the > driver layer and not mixed into statemove. Otherwise you get (exactly > as it is now) inconsistent behavior between the lower layer > implementations because every driver has its own collection of if's to > deal with special cases (like TLR). > Implementing tlr in the driver layer does not remove driver specific inconsistenices. TLR should not be a special case for a driver, it is simply just another tms sequence. Putting the logic in jtag.c make behaviour more consistent.
My logic is that all jtag operations except for scans, are done by statemoves, pathmoves and and stable clocks, trst and srst are outside of the jtag stateengine. So why not build tlr and runtest() from these elements ? Regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
