Rick Altherr wrote:
>
> On Jan 7, 2009, at 10:57 AM, Dick Hollenbeck wrote:
>
>>
>> How does this look?
>>
>
> I like it.
>
>>
>> It adds jtag_add_clocks() and implements those in the bitbang and 
>> ft2232.c drivers both.
>
> My only concern is making sure that all of the other interfaces are 
> updated to support the new stable clocks command.

Yes that will still be a to do item.  However, this is not as bad as it 
sounds:

1) the jtag_add_clocks()  function is only called from xsvf.c

2) it is never called from there unless either:

    a) xsvf is invoked with "virt2".   Not likely.
    b) the user has Lattice specific extensions in the SVF file.  Not 
likely. 
    c) a person uses my xsvf_tools and there is a RUNTEST in the file.  
This gets translated to XWAITSTATE and from here jtag_add_clocks() is 
called.

The virt2 option, oddly named, means that the RUNTEST timedelay is to be 
interpreted as clocks not usecs.  Most of the time this is interpreted 
as usecs and jtag_add_sleep() happens.

The most likely scenario is 2.c and if jtag_add_clocks() is called with 
clock_count==0, then this also will have no effect if you were to add a 
test for it before allocating the JTAG_STABLECLOCKS command onto the queue.




If it is called against a driver not supporting JTAG_STABLECLOCKS, then 
*something like* (in those respective drivers) line
1444 of ft2232.c will be hit:

            default:
                LOG_ERROR("BUG: unknown JTAG command type encountered");
                exit(-1);

I wonder if those who are more familiar with their respective drivers 
wouldn't mind adding this support over time.  I don't know if you have a 
TODO list anywhere in the project.  But this is not a hard function to 
add for those that have written the jtag_add_runtest() function.

I simply don't have the time, nor the expertise to add this to all the 
drivers, nor the facility to test those changes.

I would hate for this to be a reason to avoid committing the patch and 
building from here.

Dick

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to