Re: [OpenOCD-devel] Integrating non-CPU targets into OpenOCD - An example implementation & questions

[Tom V. <ho...@gm...>]

 > It basically uses irscan and drscan, which are also available through
the TCL
> interpreter. Why not just code a few TCL functions to talk to those
blocks?

The jtag_gpio is an initial proof of concept, and of course it can be used
with just TCL commands.

But as I understand it, the TCL functionality is limited in scope: it's
just a glorified text interface, and it's pull only: you need to write your
own polling loop.

A step up from jtag_gpio would be a JTAG uart where you want a telnet
interface on the host side. This is exactly what already present with the
OR1K JTAG serial port, except that you really want a JTAG UART to be
independent from any CPU, since that's a more scalable approach.

Another example would be an open source equivalent of SignalTap or
ChipScope with live updates. Here, you want a high-bandwidth interface,
preferably a plain TCP/IP socket with push functionality as well.

All that said: while I did some experiments with the tcl interface, there
are probably some major gaps in my understanding of all its features. The
documentation is a bit terse. :-)

> Nothing in OpenOCD is right now prepared to handle targets that don't have

> memory, registers and require run control. The ls1_sap target already
> stretches the boundary, but it's somewhat ok since you can at least do
memory
> reads and writes.

I wish I had known about the ls1_sap target before I started this! It's a
much better tutorial for writing your first target than the testee target.

But I see that it also simply stubs out a bunch of callbacks that are
relevant only for CPU, so I'll keep on doing that.

Thanks!
Tom


On Wed, May 16, 2018 at 2:35 AM, Matthias Welwarsky <mat...@we...>
wrote:

> On Dienstag, 8. Mai 2018 02:46:56 CEST Tom Verbeure wrote:
> > Hello OpenOCD Devs,
> >
> > I have been working some JTAG enabled blocks (GPIOs, serial port, logic
> > analyzer) that are completely stand-alone, not dependent on a particular
> > CPU. The goal is to gradually have a set of open source debug options
> > similar to the closed source ones of Altera and Xilinx (jtag_uart,
> > In-System Signals & Probes, Signal Tap, ...)
>
> > Right now, I have solved the problem by creating a new target (jtag_gpio)
> > that implements a bunch of callbacks such as init, poll, etc and a number
> > of commands as well.
> >
> > It stubs out pure CPU related callbacks to prevent OpenOCD from
> segfaulting
> > when you run particular commands (e.g. OpenOCD expects the 'resume'
> > callback to always be implemented).
> >
> > An example is here:
> > https://github.com/tomverbeure/openocd/blob/jtag_
> gpio/src/target/jtag_gpio.c
>
> > It works fine.
>
> It basically uses irscan and drscan, which are also available through the
> TCL
> interpreter. Why not just code a few TCL functions to talk to those
> blocks?
> Nothing in OpenOCD is right now prepared to handle targets that don't have
> memory, registers and require run control. The ls1_sap target already
> stretches the boundary, but it's somewhat ok since you can at least do
> memory
> reads and writes.
>
> > Here are my questions:
> >
> > 1. First and foremost, while my current way of creating non-CPU targets
> > works fine, I'm wondering if I missed something obvious in terms of how I
> > should have done this. Was it inevitable to implement code as a target,
> or
> > should I have used a different non-target primitive?
>
> No, you didn't miss anything. There is simply no infrastructure in place
> for
> what you attempt to do.
>
> > 2. Are you guys open to patches that gradually expand targets to non-CPUs
> > and fix issues 1 and 2. For example, if a target would have a flag that
> > made it explicit that something was not a CPU, the hacks of 1 and 2 would
> > not be necessary.
>
> Not on my roadmap.
>
> > 3. Similarly, would there be interest in a generic socket implementation?
>
> The TCLRPC stuff is not enough for your purposes?
>
> BR,
> Matthias
>
> >
> > Other comments?
> >
> > Thanks!
> > Tom
>
>
>