Hi all,
I am looking to add to MIPS core support for Fast Data Channel (FDC) which
requires 38-bit support on the jtag interface. The FDC is like ARM DCC which
provides for higher bandwidth data transfers between a debug host/probe and a
target. The information below is from the current EJTAG Spec 6.11.
Kent
Fast Debug Channel
EJTAG version 5.0 adds an optional Fast Debug Channel (FDC) mechanism for
higher bandwidth data transfers between a debug host/probe and a target. The
existing FASTDATA mechanism was designed to make data transfers
more efficient in terms of TAP bandwidth utilization. However, the FASTDATA
mechanism causes the target CPU to block on every fastdata memory access,
preventing it from executing non-debug instructions and making the data
transfer intrusive to the program under debug. The FDC mechanism allows the
user to set up a data transfer, and then resume normal operation. The data
transfer occurs in the background, and the target CPU can either choose to
check the status of the transfer periodically, or it can choose to be
interrupted at the end of the transfer. The FDC mechanism adds several
architectural components to EJTAG state. The rest of this chapter describes
these components and the usage of FDC in more detail.
8.1 Overview
The FDC mechanism adds two First In First Out (FIFO) structures that are mapped
to the target CPU's physical address map. The probe uses the new FDC TAP
instruction to access these FIFOs, while the CPU accesses them using
memory accesses. To transfer data out of the core, the CPU writes one or more
pieces of data to the transmit FIFO. At this time, the CPU can resume doing
other work. An external probe would examine the status of the transmit FIFO
periodically, and if there is data to be read, the probe starts to receive data
from the FIFO, one entry at a time. When all data from the FIFO has been
drained, the probe goes back to waiting for the CPU to write more data. The CPU
can either choose to be informed of the empty transmit FIFO via an interrupt,
or it can choose to periodically check the status. Receiving data works in a
similar manner, that is, the probe writes to the receive FIFO. At that time,
the CPU is either interrupted, or learns of the event by polling a status bit.
The CPU can then do load accesses to the receive FIFO and receive data being
sent to it by the probe. The primary advantage of FDC is that it does not
require the CPU to be blocked when the probe is reading or writing the data
transfer FIFOs. This significantly reduces the CPU overhead, and makes the data
transfer far less intrusive to
the code executing on the CPU.
8.2 FDC Features
The FDC memory-mapped registers are located in the common device memory map
(CDMM) region. FDC has a device ID of 0xFD.
8.2.2 FDC TAP Instruction
The FDC TAP instruction performs a 38-bit bidirectional transfer of data as
shown in Figure 8.1. On scan out, the probe receives a Data Out valid bit, a
Receive Buffer Full status bit, a 4-bit channel identifier and 32 bits of data.
On
scan in, the probe sends status as to whether the data out in the current
scan-out will be accepted by the probe, a valid bit for data from the probe, 4
channel bits, and 32 bits of data. The probe can cause an interrupt to be sent
to the processor core by sending in a special value with 0xD in the channel
bits and a zero value in the Data In Valid bit. This mechanism can be used by
the probe to interrupt the core in cases where a probe to core transfer
completes without filling the receive FIFO. If receive interrupts are not
enabled, this special value has no effect on the core. Figure 8.1 shows a block
diagram of the FDC mechanism.
Figure 8.1 FDC Block Diagram and TDI to TDO Path
[cid:image003.png@01D075D3.A3463160]
From: Paul Fertser [mailto:d...@users.sf.net]
Sent: Saturday, April 11, 2015 11:36 AM
To: openocd-devel@lists.sourceforge.net
Subject: [OpenOCD-devel] [openocd:tickets] Re: #92 irlen 38 bits support
On Sat, Apr 11, 2015 at 04:54:45PM +0000, Andrey Gursky wrote:
User : 72 6 command.c:666 command_run_line(): Runtime Error:
embedded:startup.tcl:160: session transport is "jtag" but your config requires
JTAG
Sorry about that, it was already reported but the fix hasn't been
merged yet:
http://openocd.zylin.com/#/c/2693/<http://openocd.zylin.com/#/c/2693> .
________________________________
[tickets:#92]<http://sourceforge.net/p/openocd/tickets/92> irlen 38 bits support
Status: new
Milestone: 0.9.0
Created: Mon Apr 06, 2015 03:53 PM UTC by Andrey Gursky
Last Updated: Sat Apr 11, 2015 05:00 PM UTC
Owner: nobody
Dear openocd developers,
to add support of TMS320VC5502, mentioned in tcl/target/omap5912.cfg, following
code in src/jtag/core.c should be fixed:
#define JTAG_IRLEN_MAX 60
...
void jtag_tap_init(struct jtag_tap *tap)
{
unsigned ir_len_bits;
unsigned ir_len_bytes;
/* if we're autoprobing, cope with potentially huge ir_length */
ir_len_bits = tap->ir_length ? : JTAG_IRLEN_MAX;
ir_len_bytes = DIV_ROUND_UP(ir_len_bits, 8);
tap->expected = calloc(1, ir_len_bytes);
tap->expected_mask = calloc(1, ir_len_bytes);
tap->cur_instr = malloc(ir_len_bytes);
/** @todo cope better with ir_length bigger than 32 bits */
if (ir_len_bits > 32)
ir_len_bits = 32;
...
Is it a major design issue of openocd or it could be fixed in an easier way?
Thanks,
Andrey
________________________________
Sent from sourceforge.net because
openocd-devel@lists.sourceforge.net<mailto:openocd-devel@lists.sourceforge.net>
is subscribed to
http://sourceforge.net/p/openocd/tickets/<http://sourceforge.net/p/openocd/tickets>
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
