On 2010-12-04 16:06, Antonio Borneo wrote:
On Sat, Dec 4, 2010 at 10:47 PM, Freddie Chopin<freddie_cho...@op.pl> wrote:
This is directly related to the findings from this post:
https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html
I've only removed srst_pulls_trst and comments that mentioned that (and
comments that were not very helpful)
Fred,
I think the right place to define "reset_config" should be in files in
"board" directory, not in "target".
The same target device could be present on many boards, with different
circuit of JTAG connector.
- We could have no connection for TRST signal (it is optional and in
this case the TAP reset is obtained pulling down two signals together,
don't remember which).
- We could have no SRST (very common case, unfortunately)
- We could have boards where SRST and TRST are connected together (I
never found one, but...)
We'll - as I said on multiple occasions - I don't like that policy (;
But - you're welcome to remove reset_config's from target files and
there are 46 such files. I wanted this patch to change nothing more than
srst_pulls_trst, that's why it does nothing more.
And here goes my old "capabilities" idea. Interface files could specify
what signal it has (srst, trst, none, both, separate, combined, ...).
Target file could specify what reset signal does that chip have (same
options as above, or something similar). In case of no "forcing" command
("you must use only SRST!") OpenOCD could choose to select the best
options possible in particular case:
- when both JTAG and target have both signals spearate, then use them
separately
- when JTAG has 1 combined signal and the target has only SRST, use only
SRST,
- ...
I think you get my idea. This would make OpenOCD more intelligent. The
same capabilities model can be used with many different things - JTAG
speed (adapters have some max speed, they support rtck or not, targets
also have some max speed and they may support rtck or not), soft-reset
options (in Cortex-M3 - it was discussed recently), ...
4\/3!!
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
