Re: [Openocd-development] 0.2.0 Status Update
On Fri, May 29, 2009 at 4:51 PM, Zach Welch z...@superlucidity.net wrote: 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 Sorry this is a false alarm. The script I got has a problem of not setting the jtag_khz. After setting it to 30khz initially it seems to work now. -- 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] 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] 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] 0.2.0 Status Update
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. -- 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] 0.2.0 Status Update
(sorry for sending to Zach and not to the list, IMHO that Reply-To behaviour is annoying, despite what was written about that in the past) From the ordinary-user point of view. - ft2232 high-speed device support Does anyone use those? They are still pretty new and I haven't seen any finished interface with them. IMHO this is not required for 0.2.0 - finish work to allow parts of libopenocd to be exposed. IMHO also not required for 0.2.0, as there were no tests of that lib (?) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
