On Mar 1, 2009, at 12:08 AM, Dirk Behme wrote:
Additionally, short status update from me:...And, I wonder why the new version needs ~6 initial TAP_RESET moves as marked with OMAP3_HACK in patch in attachment. Else, the ID code won't be detected correctly. I assume that this isn't related to new tap_get_tms_path(). I vote for a reset issue (?)After TRST, the OMAP3 needs 10 TCK pulses before the JTAG hardware turns on. I'm assuming that the 7 TAP_RESET moves combined with 3 other pulses was just enough to get things turned on.Ah, yes, I forgot this. Thanks for making me re-read TI's spec ;) What do you think would be the best way to add this to OpenOCD? The first and easiest idea is to add something like #ifdef OMAP3_SUPPORT /* Do 10 TCK in RESET state to enable OMAP3 jtag */ omap3_init() #endifto jtag_init_inner(). But this is quite hackish. There doesn't seem to be an interface to add processor specific pre-init functionality to jtag_init_inner() ?
I'm not fond of device-specific code in C. The 'run_test' command available in TCL should let you run any number of clocks in IDLE today. We have talked about changing it to add an optional state argument, so you could do something like 'run_test 10 RESET' and have it do 10 TCK in RESET. Then you can use the reset-init event (exposed in TCL via the target event hooks) to do that when OpenOCD does a reset.
Best regards Dirk
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
