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 <d...@softplc.com> 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 >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >>> >>> >>> >> >> > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
