On Saturday 30 May 2009, Øyvind Harboe wrote: > >> So these are *targets* that don't need or want > >> TRST? > > > > In the Atmel case, yes. > > > > In the TI case, no. TI boards often come with > > both "TI-14" and "ARM-20" JTAG connectors. > > So whether you have SRST depends on which kind > > of JTAG adapter you use ... not the board, not > > the CPU. > > How about using separate target/board config files to > handle different connectors on a board?
No, that's chaos. Notice that my "PROPOSAL 2" gave a completely clean way to handle that: the *JTAG adapter* can veto the use of a particular signal. So an adapter that talks "TI-14" could say "disable_srst" ... and when it hooks up to a board that's correctly setup for "srst_and_trst", it will work just fine. Or in the AVR8 case, tha board might say "disable_trst" then it won't matter what kind of jtag link is used. This would work well with a "disable_rtck" ... when a board doesn't support it, it shouldn't be possible to try using it even if the adapter does. > It seems to me that we should try to define the simplest > possible options in reset_config on top of which we > build more complex stuff. I'm not clear what you're suggesting. Are you hinting there should be some *other* command that talks about which signals are available? I *was* trying to keep it simple. With a single "go-to" command for most aspects of reset wiring, not two or more (which don't play well with each other). On the other hand, maybe there's merit in the notion of way to declare what JTAG signals exist ... one that isn't limited to the core four (TMS/TCK/TDI/TDO) plus resets (SRST/TRST), but also accomodates various other signals (DBGREQ/DBGACK, EMU0/EMU1, EVTI/EVTO, etc). > If we push *everything* into reset_config, then we end > up with a reset_config command from hell.... Only if that command is poorly designed and factored. Admittedly, it *started* out that way. But needing two or three different commands to configure the things that "reset_config" claims to handle would seem worse. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
