Setting Up OpenOCD Under Linux

HowTos > Setting Up OpenOCD Under Linux

Getting OpenOCD

Currently OpenOCD support for sheevaplug only exists in the OpenOCD git repository. For openrd support does not exist yet (but don't despair, we explain later on how to proceed).
If your distribution does not provide a recent enough version (e.g. the Debian/Ubuntu openocd package supports the Sheevaplug since version 0.0+r1583-1, but to flash u-boot you need a version >= r1770 which implements 4 bits ECC), install the git (if needed) and checkout the code:

 git clone git://

You might also need this version if you have only one ttyUSB device.

Building OpenOCD

You also need to download and install the drivers from FTDI Ltd or libFTDI (recommended). Follow the instructions included in the version supplied for your architecture. Make sure the libs end up in /usr/lib, not in /usr/local/lib (as otherwise openocd configure will not find them)

Specifically, if you use ftd2xx (not recommended) you need to have the following installed:


And the following soft links:

 /usr/lib/ -> /usr/lib/
 /usr/lib/ -> /usr/lib/

After checking out the SVN tree, bootstrap autoconf:

 $ ./bootstrap

Configure with the FTDI driver. If you're using libFTDI then run:

 $ ./configure --enable-maintainer-mode --enable-ft2232_libftdi

If you're using ftd2xx, use this configure line:

 $ ./configure --enable-maintainer-mode--enable-ft2232_ftd2xx

Note that when using libftdi, you will be able to use the serial port AND the ICE interface together; while ftd2xx reclaims all FTDI chip resources, so only power cycle of the plug will revert the USB serial functionality.

Make and install:

 $ make
 $ sudo make install

Running OpenOCD on Sheevaplug

To start OpenOCD:

 $ sudo openocd -f /usr/local/lib/openocd/board/sheevaplug.cfg

Note that the /usr/local/lib/openocd/board/sheevaplug.cfg might be missing a configuration directive. If openocd complains add the following line to the sheevaplug.cfg file:

 ft2232_device_desc "USB <-> Serial Cable A"

Also, on new Sheevaplugs they've changed the USB device ids (use lsusb to check).
So, if you get an error, you can try changing ../openocd/interface/sheevaplug.cfg like:

 #ft2232_vid_pid 0x9e88 0x9e8f                        <-- old USB ids
 #ft2232_device_desc "SheevaPlug JTAGKey FT2232D B"   <-- old device desc
 #jtag_khz 2000                                       <-- old JTAG rate

 ft2232_vid_pid 0x0403 0x6010
 ft2232_device_desc "Dual RS232"
 jtag_khz 3000

You should see something similar to the following:

 Open On-Chip Debugger 1.0 (2009-04-02-23:53) svn:1447

 BUGS? Read

 $URL: svn:// $
 3000 kHz
 dcc downloads are enabled
 Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2)
 Info : JTAG Tap/device matched
 Error: unknown EmbeddedICE version (comms ctrl: 0x00000018)
 Warn : no telnet port specified, using default port 4444
 Warn : no gdb port specified, using default port 3333
 Warn : no tcl port specified, using default port 6666

Running OpenOCD on OpenRD

At the moment there is no openrd description in openocd. I've copied the files from the Marvell CD and made them available here: File:Openrd openocd.tar.gz (slightly modified to fix paths)

If you do not have openrd files in /usr/local/lib/openocd download this file and untar it in the /usr/local/lib/openocd directory

To start OpenOCD:

 $ sudo openocd -f /usr/local/lib/openocd/board/openrd.cfg

If you get a message that you cannot connect to the target check /usr/local/lib/openocd/interface/openrd.cfg

This file should look like:

interface ft2232
ft2232_layout sheevaplug
ft2232_vid_pid 0x0403 0x9e90
ft2232_device_desc "OpenRD JTAGKey FT2232D B"
jtag_khz 3000

You might want to check if ft2232_vid_pid matches the value that you get in dmesg and that ft2232_device_desc matches the name of the device as seen in dmesg (the string after Product: ).

If you get error messages like

Can't find target/target/feroceon.cfg

you probably used a board/openrd.cfg file with incorrect paths. Use the one from File:Openrd openocd.tar.gz or edit the file to correct the path.

If openocd starts properly you should see something similar to the following:

Open On-Chip Debugger 0.3.0-dev-00356-g1c2e48b (2009-10-13-11:40)
For bug reports, read
3000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
Info : clock speed 3000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2)

Note: if you get an error you might need to abort and reissue the openocd command. (This might also depend on whether the board was running when you invoked openocd)

Example 1: Running Das U-Boot from DRAM

Connect to OpenOCD with netcat:

 $ nc localhost 4444

Note: if nc is not found you can try:

 $ netcat localhost 4444.

Issue the following commands to reset the processor, load a U-Boot ELF file, and to set it running:

 > sheevaplug_init
 > load_image SheevaPlug_U-Boot/Compiled_Images/u-boot-rd88f6281Sheevaplug
 > resume 0x00600000

For openrd the command is of course openrd_init. Image names and paths are of course to your own discretion.

Example 2: Reflashing a Bricked U-Boot (Method 1)

This will reflash the plug with a new U-Boot called uboot.bin (this is the .bin file and not ELF and the name must be uboot.bin).

 > cd <directory that has uboot.bin>
 > openocd -f /usr/local/lib/openocd/board/sheevaplug.cfg -c init -c sheevaplug_reflash_uboot -c exit

Wait 1.5 minutes.

Example 3: Reflashing a Bricked U-Boot (Method 2)

Bring up Das U-Boot from DRAM as described in Example 1 above then tftp download the U-Boot binary file (not ELF, but the .bin file) you want to reflash -

 > setenv ipaddr <required IP address for the plug>
 > setenv serverip <tftp server IP address>
 > bubt <the .bin file you want to reflash>

The 'bubt' command will tftp download a U-Boot .bin file and reflash is on NAND memory.
If you are satisfied with your original U-Boot environment variable, then you can keep those once asked in the process, although once you reflash a bricked system it's a good idea to override your U-Boot env variable and reprogram them again in the next boot.