Hi,
I'm developing OpenOCD, and I want to clarify some things that got mixed up
during the discussion in #openjtag.
Currently, the OpenOCD supports debugging of ARM7 and ARM9 systems, meaning it
is able to halt the core, examine registers, read/write memory, set
breakpoints and so on.
It's also going to offer the same functionality for XScale cores (PXA2[57]x,
IXP42x, probably not IXP23xx, as there's no documentation I could find), and
the basics are already working, like downloading the debug handler, accessing
registers (including coprocessor regs), read/write memory. The details that
are missing are break/watchpoints, single-stepping, resuming (okay, this one
probably isn't just a detail, but not much trouble either).
It also contains flash writing support for CFI compatible NOR flashes using
the Intel commandset, with a patch for AMD/Spansion commandset lurking in my
inbox, for which I haven't had time yet. The flash writing is done by using
the CPU to do the accesses, either one read/write at a time, or by
downloading a small handler to the target and writing a whole buffer at a
time. It doesn't use the boundary scan chain, and achieves about 10k on a
ARM7TDMI using a Wiggler (dumb parallel port) interface.
The OpenOCD also contains a XSVF player which I use to program Xilinx
CoolRunner parts, and which I'm planning to extend to Xilinx FPGAs and other
CPLDs. Playing the bitfile could be possible, too, but isn't implemented
yet - using Impact to produce the .xsvf worked for me so far.
The JTAG layer has generic "bitbang" support that's currently used by a driver
for PC parallel port hardware, FTDI FT2232C support (Amontec JTAGkey, Olimex
ARM-USB-OCD, homebrew devices) and support for the Amontec JTAGAccelerator
(IEEE1284 EPP, faster than all the other interfaces, but proprietary). It
supports multiple devices in a scan chain, but not multiple scan chains,
though that could be added easily - the difficulty with multiple chains
probably arises once you "use" the JTAG layer to do board-level testing etc.
I've always wanted to add boundary-scan PCB testing features (opens, shorts,
etc.), too, but while talking about this in #openjtag, I came to the
impression that we (I?) didn't really know enough about the use of this
functionality. So the OpenOCD isn't about PCB testing, at least not now.
Best regards,
Dominic Rath
On Tuesday 04 July 2006 17:17, Wookey wrote:
> I've been talking to the openJTAG people (irc://irc.freenode.net#openJTAG )
> and thought it was useful to collect the info I found here, along with a
> little summary of balloonbaord JTAG requirements (which would no doubt
> benefit from some input from hardware types).
>
> JTAG experts go to the bottom for actual actions...
>
> Balloon needs JTAG tools and hardware for two purposes -
> 1) initial board programming
> 2) debugging and testing
>
> These have differing charactistics to some extent, although there is also
> quite a lot of commonality. The initial programming is a basic use of JTAG
> and whilst we'd like it to go as fast as possible it works fine with quite
> slow hardware interfacing to the JTAG. The process is also very simple:
> download some stuff.
>
> For testing things are more complicated in that you really want something
> that talks to the JTAG as fast as possible as you will be using it
> interactively, and the software needs to do more complicated stuff like
> display results and understand CPU debug modes etc.
>
> Currently for 1) we use jflash on balloon2 and bflash on balloon3, both
> with the xilinx-a-like dongle. Does bflash support balloon2 as well?
>
> for 2) we use XJTAG, which is very good but impractically expensive for
> many interested parties at several thousand pounds per seat.
>
> It would make sense to use existing open hardware/free software solutions
> where these are sufficient for our needs, or likely to become so with a bit
> of development, rather than inventing all this stuff again ourselves, so I
> took a look at what is available.
>
> This project provides much of what we want and is aiming at the same goals,
> but would need some work to be directly useable:
> http://openocd.berlios.de/web/
> It is developed by Dominic Rath (vmaster on #openJTAG)
> It currently supports arm7 and 9, and xscale support is 'coming along
> nicely', which translates to "i got the basics working, but all the
> details have to be filled in". Strongarm is also not currently supported.
>
> You can see the talk given at FOSDEM on the software here:
> http://openocd.berlios.de/OpenOCD_Fosdem2006_talk.odp
>
> Or if you prefer to watch the video:
> http://free-electrons.com/community/videos/conferences
> (Openocd, the Open On-Chip Debugger, by Dominic Rath)
>
> For hardware it supports wigglers (which I think correspond to our dongles
> - if not adding support would be trivial - someone needs to test this), and
> FT2232-based usb devices, which seems to be the way everyone is implmenting
> fast devices. You can layout your own from this:
> http://www.ftdichip.com/Projects/MPSSE/FT2232C-Proj03_v11.pdf
> or here: http://www.olimex.com/dev/arm-usb-ocd.html (euro60, available any
> minute now)
> This device is also supported and can impersonate various devices because
> it's implemented as a CPLD http://www.amontec.com/ Chameleon pod (euro129)
>
> The main thing missing at the moment, that we need, is multi-chain support.
> OpenOCD supports multi-cores but only one JTAG chain right now.
> We are not the only people that would like this feature. Domonic thinks
> "that could be added quite easily", but not for at least a couple of weeks
> as he currently has finals. Sending him a balloon to experiment on would
> probably help.
>
> It seems to me that we would be better off adding multi-chain, our dongle,
> and strongarm support to this framework, and using the available, supported
> faster JTAG hardware than by developing something from scratch ourselves.
>
> But I am no JTAG expert and it would be good if Dave and Steve had a look.
> vmaster asked that I get 'our JTAG people' (that's Dave, Steve, praf and
> nick so far I think) to join #openjtag for a chat about what is needed.
>
> Wookey
(text/plain)