On Sat, May 30, 2009 at 2:01 PM, David Brownell <[email protected]> wrote: > 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. How about using separate target/board config files to handle different connectors on a board? 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. If we push *everything* into reset_config, then we end up with a reset_config command from hell.... >> 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? I don't know what a trst_disable would do, so I was just guessing/postulating some behaviour. >> 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. Generally I'd to support telnet tinkering with options rather than requiring a reboot. JTAG/hardware debugger + telnet *IS* tinkering :-) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
