Re: [Openocd-development] 0.2.0 Status Update
On May 28, 2009, at 7:04 PM, Zach Welch wrote: In addition, the following issues appear to require resolution, in order to decided whether they should be accomplished for 0.2.0 or postponed: - ft2232 high-speed device support Not necessary for 0.2.0, but if a patch was ready, it would go in. The patches I've seen for this before (that sadly don't apply cleanly today) are relatively small and just add detection of the new device, support for faster clock speeds, and RTCK support. - finish work to allow parts of libopenocd to be exposed. Definitely not for 0.2.0. I'd even go so far as to make the default -- disable-shared for 0.2.0 since the entire library hasn't been vetted for any sort of use except by the openocd binary. Once we have the API pruned, the default could be --enable-shared, but for now, it just makes the build take longer, installs unnecessary files, and potentially misleads users/developers into thinking we support this type of usage. - continue reorganizing TCL files to provide more structure I'm OK with this since it doesn't really have a big effect on users. - longer usb timeouts (or non-blocking I/O?) longer timeouts are OK for 0.2.0, but I don't think they really resolve the issue. Non-blocking I/O is definitely not for 0.2.0 as it would require some major restructuring. - fix jlink to work with large scan chains (e.g. R.Doss svf test). As long as the fix is relatively small, I'd be OK with this. - fix endemic reset problems I'd love to see this resolved. It has confused me a number of times with the Luminary FTDI-based demo board as well as when playing with the beagleboard. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Update
On Thu, 2009-05-28 at 23:45 -0700, Rick Altherr wrote:
On May 28, 2009, at 7:04 PM, Zach Welch wrote:
In addition, the following issues appear to require resolution, in
order
to decided whether they should be accomplished for 0.2.0 or postponed:
- ft2232 high-speed device support
Not necessary for 0.2.0, but if a patch was ready, it would go in.
The patches I've seen for this before (that sadly don't apply cleanly
today) are relatively small and just add detection of the new device,
support for faster clock speeds, and RTCK support.
The attached patch applies cleanly and improves on the previous version,
adding a static routine to test for high-speed devices (eliminating a
small bit of redundant code that can be expected to change over time).
Please feel free to review, test, and commit it.
Cheers,
Zach
Index: configure.in
===
--- configure.in (revision 1942)
+++ configure.in (working copy)
@@ -310,6 +310,10 @@
AC_ARG_ENABLE(ft2232_ftd2xx,
AS_HELP_STRING([--enable-ft2232_ftd2xx], [Enable building support for FT2232 based devices using the FTD2XX driver from ftdichip.com]),
[build_ft2232_ftd2xx=$enableval], [build_ft2232_ftd2xx=no])
+
+AC_ARG_ENABLE(ftd2xx_highspeed,
+ AS_HELP_STRING([--enable-ftd2xx-highspeed], [Enable building support for FT2232H and FT4232H-based devices (requires =libftd2xx-0.4.16)]),
+ [want_ftd2xx_highspeed=$enableval], [want_ftd2xx_highspeed=maybe])
AC_ARG_ENABLE(amtjtagaccel,
AS_HELP_STRING([--enable-amtjtagaccel], [Enable building the Amontec JTAG-Accelerator driver]),
@@ -737,6 +741,32 @@
return 0;
}
], [ AC_MSG_RESULT([Success!])] , [ AC_MSG_ERROR([Cannot build run test program using ftd2xx.lib]) ] )
+
+AC_MSG_CHECKING([whether to build ftd2xx device support])
+AC_MSG_RESULT([$want_ftd2xx_highspeed])
+if test $want_ftd2xx_highspeed != no; then
+AC_MSG_CHECKING([for ftd2xx highspeed device support])
+AC_COMPILE_IFELSE([
+#include confdefs.h
+#if IS_WIN32
+#include windows.h
+#endif
+#include stdio.h
+#include ftd2xx.h
+DWORD x = FT_DEVICE_4232H;
+], [
+ AC_DEFINE(BUILD_FTD2XX_HIGHSPEED, [1], [Support FT2232H/FT4232HS with FTD2XX.])
+ build_ftd2xx_highspeed=yes
+], [
+ build_ftd2xx_highspeed=no
+] )
+AC_MSG_RESULT([$build_ftd2xx_highspeed])
+
+if test $want_ftd2xx_highspeed = yes -a $build_ftd2xx_highspeed = no; then
+ AC_MSG_ERROR([You need a newer FTD2XX driver (version 0.4.16 or later).])
+ fi
+fi
+
LDFLAGS=$LDFLAGS_SAVE
CFLAGS=$CFLAGS_SAVE
fi
Index: src/jtag/ft2232.c
===
--- src/jtag/ft2232.c (revision 1942)
+++ src/jtag/ft2232.c (working copy)
@@ -91,6 +91,8 @@
*/
static int ft2232_stableclocks(int num_cycles, jtag_command_t* cmd);
+/* max TCK for the high speed devices 3 kHz */
+#define FTDI_2232H_4232H_MAX_TCK 3
static char * ft2232_device_desc_A = NULL;
static char*ft2232_device_desc = NULL;
@@ -173,6 +175,7 @@
#if BUILD_FT2232_FTD2XX == 1
static FT_HANDLE ftdih = NULL;
+static FT_DEVICE ftdi_device = 0;
#elif BUILD_FT2232_LIBFTDI == 1
static struct ftdi_context ftdic;
#endif
@@ -410,13 +413,55 @@
return ERROR_OK;
}
+#ifdef BUILD_FTD2XX_HIGHSPEED
+static bool ft2232_device_is_highspeed(void)
+{
+ return (ftdi_device == FT_DEVICE_2232H) || (ftdi_device == FT_DEVICE_4232H);
+}
+static int ft2232_adaptive_clocking(int speed)
+{
+ bool use_adaptive_clocking = FALSE;
+ if (0 == speed)
+ {
+ if (ft2232_device_is_highspeed())
+ use_adaptive_clocking = TRUE;
+ else
+ {
+ LOG_ERROR(ft2232 device %lu does not support RTCK, ftdi_device);
+ return ERROR_OK;
+ }
+ }
+
+ u8 buf = use_adaptive_clocking ? 0x96 : 0x97;
+ LOG_DEBUG(%2.2x, buf);
+
+ u32 bytes_written;
+ int retval = ft2232_write(buf, 1, bytes_written);
+ if (ERROR_OK != retval || bytes_written != 1)
+ {
+ LOG_ERROR(unable to set adative clocking: %d, retval);
+ return retval;
+ }
+
+ return ERROR_OK;
+}
+#else
+static int ft2232_adaptive_clocking(int speed)
+{
+ // not implemented on low-speed devices
+ return speed ? ERROR_OK : -1234;
+}
+#endif
+
static int ft2232_speed(int speed)
{
u8 buf[3];
int retval;
u32 bytes_written;
+ ft2232_adaptive_clocking(speed);
+
buf[0] = 0x86; /* command set divisor */
buf[1] = speed 0xff; /* valueL (0=6MHz, 1=3MHz, 2=2.0MHz, ...*/
buf[2] = (speed 8) 0xff; /* valueH */
@@ -448,8 +493,15 @@
{
if (khz==0)
{
- LOG_DEBUG(RTCK not supported);
+#ifdef BUILD_FTD2XX_HIGHSPEED
+ *jtag_speed = 0;
+ return ERROR_OK;
+#else
+ LOG_DEBUG(RCLK not supported);
+ LOG_DEBUG(If you have a high-speed FTDI device, then
+ OpenOCD may be built with --enable-ftd2xx-highspeed.);
return ERROR_FAIL;
+#endif
}
/* Take a look in the FT2232 manual,
@@ -1743,6 +1795,9 @@
static int ft2232_init_ftd2xx(u16 vid, u16 pid, int more, int* try_more)
{
FT_STATUS status;
+ DWORD deviceID;
+ char
Re: [Openocd-development] 0.2.0 Status Update
On Thu, 2009-05-28 at 23:45 -0700, Rick Altherr wrote: On May 28, 2009, at 7:04 PM, Zach Welch wrote: [snip] In addition, the following issues appear to require resolution, in order [snip] - fix jlink to work with large scan chains (e.g. R.Doss svf test). As long as the fix is relatively small, I'd be OK with this. No patch is pending, but Simon Qian sent me the following information off-list when I asked him about it. In jlink_scan, jlink_tap_ensure_space(1, scan_size + 16); is called first to ensure there is enough space, but if scan_size is large than the buffer size, it will always fail. So jlink_tap_ensure_space should be called in jlink_tap_append_scan. If no one else looks at this, I will try to get around to it eventually. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Thu, May 28, 2009 at 10:05 PM, Vytautas Lukenskas vytautas.lukens...@arevita.com wrote: On Thursday 28 May 2009 12:57:38 massimiliano cialdi wrote: Maybe the opensource libftdi? Do I need to try with ftd2xx driver provided by Amontec? I don't think that is for 64bit systems, isn't it? You could try ftd2xx lib directly from ftdichip -- they have x86_64 version. Here is link: http://www.ftdichip.com/Drivers/D2XX.htm OK, but it doesn;t compile openocd Downloaded driver version 0.4.16, from FTDIchip I follow all the steps described in readme to install then I configure openocd as follows: ./configure --enable-ft2232_ftd2xx --disable-werror --enable-maintainer-mode --with-ftd2xx-linux-tardir=dirtolibftd2xx/libftd2xx0.4.16_x86_64 but make stops whit an error: libtool: link: gcc -std=gnu99 -g -O2 -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o .libs/openocd main.o /home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' collect2: ld returned 1 exit status make[3]: *** [openocd] Errore 1 make[3]: uscita dalla directory «/home/POWERSOFT/massimiliano/download/openocd/trunk-1938/src» make[2]: *** [all-recursive] Errore 1 make[2]: uscita dalla directory «/home/POWERSOFT/massimiliano/download/openocd/trunk-1938/src» make[1]: *** [all-recursive] Errore 1 make[1]: uscita dalla directory «/home/POWERSOFT/massimiliano/download/openocd/trunk-1938» make: *** [all] Errore 2 Where I am wrong? I absolutely need to speedup speed of openocd bye -- Assioma di Cole: La somma dell'intelligenza sulla Terra è costante; la popolazione è in aumento Massimiliano Cialdi cia...@gmail.com massimiliano.cia...@powersoft.it ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote: but make stops whit an error: libtool: link: gcc -std=gnu99 -g -O2 -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o .libs/openocd main.o /home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64/static _lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' bye Hi, Take a look at https://lists.berlios.de/pipermail/openocd-development/2009-May/007252.html It's a pity, it is still not fixed. -- vylu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Fri, 2009-05-29 at 11:01 +0300, Vytautas Lukenskas wrote: On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote: but make stops whit an error: libtool: link: gcc -std=gnu99 -g -O2 -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o .libs/openocd main.o /home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64/static _lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' bye Hi, Take a look at https://lists.berlios.de/pipermail/openocd-development/2009-May/007252.html It's a pity, it is still not fixed. Does the attached patch solve this problem? Cheers, Zach Index: configure.in === --- configure.in (revision 1942) +++ configure.in (working copy) @@ -6,7 +6,6 @@ AC_CANONICAL_HOST AC_SEARCH_LIBS([ioperm], [ioperm]) -AC_SEARCH_LIBS([dlopen], [dl]) AC_CHECK_HEADERS(arpa/inet.h) AC_CHECK_HEADERS(elf.h) @@ -705,6 +704,8 @@ fi fi +AC_SEARCH_LIBS([dlopen], [dl]) + if test $build_ft2232_ftd2xx = yes -o $build_presto_ftd2xx = yes; then # Before we go any further - make sure we can *BUILD* and *RUN* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Update
On Fri, 2009-05-29 at 13:02 +0800, Xiaofan Chen wrote: On Fri, May 29, 2009 at 10:04 AM, Zach Welch z...@superlucidity.net wrote: The following tasks appear to be pending for the 0.2.0 release: - fix OMAP3 problems reported by Dick Behme (or did these get resolved?) - final packaging fix-ups (RPM file layout) - reporting/testing tools - documentation: - updates and clean-ups for The Guide (openocd.texi): - document commands for str9pec, ocl, xscale, arm11, and others - remove 'variant' test from most of The Guide. - add expiration dates for all deprecated calls. - update and review The Manual (doxygen) - add Quick/Full/Hardware References? (seems possible and worth doing) - updates for configuration files: - c01.cfg and c02.cfg - others? What about the J-Link issues with various target in the thread TMS470 Scripts? TMS470: https://lists.berlios.de/pipermail/openocd-development/2009-May/007391.html USR8200 (IXP422): https://lists.berlios.de/pipermail/openocd-development/2009-May/007403.html STM32: https://lists.berlios.de/pipermail/openocd-development/2009-May/007406.html For my short time experiences with OpenOCD/J-Link, it has been much more usable now. But it seems there are still quite some issues with J-Link (different versions). Maybe this will not make it to 0.2.0 though. At this point, it remains unclear to me what the problems might be, and the v6 unit that I have to test works better than it has in the past. Several major problems have been resolved, but I am not surprised that the driver has not reached full stability and support. Unless Magnus or others have pending patches to test, this will require more information and time to debug properly, so I do not think it is reasonable to expect further work do be done on it for 0.2.0. It would be nice to find the bugs, but I think it is more than we can expect. Certainly, the J-Link driver will remain on The List for future work. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Fri, May 29, 2009 at 10:01 AM, Vytautas Lukenskas vytautas.lukens...@arevita.com wrote: On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote: but make stops whit an error: libtool: link: gcc -std=gnu99 -g -O2 -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o .libs/openocd main.o /home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64/static _lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' bye Take a look at https://lists.berlios.de/pipermail/openocd-development/2009-May/007252.html It's a pity, it is still not fixed. Ok, now I can compile and execute it, but still too slow. same speed of libftdi I test target board on another pc (very old, P4 2.8GHz and 1GB ram) running windows xp, openocd r256 provided by yagarto and amontec customization of ftdi2xx driver also provided by yagarto (I do not remenber version but surely not last). I can obtain more than 9KB/s I expect that my new PC (quad core Q8300 and 4GB ram) could flash the firmware faster. thanks -- Assioma di Cole: La somma dell'intelligenza sulla Terra è costante; la popolazione è in aumento Massimiliano Cialdi cia...@gmail.com massimiliano.cia...@powersoft.it ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Fri, 2009-05-29 at 11:23 +0200, massimiliano cialdi wrote: On Fri, May 29, 2009 at 10:01 AM, Vytautas Lukenskas vytautas.lukens...@arevita.com wrote: On Friday 29 May 2009 10:31:25 massimiliano cialdi wrote: but make stops whit an error: libtool: link: gcc -std=gnu99 -g -O2 -I/home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o .libs/openocd main.o /home/POWERSOFT/massimiliano/download/openocd/libftd2xx0.4.16_x86_64/static _lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' bye Take a look at https://lists.berlios.de/pipermail/openocd-development/2009-May/007252.html It's a pity, it is still not fixed. Ok, now I can compile and execute it, but still too slow. same speed of libftdi Did you use the patch that I just posted, or did you use another fix? If you used mine, I will commit it; otherwise, please post the solution that you use. Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Xiaofan Chen wrote: Back to the basic, how can OpenOCD to wiggle a pin (forget about the PCB Gerber View integration part)? Is this possible? I am not so familiar with JTAG. But intuitively I think this is already difficult. Without downloading a small program to the chips, how do you toggle an I/O pin? Take a look a this introduction: http://www.corelis.com/products/Boundary-Scan_Tutorial.htm The idea is this: If you have a BSDL file, which identifies the JTAG commands, the DR scan order (bit order) of all I/O pins... you don't need much more. Step 1: Scan in a zero the pin, Step 2: Scan in a one on the pin, Step 3: Repeat. There is no target code involved. Same method is used to read the pin.. But - back to the gerber view - or something like it... Perhaps a chip outline. Maybe like the Xilinix pin allocation graphic view program. If you can read all the pins. You can draw logic 1 pins in one color, and 0 in another. If you keep reading, you could draw changing in a different color. Take that to the next level - ie: Gerber view - and you can make board traces blink different colors. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Friday 29 May 2009 11:43:37 you wrote: Does the attached patch solve this problem? Hi Zach, No, the patch does not help, at least for me. I receive the same errors as before. /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o libopenocd.la -ldl /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 -lpthread gcc -std=gnu99 -g -O2 -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o .libs/openocd main.o /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' collect2: ld returned 1 exit status -- vylu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Fri, May 29, 2009 at 12:46 PM, Magnus Lundin lun...@mlu.mine.nu wrote: arm7_9 dcc_downloads enable dcc downloads are enabled arm7_9 fast_memory_access enable fast memory access is enabled flash write_image erase firmware.bin 0x10 bin auto erase enabled wrote 44616 byte from file firmware.bin in 11.045264s (3.944705 kb/s) The performance problems are because you use auto erase, the AT91SAM7 can only erase a whole flash bank or it it can erase flash by writing 0xFF to the flash memory. and that is slow. For normal flash writes it is not necessary to erase the flash first on the AT91SAM7 targets, that is done automatically by the flash controller. If you want to make sure that there is no old code in flash, use flash erase before the flash write_image. I tried without autoerase, and I obtain some errors value captured during scan didn't pass the requested check: captured: 0x01E1 check_value: 0x0009 check_mask: 0x0009 JTAG error while reading cpsr error writing to flash at address 0x0010 at offset 0x (-307) so I need to disable fast memory access. In thi way is more slowly: arm7_9 fast_memory_access disable fast memory access is disabled flash write_image ../images/DCellEVB.bin 0x10 bin wrote 49908 byte from file ../images/DCellEVB.bin in 25.822573s (1.887429 kb/s) this is awful thanks -- Assioma di Cole: La somma dell'intelligenza sulla Terra è costante; la popolazione è in aumento Massimiliano Cialdi cia...@gmail.com massimiliano.cia...@powersoft.it ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Hi Duane, On 5/28/09, Duane Ellis open...@duaneellis.com wrote: sic Imagine (1) being able to plug OpenOCD/JTAG into the board. (2) using some gerber view program - view the PCB (3) Double click on a pin, or a trace with a mouse (4) The trace starts blinking (5) And openocd makes the trace toggle 0/1 That alone would be a powerful debug tool, no debug software to write, no flash to program, no nothing. OpenOCD needs this feature! I think OpenOCD will need a script to convert the BSDL to some XML or to a simple standard file (even C source code), then openocd can map it to JTAG chain. Finally libopenocd will let other software to control each pin individually. It makes simple to CAD software (i.e. KiCAD) to do what you suggested. Also it will make easy to someone create a simple graphical python interface with all pins from a BGA chip, then you just click on a ball (a pin) to change its status. Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] jlink issues
Hi, I have been running a few tests with regards to jlink support (win32) svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and stm32 target. Connecting using r1192 is ok, just a little slow. The strange thing is if i then connect using r1943 it will work !! Replug the jlink and it will fail with r1943, run r1192 then all is ok again. I have attached logs to see if it inspires anyone, other than i am trying to delve into the issue. Cheers Spen jlink-good-r1943.log Description: Binary data jlink-r1192.log Description: Binary data jlink-fail-r1943.log Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TMS470 Scripts
On Thu, May 28, 2009 at 7:27 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, May 28, 2009 at 6:06 AM, Peter Denison open...@marshadder.org wrote: The offending lines that cause it to break were added in jlink.c by Oyvind in r1498. However, according to the docs (RM08001-02, dated June 30, 2008 at www.segger.com), they should be correct. Once you've read the TDO lines out, read the next byte out, and if it's 0, it's OK, if not, it's an error. Sadly, the docs don't go on to explain what an error code of 1 means. Mine is consistently reading out a 1 instead of a 0. r1498 jlink change seems to be quite a big change. https://lists.berlios.de/pipermail/openocd-svn/2009-April/000282.html Could you point which is the offending line? Thanks. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Listing BSDL files
Hi all, Follow below links to some BSDL files: NXP LPC: http://www.standardics.nxp.com/support/models/lpc2000/ Freescale PowerPC: http://www.freescale.com/webapp/sps/site/overview.jsp?code=DRPPCBSDLFLS Freescale i.MX1 (too old): http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX1nodeId=0162468rH311432973ZrDRfpsp=1tab=Design_Tools_Tab Did I forget other BSDL links? Show me the link ;-) Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
On 5/29/09, Alan Carvalho de Assis acas...@gmail.com wrote: Hi all, Follow below links to some BSDL files: NXP LPC: http://www.standardics.nxp.com/support/models/lpc2000/ Freescale PowerPC: http://www.freescale.com/webapp/sps/site/overview.jsp?code=DRPPCBSDLFLS Freescale i.MX1 (too old): http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX1nodeId=0162468rH311432973ZrDRfpsp=1tab=Design_Tools_Tab Did I forget other BSDL links? Show me the link ;-) Replying myself: In the Corelis web site Duane sent we can find this listing: http://www.corelis.com/support/BSDL.htm Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and stm32 target. Connecting using r1192 is ok, just a little slow. The strange thing is if i then connect using r1943 it will work !! Replug the jlink and it will fail with r1943, run r1192 then all is ok again. I have attached logs to see if it inspires anyone, other than i am trying to delve into the issue. Cheers Spen I have seen the same behavior. 1938 works fine with older j-link hardware (v3/v4). 1188 works with newer but is more than a little slow. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
On Friday 29 May 2009, Alan Carvalho de Assis wrote: Did I forget other BSDL links? Show me the link ;-) TI links theirs right off the generic page for each chip. They're like most vendors in that, so far as I can tell; so I'm not sure why you'd want a collection of links... So for example: DaVinci DM355 - http://www.ti.com/litv/zip/sprm262b DaVinci DM6446 (2.1 silicon) - http://www.ti.com/litv/zip/sprm325a (older silicon) - http://www.ti.com/litv/zip/sprm203 OMAP 3530 CBB package - http://www.ti.com/litv/zip/sprm315b (515 ball s-PGBA, POP, 0.4mm pitch) CUS package - http://www.ti.com/litv/zip/sprm314a (515 ball s-PGBA, POP, 0.5mm pitch) CBC package - http://www.ti.com/litv/zip/sprm346 (423 ball s-PGBA, 0.65mm pitch) I think those probably all come as ZIPped files. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
Hi David, On 5/29/09, David Brownell davi...@pacbell.net wrote: On Friday 29 May 2009, Alan Carvalho de Assis wrote: Did I forget other BSDL links? Show me the link ;-) TI links theirs right off the generic page for each chip. They're like most vendors in that, so far as I can tell; so I'm not sure why you'd want a collection of links... So for example: DaVinci DM355 - http://www.ti.com/litv/zip/sprm262b DaVinci DM6446 (2.1 silicon) - http://www.ti.com/litv/zip/sprm325a (older silicon) - http://www.ti.com/litv/zip/sprm203 OMAP 3530 CBB package - http://www.ti.com/litv/zip/sprm315b (515 ball s-PGBA, POP, 0.4mm pitch) CUS package - http://www.ti.com/litv/zip/sprm314a (515 ball s-PGBA, POP, 0.5mm pitch) CBC package - http://www.ti.com/litv/zip/sprm346 (423 ball s-PGBA, 0.65mm pitch) Thank you! I think those probably all come as ZIPped files. Nothing special, just to make life ease when OpenOCD get support to boundary scan :-) Anyone can search on google and find all BSDLs, but a filtered information has more value than a raw info. I wish openocd to have a wiki page where we could create this listing. Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
svn head (currently r1943) fails when connecting using a v6/v5.3 jlink and stm32 target. Connecting using r1192 is ok, just a little slow. The strange thing is if i then connect using r1943 it will work !! Replug the jlink and it will fail with r1943, run r1192 then all is ok again. I have attached logs to see if it inspires anyone, other than i am trying to delve into the issue. Cheers Spen I have seen the same behavior. 1938 works fine with older j-link hardware (v3/v4). 1188 works with newer but is more than a little slow. Tracing further in. For me the break is @ r1509 (tms pad patch) - now to find a solution. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Listing BSDL files
On Fri, May 29, 2009 at 11:19 PM, David Brownell davi...@pacbell.net wrote: On Friday 29 May 2009, Alan Carvalho de Assis wrote: Did I forget other BSDL links? Show me the link ;-) TI links theirs right off the generic page for each chip. They're like most vendors in that, so far as I can tell; so I'm not sure why you'd want a collection of links... For some vendors, it is still useful. For example, Renesas, you have to register in order to download the BSDL files. The device page does not come with BSDL file. Eg: for R32C/117 http://sg.renesas.com/fmwk.jsp?cnt=r32c116_7_8_root.jspfp=/products/mpumcu/m16c_family/r32c100_series/r32c116_7_8_group/ You can not find the BSDL file. But the following link will point to the correct URL. http://www.corelis.com/support/BSDL.htm One vendor missing is Fujitsu. I could not find the BSDL files for their MCUs. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
-Original Message-
From: Magnus Lundin [mailto:lun...@mlu.mine.nu]
Sent: 29 May 2009 16:42
To: Spencer Oliver
Cc: 'Dylan Reid'; openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] jlink issues
Spencer Oliver wrote:
svn head (currently r1943) fails when connecting using a
v6/v5.3 jlink
and
stm32 target.
Connecting using r1192 is ok, just a little slow.
The strange thing is if i then connect using r1943 it will work !!
Replug the jlink and it will fail with r1943, run r1192
then all is ok
again.
I have attached logs to see if it inspires anyone, other
than i am
trying to delve into the issue.
Cheers
Spen
I have seen the same behavior. 1938 works fine with older j-link
hardware (v3/v4). 1188 works with newer but is more than a little
slow.
Tracing further in.
For me the break is @ r1509 (tms pad patch) - now to find a
solution.
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Perhaps return packages that are exact multiple of 64 should
be broken in 2 smaller transactions, not padded.
a bit more debugging
The issue seesms to be in the function jlink_tap_execute
the change in r1509 that causes the issue is:
// number of full bytes (plus one if some would be left over)
byte_length = tap_length / 8 + !!(tap_length % 8);
instead of r1508
/* Pad last byte so that tap_length is divisible by 8 */
while (tap_length % 8 != 0)
{
/* More of the last TMS value keeps us in the same state,
* analogous to free-running JTAG interfaces. */
jlink_tap_append_step(last_tms, 0);
}
byte_length = tap_length / 8;
I have attached logs of both rev, as you can see the line of interest for
r1508 is
Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
and r1509
Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
Cheers
Spen
jlink-r1508.log
Description: Binary data
jlink-r1509.log
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
Hi
a bit more debugging
The issue seesms to be in the function jlink_tap_execute
the change in r1509 that causes the issue is:
// number of full bytes (plus one if some would be left over)
byte_length = tap_length / 8 + !!(tap_length % 8);
instead of r1508
/* Pad last byte so that tap_length is divisible by 8 */
while (tap_length % 8 != 0)
{
/* More of the last TMS value keeps us in the same state,
* analogous to free-running JTAG interfaces. */
jlink_tap_append_step(last_tms, 0);
}
byte_length = tap_length / 8;
I have attached logs of both rev, as you can see the line of interest for
r1508 is
Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
and r1509
Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
Yes, it definetly seems some JLinks dislikes 7 bit transactions, but not
always, not if they are in a good mode after running rev 1188.
We can patch all transactions to be a multiple of 8, but that has a
tendency of driving some arm7/9 targets into a strange state if the
endstate is IDLE, since this is the clock instruction into cpu. For
Cortex targets this is not a problem.
Still it would be very good to know if this is the problem for (at least
some of) the V6 adapters.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Spencer Oliver wrote:
Spencer Oliver wrote:
The strange thing is if i then connect using r1943 it will work !!
Replug the jlink and it will fail with r1943, run r1192
then all is ok again.
Tracing further in.
For me the break is @ r1509 (tms pad patch) - now to find a
solution.
a bit more debugging
The issue seesms to be in the function jlink_tap_execute
the change in r1509 that causes the issue is:
// number of full bytes (plus one if some would be left over)
byte_length = tap_length / 8 + !!(tap_length % 8);
instead of r1508
/* Pad last byte so that tap_length is divisible by 8 */
while (tap_length % 8 != 0)
{
/* More of the last TMS value keeps us in the same state,
* analogous to free-running JTAG interfaces. */
jlink_tap_append_step(last_tms, 0);
}
byte_length = tap_length / 8;
I have attached logs of both rev, as you can see the line of interest for
r1508 is
Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
and r1509
Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
Well found, although it doesn't explain why it should work with =r1509
after having previously worked with =r1508.
Apologies for my misdirection about r1498. I saw large changes to the
testing code under svn blame, but they were merely refactoring, and
weren't substantive.
It also concerns me that padding with the last TMS is considered to be
universally OK. When you move to DR_SHIFT, there are side-effects
(starting to clock the value out!) if you introduce extra clocks.
Particularly with the XScale, it needs to be taken to DR_SHIFT via
pathmove(), and if anything introduces extra clocks after that, the data
will start to be clocked out.
I will try this change in isolation, and report back.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 libftdi and ftd2xx performance
Hello list The accepted wisdom seems to be that libftdi is slower than ftd2xx, and when performance is low change to ftd2xx. Is this true or a myth ? Two years ago, or three, this was true, today I am not so sure. I have made some small tests , single stepping arm7, uploading medium sized files to arm925ejs and what I can see is that the libftdi is actualyy a touch faster. ( Linux 2.6 Fedora ) Do we have any other hard facts about this question ? Best regárds Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Magnus Lundin wrote: I have attached logs of both rev, as you can see the line of interest for r1508 is Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00 and r1509 Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00 Yes, it definetly seems some JLinks dislikes 7 bit transactions, but not always, not if they are in a good mode after running rev 1188. We can patch all transactions to be a multiple of 8, but that has a tendency of driving some arm7/9 targets into a strange state if the endstate is IDLE, since this is the clock instruction into cpu. For Cortex targets this is not a problem. Still it would be very good to know if this is the problem for (at least some of) the V6 adapters. Unfortunately not mine... I still get a 1 returned (instead of a zero) as the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = 6, result = 6 Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): jlink_usb_read_result, result = 1 Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) This is both from a power-up, and from warm (though not testing with an earlier working version). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 libftdi and ftd2xx performance
On May 29, 2009, at 19:40, Magnus Lundin wrote: The accepted wisdom seems to be that libftdi is slower than ftd2xx, and when performance is low change to ftd2xx. Is this true or a myth ? I don't think OpenOCD's USB usage is such that the used driver has any noticeable effect. In another project where the FT2232 was used as a synchronous serial port I had no troubles reaching sustained transfer speeds of over 120 kilobytes/second using libftdi (the remote device's serial port was the limiting factor). This was on a 1.4 GHz PPC Mac. Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
Still it would be very good to know if this is the problem for (at least some of) the V6 adapters. Unfortunately not mine... I still get a 1 returned (instead of a zero) as the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = 6, result = 6 Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): jlink_usb_read_result, result = 1 Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) This is both from a power-up, and from warm (though not testing with an earlier working version). what jlink firmware version is this? mine reports: J-Link ARM V6 compiled Nov 5 2008 20:49:58 Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Fri, 29 May 2009, Spencer Oliver wrote: Still it would be very good to know if this is the problem for (at least some of) the V6 adapters. Unfortunately not mine... I still get a 1 returned (instead of a zero) as the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = 6, result = 6 Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): jlink_usb_read_result, result = 1 Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) This is both from a power-up, and from warm (though not testing with an earlier working version). what jlink firmware version is this? mine reports: J-Link ARM V6 compiled Nov 5 2008 20:49:58 J-Link ARM V6 compiled Mar 3 2008 18:04:42 I don't think much of their revision control, to be honest. The capabilities of a lot of the versions we see in traces are wildly different, and the only distinction is a date. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] reset config updates
Make it so the magic reset_config keywords can be provided in any
order. This eliminates needless error paths, and makes it easier
to define things at the right level (adapter, board, target).
It also includes two other behavioral changes:
(1) When handle_reset_config sees a parameter error, it
exits without changing anything. This is best viewed
as a bugfix. (Old behavior: restore defaults, even if
they weren't previously active.)
(2) Only the behaviors that were explicitly specified get
changed. (Old behavior: everything else gets reset to
the default.) So for example you can now specify SRST
drive requirements without saying anything about the
three unrelated topics you previously had to specify.
That second one might cause confusion for any configs that end
up calling reset_config twice, so it will deserve to be called
out in the release notes. (There were no such configurations in
the current OpenOCD source tree.)
Update docs accordingly. Note that at least some versions of
the texi-to-html tools can't handle @xref{with spaces}, but
those work properly in PDF and in the info files.
---
This is the updated version of the patch I sent before.
Sanity tested.
doc/openocd.texi | 75 +---
src/jtag/jtag.c | 140 -
2 files changed, 144 insertions(+), 71 deletions(-)
Make it so the magic reset_config keywords can be provided in any
order. This eliminates needless error paths, and makes it easier
to define things at the right level (adapter, board, target).
It also includes two other behavioral changes:
(1) When handle_reset_config sees a parameter error, it
exits without changing anything. This is best viewed
as a bugfix. (Old behavior: restore defaults, even if
they weren't previously active.)
(2) Only the behaviors that were explicitly specified get
changed. (Old behavior: everything else gets reset to
the default.) So for example you can now specify SRST
drive requirements without saying anything about the
three unrelated topics you previously had to specify.
That second one might cause confusion for any configs that end
up calling reset_config twice, so it will deserve to be called
out in the release notes. (There were no such configurations in
the current OpenOCD source tree.)
Update docs accordingly. Note that at least some versions of
the texi-to-html tools can't handle @xref{with spaces}, but
those work properly in PDF and in the info files.
---
doc/openocd.texi | 75 +---
src/jtag/jtag.c | 140 -
2 files changed, 144 insertions(+), 71 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1574,9 +1574,13 @@ jtag_rclk 3000
Every system configuration may require a different reset
configuration. This can also be quite confusing.
+Resets also interact with @var{reset-init} event handlers,
+which do things like setting up clocks and DRAM, and
+JTAG clock rates. (@xref{JTAG Speed}.)
Please see the various board files for examples.
-...@b{note} to maintainers and integrators:
+...@quotation Note
+To maintainers and integrators:
Reset configuration touches several things at once.
Normally the board configuration file
should define it and assume that the JTAG adapter supports
@@ -1587,6 +1591,7 @@ which will be true for most (or all) boa
And when the JTAG adapter doesn't support everything, the
system configuration file will need to override parts of
the reset configuration provided by other files.
+...@end quotation
@section Types of Reset
@@ -1671,11 +1676,18 @@ Use the @command{reset_config} @var{trst
There can also be other issues.
Some devices don't fully conform to the JTAG specifications.
-Others have chip-specific extensions like extra steps needed
-during TAP reset, or a requirement to use the normally-optional TRST
-signal.
Trivial system-specific differences are common, such as
SRST and TRST using slightly different names.
+There are also vendors who distribute key JTAG documentation for
+their chips only to developers who have signed a Non-Disclosure
+Agreement (NDA).
+
+Sometimes there are chip-specific extensions like a requirement to use
+the normally-optional TRST signal (precluding use of JTAG adapters which
+don't pass TRST through), or needing extra steps to complete a TAP reset.
+
+In short, SRST and especially TRST handling may be very finicky,
+needing to cope with both architecture and board specific constraints.
@section Commands for Handling Resets
@@ -1691,31 +1703,58 @@ How long (in milliseconds) OpenOCD shoul
nTRST (active-low JTAG TAP reset) before starting new JTAG operations.
@end deffn
-...@deffn {Command} reset_config signals [combination [trst_type [srst_type]]]
+...@deffn {Command} reset_config mode_flag ...
This command tells OpenOCD the reset configuration
of
Re: [Openocd-development] Listing BSDL files
On Fri, 2009-05-29 at 12:30 -0300, Alan Carvalho de Assis wrote: Hi David, On 5/29/09, David Brownell davi...@pacbell.net wrote: On Friday 29 May 2009, Alan Carvalho de Assis wrote: Did I forget other BSDL links? Show me the link ;-) TI links theirs right off the generic page for each chip. They're like most vendors in that, so far as I can tell; so I'm not sure why you'd want a collection of links... So for example: DaVinci DM355 - http://www.ti.com/litv/zip/sprm262b DaVinci DM6446 (2.1 silicon) - http://www.ti.com/litv/zip/sprm325a (older silicon) - http://www.ti.com/litv/zip/sprm203 OMAP 3530 CBB package - http://www.ti.com/litv/zip/sprm315b (515 ball s-PGBA, POP, 0.4mm pitch) CUS package - http://www.ti.com/litv/zip/sprm314a (515 ball s-PGBA, POP, 0.5mm pitch) CBC package - http://www.ti.com/litv/zip/sprm346 (423 ball s-PGBA, 0.65mm pitch) Thank you! I think those probably all come as ZIPped files. Nothing special, just to make life ease when OpenOCD get support to boundary scan :-) Anyone can search on google and find all BSDLs, but a filtered information has more value than a raw info. I wish openocd to have a wiki page where we could create this listing. We have doc/manual, and it would be easy to create a new file and submit a patch to add doc/manual/bsdl.txt. Better would be to lay out a few different plans for attacking the problem directly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
On Sat, May 30, 2009 at 2:32 AM, Peter Denison open...@marshadder.org wrote: what jlink firmware version is this? mine reports: J-Link ARM V6 compiled Nov 5 2008 20:49:58 J-Link ARM V6 compiled Mar 3 2008 18:04:42 I don't think much of their revision control, to be honest. The capabilities of a lot of the versions we see in traces are wildly different, and the only distinction is a date. But they have the solution. I think the J-Link Windows DLL or maybe the Linux utility can download the latest firmware. So the date and version does not matter for the same V6 if you can update the firmware to the latest. For example, my J-Link V6 used to be of old firmware, now it says. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-29-19:50) svn:1943 Info : J-Link ARM V6 compiled Apr 1 2009 11:56:10 Two week agos, it says this. mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809 Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi - ARM trace docs (ETM, ETB)
Provide basic documentation on the ARM ETM and ETB trace commands.
Fix minor goofs in registration of the ETM commands; and whitespace
issues in the proof-of-concept oocd_trace code. (Plus include a
ref to Dominic's email saying that it's just proof-of-concept code.)
Note that I'm still not sure whether the ETM support works. But
documenting how it's expected to work should help sort out which
behaviors are bugs, which will help get bugs patched.
---
doc/openocd.texi| 191 +++---
src/target/etm.c|8 +
src/target/oocd_trace.c | 109 +-
3 files changed, 242 insertions(+), 66 deletions(-)
Provide basic documentation on the ARM ETM and ETB trace commands.
Fix minor goofs in registration of the ETM commands; and whitespace
issues in the proof-of-concept oocd_trace code. (Plus include a
ref to Dominic's email saying that it's just proof-of-concept code.)
Note that I'm still not sure whether the ETM support works. But
documenting how it's expected to work should help sort out which
behaviors are bugs, which will help get bugs patched.
---
doc/openocd.texi| 191 +++---
src/target/etm.c|8 +
src/target/oocd_trace.c | 109 +-
3 files changed, 242 insertions(+), 66 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1094,17 +1094,11 @@ Some ARM cores are equipped with trace s
examination of the instruction and data bus activity. Trace
activity is controlled through an ``Embedded Trace Module'' (ETM)
on one of the core's scan chains. The ETM emits voluminous data
-through a ``trace port''. The trace port is accessed in one
-of two ways. When its signals are pinned out from the chip,
-boards may provide a special high speed debugging connector;
-software support for this is not configured by default, use
-the ``--enable-oocd_trace'' option. Alternatively, trace data
-may be stored an on-chip SRAM which is packaged as an ``Embedded
-Trace Buffer'' (ETB). An ETB has its own TAP, usually right after
-its associated ARM core. OpenOCD supports the ETM, and your
-target configuration should set it up with the relevant trace
-port: ``etb'' for chips which use that, else the board-specific
-option will be either ``oocd_trace'' or ``dummy''.
+through a ``trace port''. (@xref{ARM Tracing}.)
+If you are using an external trace port,
+configure it in your board config file.
+If you are using an on-chip ``Embedded Trace Buffer'' (ETB),
+configure it in your target config file.
@example
etm config $_TARGETNAME 16 normal full etb
@@ -3586,6 +3580,181 @@ OpenOCD packages most such operations in
Some of those operations don't fit well in that framework, so they are
exposed here using architecture or implementation specific commands.
+...@anchor{arm Tracing}
+...@subsection ARM Tracing
+...@cindex ETM
+...@cindex ETB
+
+CPUs based on ARM cores may include standard tracing interfaces,
+based on an ``Embedded Trace Module'' (ETM) which sends voluminous
+address and data bus trace records to a ``Trace Port''.
+
+...@itemize
+...@item
+Development-oriented boards will sometimes provide a high speed
+trace connector for collecting that data, when the particular CPU
+supports such an interface.
+(The standard connector is a 38-pin Mictor, with both JTAG
+and trace port support.)
+Those trace connectors are supported by higher end JTAG adapters
+and some logic analyzer modules; frequently those modules can
+buffer several megabytes of trace data.
+Configuring an ETM coupled to such an external trace port belongs
+in the board-specific configuration file.
+...@item
+If the CPU doesn't provide an external interface, it probably
+has an ``Embedded Trace Buffer'' (ETB) on the chip, which is a
+dedicated SRAM. 4KBytes is one common ETB size.
+Configuring an ETM coupled only to an ETB belongs in the CPU-specific
+(target) configuration file, since it works the same on all boards.
+...@end itemize
+
+ETM support in OpenOCD doesn't seem to be widely used yet.
+
+...@quotation Issues
+ETM support may be buggy, and at least some @command{etm config}
+parameters should be detected by asking the ETM for them.
+It seems like a GDB hookup should be possible,
+as well as triggering trace on specific events
+(perhaps @emph{handling IRQ 23} or @emph{calls foo()}).
+There should be GUI tools to manipulate saved trace data and help
+analyse it in conjunction with the source code.
+It's unclear how much of a common interface is shared
+with the current XScale trace support, or should be
+shared with eventual Nexus-style trace module support.
+...@end quotation
+
+...@subsubsection ETM Configuration
+ETM setup is coupled with the trace port driver configuration.
+
+...@deffn {Config Command} {etm config} target width mode clocking driver
+Declares the ETM associated with @var{target}, and associates it
+with a given trace port @var{driver}.
[Openocd-development] [PATCH] encapsulate jtag interface
Hi all,
The following patch encapsulates the global JTAG interface pointer,
adding a wrapper routine for the only out-of-module user.
I will apply unless there are objections.
Cheers,
Zach
==
Encapsulate the global jtag jtag_interface pointer:
- Add jtag_interface_quit, factored from exit_handler() in openocd.c.
- Remove its extern declaration.
- Add static keyword to its definition.
---
jtag/jtag.c | 16 +++-
jtag/jtag.h |5 +++--
openocd.c |4 +---
3 files changed, 19 insertions(+), 6 deletions(-)
---
Index: src/jtag/jtag.c
===
--- src/jtag/jtag.c (revision 1942)
+++ src/jtag/jtag.c (working copy)
@@ -227,7 +227,7 @@
NULL,
};
-jtag_interface_t *jtag = NULL;
+static jtag_interface_t *jtag = NULL;
/* configuration */
static jtag_interface_t *jtag_interface = NULL;
@@ -2407,6 +2407,20 @@
return ERROR_OK;
}
+int jtag_interface_quit(void)
+{
+ if (!jtag || !jtag-quit)
+ return ERROR_OK;
+
+ // close the JTAG interface
+ int result = jtag-quit();
+ if (ERROR_OK != result)
+ LOG_ERROR(failed: %d, result);
+
+ return ERROR_OK;
+}
+
+
int jtag_init_reset(struct command_context_s *cmd_ctx)
{
int retval;
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 1942)
+++ src/jtag/jtag.h (working copy)
@@ -515,8 +515,6 @@
extern jtag_event_callback_t* jtag_event_callbacks;
-extern jtag_interface_t* jtag; /* global pointer to configured JTAG
interface */
-
extern int jtag_speed;
extern int jtag_speed_post_reset;
@@ -538,6 +536,9 @@
*/
extern int jtag_interface_init(struct command_context_s* cmd_ctx);
+/// Shutdown the JTAG interface upon program exit.
+extern int jtag_interface_quit(void);
+
/* initialize JTAG chain using only a RESET reset. If init fails,
* try reset + init.
*/
Index: src/openocd.c
===
--- src/openocd.c (revision 1942)
+++ src/openocd.c (working copy)
@@ -79,9 +79,7 @@
static void exit_handler(void)
{
- /* close JTAG interface */
- if (jtag jtag-quit)
- jtag-quit();
+ jtag_interface_quit();
}
static int log_target_callback_event_handler(struct target_s *target, enum
target_event event, void *priv)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] encapsulate jtag interface
On Friday 29 May 2009, Zach Welch wrote: I will apply unless there are objections. Clean code is happy code. Are you *sure* you want to see happy code? :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] reset config updates
On Fri, 2009-05-29 at 12:51 -0700, David Brownell wrote:
Make it so the magic reset_config keywords can be provided in any
order. This eliminates needless error paths, and makes it easier
to define things at the right level (adapter, board, target).
It also includes two other behavioral changes:
(1) When handle_reset_config sees a parameter error, it
exits without changing anything. This is best viewed
as a bugfix. (Old behavior: restore defaults, even if
they weren't previously active.)
(2) Only the behaviors that were explicitly specified get
changed. (Old behavior: everything else gets reset to
the default.) So for example you can now specify SRST
drive requirements without saying anything about the
three unrelated topics you previously had to specify.
That second one might cause confusion for any configs that end
up calling reset_config twice, so it will deserve to be called
out in the release notes. (There were no such configurations in
the current OpenOCD source tree.)
Update docs accordingly. Note that at least some versions of
the texi-to-html tools can't handle @xref{with spaces}, but
those work properly in PDF and in the info files.
---
This is the updated version of the patch I sent before.
Sanity tested.
doc/openocd.texi | 75 +---
src/jtag/jtag.c | 140 -
2 files changed, 144 insertions(+), 71 deletions(-)
Committed, r1944.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi - ARM trace docs (ETM, ETB)
On Fri, 2009-05-29 at 17:50 -0700, David Brownell wrote: Provide basic documentation on the ARM ETM and ETB trace commands. Fix minor goofs in registration of the ETM commands; and whitespace issues in the proof-of-concept oocd_trace code. (Plus include a ref to Dominic's email saying that it's just proof-of-concept code.) Note that I'm still not sure whether the ETM support works. But documenting how it's expected to work should help sort out which behaviors are bugs, which will help get bugs patched. --- doc/openocd.texi| 191 +++--- src/target/etm.c|8 + src/target/oocd_trace.c | 109 +- 3 files changed, 242 insertions(+), 66 deletions(-) Committed, r1945. The whitespace changes were committed in r1946. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 libftdi and ftd2xx performance
On Sat, May 30, 2009 at 12:40 AM, Magnus Lundin lun...@mlu.mine.nu wrote: Hello list The accepted wisdom seems to be that libftdi is slower than ftd2xx, and when performance is low change to ftd2xx. Is this true or a myth ? Two years ago, or three, this was true, today I am not so sure. I have made some small tests , single stepping arm7, uploading medium sized files to arm925ejs and what I can see is that the libftdi is actualyy a touch faster. ( Linux 2.6 Fedora ) Do we have any other hard facts about this question ? Not so sure if this helps. http://www.nonpolynomial.com/archives/2008/04/libusb-libftdi-latency-and-my-own-stupid.php But is all depends on the usage inside OpenOCD. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 libftdi and ftd2xx performance
On Sat, May 30, 2009 at 10:22 AM, Xiaofan Chen xiaof...@gmail.com wrote: Not so sure if this helps. http://www.nonpolynomial.com/archives/2008/04/libusb-libftdi-latency-and-my-own-stupid.php But is all depends on the usage inside OpenOCD. The key is to queue large bulk transfer for libusb based application. libusb 1.0 is potentially a good library to use to replace libusb 0.1 and even libftdi under Linux (and maybe Mac OS X). Another potential increase of speed is to use libusb-compat-0.1 (compat layer for libusb 1.0) to replace libusb-0.1 and you may get a lbit of speed increase without rewriting the programing using libusb 1.0. http://libusb.wiki.sourceforge.net/LibusbCompat0.1 http://article.gmane.org/gmane.comp.lib.libusb.devel.general/5364 By the way, Danile Drake has released libusb 1.0.1 and and libusb-compat-0.1.1 and they should be quite usable now. http://sourceforge.net/project/showfiles.php?group_id=1674 Major performance boost can come from the asynchronous I/O from libusb 1.0. http://libusb.sourceforge.net/api-1.0/group__asyncio.html -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
