On Tuesday 08 December 2009, Øyvind Harboe wrote: > The changes you are proposing look *great* but I wonder if > they shouldn't be spread out over 0.4, 0.5 and possibly > also 0.6 to get enough feedback on the work along > the way.
Assuming they all get done, they'd absolutely need to be spread out over enough time to consider each proposal, and to address that feedback. > When it comes to cleaning up global state(a precursor to > multiple jtag interfacs), then my favorite would be > to abolish jtag_set_end_state(). Even "simply" getting > rid of jtag_set_end_state() would require a *vast* amount > of regression testing on real hardware. Yeah, every time I see that I scratch my head and say "WTF". It should be derived from "real" scan chain operations. > I would much rather > push the end state into the target layer. Presumably > there would be no need to coordinate end state across a > heterogeneous JTAG chain or if there were, then I suspect > a naive concept of a global end state per interface would > be insufficient. Yoicks ... that kind of interaction is sick: not being able to talk to one TAP, because another one is sniffing the JTAG state transitions! Maybe that's why there seems to have been a slowdown in the IEEE 1149.7 work ... it was originally using a "zero byte scan" to kick in new functionality, but I saw some alternate noise about not using TCK more recently. > What I would like to see pushed before 0.4 are sweeping > changes with low risk profile, so as to make branches > easier to maintain. Not too many more such changes though, I hope. :) I think all the ones we planned on are now finished (many from Zach) and I think the tree is much-improved in consequence. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development