Sounds like an awfully complicated solution to what's going
on all the time in terms of a cleanup problem.
Right, this is not the IDEAL solution.
But openocd mechanism concerning jtag adapter init and jtag adapter
init/quit is not IDEAL too !
The better case for jtag adapter would be to have
.open
.init
.xxx-interface-me-xxx
.deinit
.close
.open and .close the handle of the jtag adapter
.init and deinit the jtag adapter itself.
But the actual openocd only knows the .init and .quit, and we have to do
with. If we go with .open .init .deinit .close, it will make a lot of
more work on all the specific jtag driver. -> could be modified on a
second step ...
THE REAL PROBLEM :
--------------------------
During the actual .init we open the handle of the jtag adapter and we
init the jtag adapter (in the specific jtag adapter driver).
The problem is the actual .init only know FAILED if the open and/or the
init failed.
The solution of Sebastien is GREAT since it allows upper layer to know
1. if the .init failed because there are not handle to open
2. or if the handle was open and the init of the jtag adapter fail
itself ...
by just adding a new code error.
After knowing this information, we can close correctly the jtag
interface by
1. bypassing .quit (no handle to close)
2.quit (deinit and close the handle)
As Sebastien's patch works only on the code error, there are no impact
on other JTAG adapter drivers. But each developer can use this mechanism
to make the quit of their JTAG adapter more robust.
Perhaps we should stop relying so much on the jtag global
pointer?
Could you point out in source code a bit more where the problem is?
See the Sebastien's reply.
Thanks.
Laurent
http://www.amontec.com
Amotnec JTAGkey-2 : High-Speed USB JTAG cable interface
--
Øyvind Harboe
Can Zylin Consulting help on your project
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
