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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to