The best is to standardize at a lower level ... and to forget the idea to have
the possibility to bitbang from the TCL of the openocd.
>/
/>/That's as for the SWD, we have to standardize some function call in the
ft2232, and avoiding bitbang access from higher-level.
/>/
/>/That's not simple to dev, but safe for end-user.
/>/
/>/
/It is necessary to expose the feature though TCL. Otherwise it is not
possible to use it as the telnet TCL interface is the primary (only?) way for
you to control OpenOCD. Furthermore, this is the interface to use if you want
to use OpenOCD from another program.
Hi,
Please do not confuse. I am not talking about to remove the TCL itself,
but I talking to avoid the possibility to bitbang the ft2232 port from
TCL in a non safe way ! It is really not the same.
Please read all my comments.
The bitbang of the ft2232 via TCL MUST pass via a filter in the ft2232.c
associated to the layout. The filter must mask the ft2232 inputs related
to the layout. The filter must apply the mask when the bitbang try to
write these ft2232 input.
If this mechanism is integrated in ft2232.c by Tomek, then yes, and only
in this case we can bitbang the ft2232 via TCL user interface.
If Tomek want to provide the bitbang from TCL, he must first provide the
filter mechanism . Actually the filter bitbang filter mechanism is not
implemented in ft2232.c .
That's all.
Again, what happen if the RTCK input is driven low or high from TCL
bitbang, by the end-user. You have lot of chance to break he ft2232 or
the buffer (between the ft2232 and the target) or the target, since you
have chance to generate a short-circuit of the RTCK wire ;-( . That's
the same for all the ft2232 Input . That's why I have write a big
DANGEROUS !
I do not understand the opposition to making OpenOCD more flexible by reducing the need
to modify the source and re-building to achieve some functionality. You can already do
plenty of "unsafe" things with OpenOCD like erasing the entire flash of your
target.
I am not opposed to make the OpenOCD more flexible. But I do not want to
see OpenOCD as dangerous for the hardware signal/wire for the target
and/or the adapter. Yes, we can do "unsafe" things with OpenOCD. But the
actual unsafe thing are not related to the JTAG / SWD hardware / signal
/ wire, but related to the how we use upper debug protocol and that's
really not the same.
Phil
Regards,
Laurent
http://www.amontec.com/jtagkey.shtml
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
