Rick Altherr wrote:
>
> On Feb 28, 2009, at 9:20 AM, Dirk Behme wrote:
>
>>
>> Ah, yes. Understood.
>>
>> Looking at jtag.c and irscan/drscan implementations:
>>
>> Why is irscan implemented as handle_irscan_command(), but drscan as
>> Jim_Command_drscan()? What is the difference between handle_xx_command
>> and Jim_command_xx?
>
> OpenOCD hasn't established naming conventions.
Does this mean there is no _functional_ difference, just a name one?
I.e. I can read Jim_Command_drscan() as handle_drscan_command()? And a
patch to rename Jim_Command_drscan() to handle_drscan_command() to
make it more consistent would be accepted?
Hmm, doesn't seem that simple rename would work, as the parameters are
different and Jim_Command_drscan() calls some Jim_xxx() functions.
handle_irscan_command() seems to use an other interface.
>> 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()
#endif
to 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() ?
Best regards
Dirk
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
