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

Reply via email to