OpenOCD tips and tricks?

[Chris Johns]

On 15/08/2015 2:21 am, Ric Claus wrote:
> 
> On Aug 4, 2015, at 1:26 PM, Chris Johns <chrisj at rtems.org> wrote:
> 
>> On 4/08/2015 5:58 pm, Ric Claus wrote:
>>> Thanks, Chris.  This looks like it will be very helpful and I am looking forward to exploring it today.
>>
>> Please update if there are errors.
> 
>   The mrd() implementation given in xilinx-tcl.cfg caused mask_poll() to choke because it returned a decimal string that was later interpreted as being hex (63 became 0x00000063).  There’s now a new version on the wiki that gives an implementation that is more like XMD’s behavior, although it provides more functionality than what ps7_init needs (which was initialy useful to me).  Probably the output of openocd’s mdw() command would have been sufficient.  However, in light of this, I wonder whether this solves the problem of "some parts of the initialisation that may not work” issue you mentioned.
> 
>   Other changes to the wiki page were to make it slightly less zc706-centric.  Probably one example is enough, but there are some quirks of the Zedboard that might be worth mentioning somewhere.  The Zedboard has both the 14 pin JTAG header on it as well as a micro-USB connector for the Digilent SMT2 FTDI-based interface.  I am using the latter and found that the ps7_init wouldn’t load unless I reduced adapter_khz to 100.  After it was loaded, I could raise it to 25000 kHz (but not the advertised 30000).  I had also found that I needed to configure the reset with 'reset_config srst_only srst_push_pull’ and 'adapter_nsrst_delay 40’ to get reliable communication.  The Zedboard configuration supplied with openocd did not work for me as-is. 
>

Excellent and thanks. I will update and test. Maybe these scripts should
be in the BSP source for the Zynq ?


>   Unfortunately, now I’ve run into openocd’s software breakpoints being ignored.  Hardware breakpoints, however, do work.  Curiously, gdb’s breakpoints do kind of work, and these seem to translate to software openocd breakpoints.  I say “kind of” because gdb’s step, next and continue commands after having stopped at a breakpoint don’t work.  The PC just remains fixed at the breakpoint address.  I’ve been digging through the mailing lists, looking at the gdbserver transactions and openocd’s diagnostics trying to find a clue, but so far have not come up with anything.  Do you have any ideas?

As I said in the other thread, I need to find time to dig into OpenOCD
and see if the L2 cache is the issue. Paul Fertser over at the OpenOCD
project knows there is an issue and it has been sitting with me for a
while now.

> 
>>
>>> You point out the gdb-scripts page, which unfortunately provides 2 broken links to your FTP area.  Do you know where the scripts might have moved to?  I found this: https://git.rtems.org/chrisj/rtems-tools.git/tree/tools/gdb.  Is it the same or does it replace or supplement it?
>>
>> It replaces the files. The scripts are built and installed when the
>> tools are built by the RSB.
>>
>> There is page as well ...
>>
>> https://devel.rtems.org/wiki/Developer/Tools/RTEMS_GDB_Python
>>
>> Maybe this page moves to the other spot.
>>
>> This is a work in progress so fixes are welcome.
> 
> The only issue here so far is that ‘python import rtems’ dies with not finding rbtrees.py.  I saw that the wscript in that directory was missing this and some other .py files, but fixing that and trying to get it applied didn’t succeed.  I haven’t had a chance to dig deeper yet.
> 

Can you please raise a PR for this ? It needs to be tracked to end up on
the 4.11 branch.

Chris