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? The ARM11 driver is certainly programmed with that assumption in mind.
I don't think the tap_get_tms_path() is a usable solution, 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
