Magnus, I think we are talking past each other. There are nouns used in your sentences that need to be defined.
For example search below for "state_move". Its meaning is not clear. We need to take MUCH more time and articulate what problem we are even talking about let alone what problem we are trying to solve. The problem I solved with the Jeff Williams patch is the wasting of clock cycles. Maybe another thread can be started for stable states. It was discussed elsewhere last week and the consensus was that stable states were the only endpoints that you can count on because clock cycles are not always halt-able on all cables. I do not want this side tracked discussion to be an impediment to getting my work done yesterday and today accepted. My head will explode. What I accomplished is to put in place a platform for experimentation of shorter TMS sequences. And diligent state transition logging. The first was a favor to Jeff, the 2nd is mandatory to do troubleshooting for me. Thanks, Dick > I am not sure we really have a problem. > > * We can easily, I am willing to do it, expand the shortest path table > to arbitary start and end states. This will work with minor changes > inside the tap_get_tms_path and without any changes for callers. > > * We can restrict state_move to stable end states or both. And we can > let path_move use the tap_get_tms_path to generate paths with arbitary > start and end states. > > * I agree with Michael, put the restrictions in the upper levels, that > would be state_move > > Regards, > Magnus > > > > Dick Hollenbeck wrote: > >> Michael, >> >> >> >>> 1. The underlaying jtag_* layer should produce the same transitions >>> regardless of the JTAG device. Is there a technical reason why that is >>> not possible? >>> >>> >> Not that I am aware of. >> >> >> >>> The ARM11 driver is certainly programmed with that >>> assumption in mind. >>> >>> I don't think the tap_get_tms_path() is a usable solution, >>> >>> >> It *is* usable solution, but to a problem other than what you are >> thinking about. Trust me, I would not have spent two days on this >> otherwise. >> >> Remember the tap_get_tms_path() is in the "Cable helper API", it is not >> at the same level as jtag_add_pathmove(int num_states, tap_state_t* path); >> >> jtag_add_pathmove() is at the level of your ARM concerns, and can be >> used with confidence in my opinion. We need to remove the comment in >> the jtag.h that says "please don't use this function". >> >> Nothing below is relevant to my current work, sorry. >> >> Dick >> >> >> >> >>> i would >>> probably just use explicit pathmove instead because the resulting code >>> would be heavily cluttered with tons of IFs trying to figure out what >>> the JTAG driver is doing. Plus it is not testable by those of us that >>> don't keep piles of different JTAG devices around. >>> >>> >>> 2. My proposal to deal with alternative paths would be as follows: >>> >>> All available alternatives can be encoded in a bit field and passed as >>> extra parameter to the relevant calls or set in some sort of >>> jtag_set_paths(u32 paths) function. >>> >>> For example: >>> bit0 Capture-DR >>> bit1 Capture-IR >>> bit2 Exit1-DR >>> bit3 Exit1-IR >>> bit4 Exit2-DR >>> bit5 Exit2-IR >>> bit6 Update-DR >>> bit7 Update-IR >>> >>> The semantics would be as follows: >>> - If in a transition between states one of these eight states lays in >>> the path and >>> - if it is possible to reach the destination by choosing either 0 or 1 >>> in that state >>> then use the value from the bit field. >>> >>> The shortest possible path is selected by setting all bits in the mask >>> to 1 except for Exit2-?R. >>> >>> >>> 3. On a mildly related note, since that was discussed here last week, >>> the restrictions to stable states are in conflict with the actual TAPs >>> which are usually optimized to allow maximum bang for the clock tick. >>> >>> As a result the driver code is not in sync with the documentation both >>> in regards to the TAP states used and the way algorithms are wrapped >>> into functions and the driver is layered. For example in the arm11 >>> code it is not possible for a lower layer which ends its algorithm at >>> Update-DR to know if the layer above needs to go via RTI or not. So >>> the lower layer leaves the TAP at Pause-DR instead thus outsourcing >>> the move to Update-DR to an upper layer. This results in unnecessary >>> complexity in the code and most likely in chaos when someone later >>> touches this fragile house of cards. >>> >>> The stable-states-only restriction should be retired at the earliest >>> possible opportunity. And it should weighted if the benefits of >>> supporting severely restricted JTAG hardware outweigh the problems of >>> adding complexity and potential for errors in the target drivers. >>> >>> At the least I would like to know if it would be possible to have the >>> stable-states-only restriction applied only to the final state before >>> jtag_execute_queue(). >>> >>> >>> Michael >>> >>> >>> On Tue, Apr 28, 2009 at 5:24 PM, Dick Hollenbeck <[email protected]> wrote: >>> >>> >>> >>>> Øyvind Harboe wrote: >>>> >>>> >>>> >>>>> I'm concerned about backwards compatibility on this one. >>>>> >>>>> I'd like to see a compile/runtime option to switch between >>>>> the old/new table. >>>>> >>>>> E.g. I suspect that ARM11 has some dependencies on >>>>> the precise paths taken today and that really it should >>>>> have a couple of more jtag_add_pathmove()'s... >>>>> >>>>> Once ARM11 is populated with enough jtag_add_pathmove()'s >>>>> for the cases where a specific path is required, we no >>>>> longer need access to the old 7 clock transitions... >>>>> >>>>> >>>>> >>>>> >>>> Yes, I share your concern. We need a graceful migration, obviously >>>> everything needs to keep working. >>>> >>>> Please see if my other posting would address your concern. >>>> >>>> The key to its understanding is that >>>> >>>> int tap_get_tms_path( tap_state_t from, tap_state_t to ) >>>> >>>> can return what each driver needs, either a 7 bit long bit vector, or a >>>> shorter bit vector. The shorter bit vector can be returned to drivers >>>> in the know about the potential of the vector being shorter and if they >>>> are prepared to also call the get_tms_path_len() function. >>>> >>>> >>>> >>>> Dick >>>> >>>> >>>> _______________________________________________ >>>> Openocd-development mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/openocd-development >>>> >>>> >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Openocd-development mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/openocd-development >> >> > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
