On Saturday 30 May 2009, Øyvind Harboe wrote:
> I see that I've jumped into a discussion where you are much
> more up to date on the overall reset_config, how to write
> quality documentation, etc. Below are some comments
> where I had any.
>
> Q: What's a "system configuration file"?
>
> I can think of interface config files, target config files, board
> config files, the users config file....
I had to coin a phrase. An example of a system config
file would be "openocd.cfg" ... basic template
source [find interface/...cfg]
source [find board/...cfg]
... define task and environment specific utilities ...
You may be using "user's config file" in a similar way.
I didn't notice that term being defined anywhere either!
> >> +
> >> +If you have an interface that does not support SRST and
> >> +TRST(unlikely),
> >
> > Not unlikely at all. The 14-pin JTAG connectors
> > that TI uses don't pass SRST. The 10-pin JTAG
> > connectors that Atmel uses with AVR8 (and AVR32)
> > chips don't pass TRST. (Although there's a pin
> > reserved for TRST. It's unclear if *any* JTAG
> > adapters use that, since the only chips supporting
> > that signal are the unclear-future AVR32 AP7s.)
>
> 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.
> I was referring to the interface not supporting
> TRST.
Couldn't tell ... :)
It's the same sort of issue though: one of the
signals is not passed through.
Other examples include RTCK, DBG{REQ,ACK}, EMU{0,1},
EVTO, and surely more...
> I don't understand how one could infer that srst
> is tied to trst by specifying trst_disable...
Huh? Me either. I don't think I said or even
implied any such thing; where did that come from?
> W.r.t. #3 I'm not keen because it's nice to be able
> to tinker with various combinations from telnet instead
> of having to "reboot" the system...
I had thought about that. Such tinkering would only
make sense when experimenting to find an initial working
config, or so I concluded. Ever afterwards, you would
not need to tinker.
> I'm also not entirely
> convinced that reset scripts might need to tinker with
> reset_config options during reset itself(seems far-fetch
> today though).
If they need such tinkering, that says to me that
something more complicated is going on ... so the
current "reset_config" is not a good answer. But
since there's no current need for such messiness,
that is not a a good reason not to adopt #3.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
