
I have been wanting to do this for a long time and doing some googling
so have others.

Now ARM jtag on the raspberry pi, is not without risk.  First some
soldering is required, not trivial soldering, not hard but not trivial.
Then you are connecting things between two boards, if you miscount the
pin numbers on either side you might short something like power to
ground and may melt one or both boards.  Third, this jtag solution
does not provide level shifters, nor any isolation.  You need to make
sure you have both the raspberry pi and the ftdi breakout board connected
to the same computer, or same usb hub, preferrably ports on the same
card or near each other to insure they use the same ground.

This example is based on this board:

http://www.sparkfun.com/products/718

In addition to being a serial port many of the ftdi usb devices have
a bitbang mode.  This one has 8 pins that you can bit bang, ftdi has
an app note, or you can just use trial and error to figure out what bit
goes with what pin.

Now you will have to solder a wire on the raspberry pi to use the
ARM jtag anyway (see the armjtag directory) so you wont have a problem
soldering pins on this ftdi breakout board.  The breakout board has
pins labelled, I am using these pins for JTAG.

#define BIT_TXD_TDI     0
#define BIT_DTR_TMS     4
#define BIT_RTS_TCK     2
#define BIT_RXD_TDO     1

TXD, DTR, RTS, RXD are the labels on the ftdi breakout board.  TDI,
TMS, TCK, TDO are the JTAG signals provided by those pins.  Map that
to the raspberry pi pins

ARM_TDI  GPIO_GCLK P1-7   IN ( 4 ALT5)
ARM_TMS  CAM_GPIO  S5-11 OUT (27 ALT4)
ARM_TCK  GPIO_GEN6 P1-22 OUT (25 ALT4)
ARM_TDO  GPIO_GEN5 P1-18 OUT (24 ALT4)

P1 pin 7, 22, and 18 and S5 (ribbon connector) pin 11.

For generic ARM jtag you may want these as well which are supported
but I am not necessarily using them as I have other ftdi boards I am
going to try out which dont have more than 4 bitbang pins.

#define BIT_RI__TRST    7
#define BIT_DSR_SRST    5

The raspberry pi does need something tied to TRST for it to work.

ARM_TRST      22 GPIO_GEN3 P1-15  IN (22 ALT4)

TRST is asserted low so tie TRST to 3.3v on the ftdi breakout board.

So first get the openocd sources, in openocd/src/jtag/drivers/ backup
the original parport.c and replace it with the one you find here.

If you use git for the cutting edge openocd sources then the first
step is

./bootstrap

which basically creates the configure script, then

./configure --enable-parport

Now, I didnt take too much time to fix this the right way, you will
get a link error complaining about ftdi_something_something functions.
Dig in and find the Makefile (openocd/src/jtag/Makefile maybe or
openocd/src/jtag/drivers/Makefile, or openocd/src/Makefile, etc) and
change LIB from -ldl to -ldl -lftdi.

You will need the libftdi development files as well
apt-get install libftdi-dev

Keep trying to make
make
the project from the top openocd directory until you see this

openocd.texi:12: @include `version.texi': No such file or directory.
openocd.texi:37: warning: undefined flag: VERSION.
openocd.texi:38: warning: undefined flag: UPDATED.
openocd.texi:58: warning: undefined flag: VERSION.
openocd.texi:59: warning: undefined flag: UPDATED.

I have not figured what to do to make the docs build.

So the src directory will contain an openocd binary.  You might want
to do a make install, but since this is a bit of a custom one I have
not I use the path to the binary.

As discussed in the armjtag directory it is much easier if you change
to the directory where you have the programs you want to load, that
way at the openocd prompt you dont need to specify a path it uses
the local directory (to the openocd SERVER).  You need to use the
raspi.cfg from this directory when using this ftdi breakout board
(or some other ft232rl device)

cd raspberrypi/blinker01/
/path/to/openocd/src/openocd -f ../jtagproxy/ft232rl/raspi.cfg

If everything is wired up right and powered you should see this:

Info : clock speed 10000 kHz
Info : JTAG tap: raspi.arm tap/device found: 0x07b7617f (mfg: 0x0bf, part: 0x7b76, ver: 0x0)
Info : found ARM1176

In another terminal you can

telnet localhost 4444

and it should respond with something like this

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>

If you get the > prompt then you can try this command, dont confuse
this prompt with your normal command line prompt, you dont want to be
halting your host computer

> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800001d3 pc: 0x00008144

Your cpsr and pc will vary.

Oh, right, of course you need to get the armjtag.bin file from the
armjtag directory and boot the raspberry pi using that file as your
kernel.img.  The green led will blink if it is running that image.
When you halt the arm the blinking will stop either on or off depending
on when you halted the arm.  So long as you have not done anything
to mess up the memory or program counter in openocd you can use
the resume command:

> resume

and it should allow the arm to resume and continue blinking.

See the armjtag directory for more info on loading programs, etc.


UPDATE

added parport_fast.c, this version buffers up ftdi writes.  copy this
file to parport.c in the proper place in the openocd sources.  It
is not perfect but at the same time is noticeably faster.

I get warnings like this.

> load_image blinker02.elf
Data transfer failed. Expected end address 0x00008088, got 0x00008089
use 'arm11 memwrite burst disable' to disable fast burst mode
in procedure 'load_image'

But the file runs.

> resume 0x8000

If you use the parport.c file instead of parport_fast.c then it works
without warning but is slow

> load_image blinker02.elf
136 bytes written at address 0x00008000
downloaded 136 bytes in 10.351526s (0.013 KiB/s)
> resume 0x8000



