On Sunday 17 January 2010, Øyvind Harboe wrote: > I have given this patch some more thought and it breaks > the JTAG API and jtag_add_pathmove() API/driver layer > in particular.
$SUBJECT includes three patches ... which one do you mean? Also, in what sense does it "break" anything? As I noted, this has been working fine for some time on FT2232. So in at least that straightforward sense, it breaks nothing. > We should discuss more post 0.4(I need to choose battles > before then), OK -- but, I'll get my initial response out there now, like your initial query is. > but essentially the interface_ layer should be *told* > what the TAP state is after a given TMS sequence. I don't follow. For starters, > > +int jtag_add_tms_seq(unsigned nbits, uint8_t *seq, enum tap_state t); does pass a state. One issue with that state is of course the reality that when switching into SWD mode, or resetting a SWD link, there *IS* no TAP, or TAP state, that's relevant. The presumption that "TAP state" is meaningful at all times would be a conceptual bug. One that must not be continued by any driver which supports SWD. And that's clearly not documented as a substitute for the error checks in current set of upper level JTAG state calls. Which is why the updated pathmove()/statemove() logic does not use that call ... it uses the low level primitives, and continues using the current TAP state tracking mechanism. > The > current jtag_add_pathmove() passes this information to > the interface_ layer. I just looked at patch #2 of the three, which modifies that to use the new primitive when the underlying JTAG driver supports it. (Eliminating redundancy in those interface calls.) And I don't see how this changes anything of note. There is a mid-layer representation of the current state (after executing any queued ops), and that's still present ... and still visible to the interface layer. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
