Before GSOC started and a few times until now I have tried to load and debug code on the Raspberry, without much success regarding RTEMS code. Alan Cudmore has suggested last year (http://alanstechnotes.blogspot.pt/2014/05/a-low-cost-jtag-debugger-for-raspberry.html) to use a FTDI FT2232H MiniMod along with OpenOCD, however although we get a JTAG connection, any code that is sent to the Pi fails to be transferred. I have checked the wiring, the JTAG setup program (the GPIO pins used for the JTAG connection have to be configured first) and OpenOCD configurations.
A great reference for this is the Dwelch67 repository (https://github.com/dwelch67/raspberrypi/tree/master/armjtag), which contains a JTAG setup program for the GPIO (armjtag.bin), OpenOcd configuration files for the FT4232H Mini Module and a test program (fastblink.elf). Alan adapted the configurations for the FT2232H (https://github.com/alanc98/rpi-minimod) which I also rechecked, and added the JTAG setup code in the RTEMS raspberry pi BSP code base.
At this point it is possible to create a JTAG connection, and have been able to control the Pi’s ACT_LED with memory word write (mww) instructions. I also managed to load Dwelch67’s test program fastblink.elf, which blinks the ACT_LED, and debug it using JTAG. To do this I recompiled the fastblink.elf program to include debug symbols (by changing the Makefile on Dwelch67’s repository) and sent it to the Pi (which is running the JTAG setup program) through GDB. I was able to set breakpoints and step through the code (although OpenOcd warns that some words were not transferred, and upon the first continue command GDB gives a “Memory write failure”), but whenever I tried to send a RTEMS binary (elf file) the transfer would fail. This may be related to some binary section memory address.
Also this JTAG configuration does not have a reset line, so the minimodule.cfg line for nSRST (ftdi_layout_signal nSRST -data 0x0020) can be left out to avoid an error message.