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:
You might also need this version if you have only one ttyUSB device.
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:
/usr/lib/libftd2xx.so.0.4.16 /usr/include/ftd2xx.h /usr/include/WinTypes.h
And the following soft links:
/usr/lib/libftd2xx.so -> /usr/lib/libftd2xx.so.0 /usr/lib/libftd2xx.so.0 -> /usr/lib/libftd2xx.so.0.4.16
After checking out the SVN tree, bootstrap autoconf:
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 http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ 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) $URL$ For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 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.