Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009, Xiaofan Chen wrote: Correct me if I'm wrong here: currently, the *ENTIRE* reason to care about the D2XX library is to get simpler Windows support. Not so sure about the word ENTIRE. I think it certainly is the main reason. There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. Which, by latest reports, are at best marginal. I don't see a win for the project in supporting such weakly motivated wants. Heck, just imagine the last two weeks without any email flamage wasted on the D2XX stuff. MAJOR win!!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
David Brownell pisze: There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. Which, by latest reports, are at best marginal. Where are those reports? It seems that I have missed another thing here... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] packaging OpenOCD for 0.2.0
On Thursday 25 June 2009, Zach Welch wrote: Hi all, Here is my summary of what I think needs to be done to prepare for a source-only 0.2.0 release, which will help promote OpenOCD and maybe attract new developers that can help fix the binary distribution issue. ... So again, we need to forget about the binary distribution problems in the OpenOCD development community for the time being. These issues will all be resolved externally or in future releases. I'm OK with the 0.2.0 release being source only, with minor updates (0.2.1 etc) as needed. The download page http://developer.berlios.de/project/showfiles.php?group_id=4148 shows lots of downloads of the MS-Windows binary -- which we are not in a position to update for now! -- and most of the rest are the source tarball, not the Fedora binary. Debian unstable is using SVN, Thursday's HEAD (r2403) in fact (!)... What needs to change before 0.2.0 finalizes? Maybe a handful of patches yet. I don't see much point in stretching it out too much longer. For the record, why don't we label r2403 as RC1? And focus this next week on high priority fixes, aiming at an RC2 for next Thursday's HEAD. Hoping that RC2 will be 0.2.0 ... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] packaging OpenOCD for 0.2.0
David Brownell pisze: For the record, why don't we label r2403 as RC1? Maybe because that fails to build of Windows without two patches I submitted 2 days ago, that weren't accepted yet? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote: David Brownell pisze: There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. Which, by latest reports, are at best marginal. Where are those reports? It seems that I have missed another thing here... I remember reading about it multiple times, e.g. here: http://lists.berlios.de/pipermail/openocd-development/2009-June/008050.html and here (last paragraph): http://lists.berlios.de/pipermail/openocd-development/2009-June/008779.html Pavel's explanation matches with what I remember about this issue. I'm preparing a test setup to verify the numbers just now. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] packaging OpenOCD for 0.2.0
On Saturday 27 June 2009, Freddie Chopin wrote: David Brownell pisze: For the record, why don't we label r2403 as RC1? Maybe because that fails to build of Windows without two patches I submitted 2 days ago, that weren't accepted yet? Exactly the kind of information we need! The strtok thing? URLs would help... We could still label it RC1, though that issue makes it clear that RC1 couldn't be 0.2.0 ... Hmm ... would you be a good candidate to track release blockers in terms of build-from-source on MS-Windows? Any bugs too. We need someone to do that. Post a list every few days, to track the issues that are still open. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Saturday 27 June 2009, Dominic wrote: On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote: David Brownell pisze: There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. Which, by latest reports, are at best marginal. Where are those reports? It seems that I have missed another thing here... I remember reading about it multiple times, e.g. here: http://lists.berlios.de/pipermail/openocd-development/2009-June/008050.html and here (last paragraph): http://lists.berlios.de/pipermail/openocd-development/2009-June/008779.html Pavel's explanation matches with what I remember about this issue. I'm preparing a test setup to verify the numbers just now. ISTR Nicolas Pitre reported almost-the-same-speed too. At least, on Linux. I believe MS-Windows does have a speed difference, but that's not at issue here. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] packaging OpenOCD for 0.2.0
On Saturday 27 June 2009 10:10:16 Freddie Chopin wrote: David Brownell pisze: For the record, why don't we label r2403 as RC1? Maybe because that fails to build of Windows without two patches I submitted 2 days ago, that weren't accepted yet? Øyvind replied to your posting with a patch that removes alloca all together (there's only one occurrence). I'm not sure about the strtok_r issue. As I see it strtok_r usage in this case isn't about thread-safety but about being able to call strtok multiple times with different strings. The note on this MSDN page says this isn't safe (and it can't be, seeing it lacks strtok_r's extra context holding pointer): http://msdn.microsoft.com/en-us/library/2c8d19sb(VS.80).aspx Maybe Duane should comment on this, it's his code. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Dominic pisze: On Saturday 27 June 2009 08:58:00 Freddie Chopin wrote: David Brownell pisze: There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. Which, by latest reports, are at best marginal. Where are those reports? It seems that I have missed another thing here... I remember reading about it multiple times, e.g. here: http://lists.berlios.de/pipermail/openocd-development/2009-June/008050.html and here (last paragraph): http://lists.berlios.de/pipermail/openocd-development/2009-June/008779.html How about here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html Libraries achieve same speed when uploading to RAM, but it seems that ROM speeds are different... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Saturday 27 June 2009, Freddie Chopin wrote: How about here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html That's Windows though -- different question. Libraries achieve same speed when uploading to RAM, but it seems that ROM speeds are different... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix Rev 2403 build on Windows
Second attempt:
1. replace alloca with malloc - that's Øyvind's patch, but I've fixed r
vs. retval and I've removed one useless part.
2. add Newlib's strtok_r to replacements so that membuf.c could be build
on Windows
4\/3!!
Index: src/helper/membuf.c
===
--- src/helper/membuf.c (revision 2405)
+++ src/helper/membuf.c (working copy)
@@ -23,6 +23,10 @@
#include stdlib.h
#include string.h
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
#include membuf.h
struct membuf {
Index: src/helper/replacements.c
===
--- src/helper/replacements.c (revision 2405)
+++ src/helper/replacements.c (working copy)
@@ -287,4 +287,87 @@
return retcode;
}
+
+/*
+ * strtok_r() taken from Newlib, as no strtok_r() is present for WIN32/MinGW
platform
+ * Modified a bit to remove unused blocks associated with skip_leading_delim
parameter
+ */
+
+/* begin Newlib copyright */
+
+/*
+ * Copyright (c) 1988 Regents of the University of California.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/* end Newlib copyright */
+
+char *strtok_r(char *s, const char *delim, char **lasts)
+{
+ register char *spanp;
+ register int c, sc;
+ char *tok;
+
+ if (s == NULL (s = *lasts) == NULL)
+ return (NULL);
+
+ /*
+* Skip (span) leading delimiters (s += strspn(s, delim), sort of).
+*/
+cont:
+ c = *s++;
+ for (spanp = (char *)delim; (sc = *spanp++) != 0;)
+ if (c == sc)
+ goto cont;
+
+ if (c == 0) { /* no non-delimiter characters */
+ *lasts = NULL;
+ return (NULL);
+ }
+ tok = s - 1;
+
+ /*
+* Scan token (scan for delimiters: s += strcspn(s, delim), sort of).
+* Note that delim must have one NUL; we stop if we see that, too.
+*/
+ for (;;) {
+ c = *s++;
+ spanp = (char *)delim;
+ do {
+ if ((sc = *spanp++) == c) {
+ if (c == 0)
+ s = NULL;
+ else
+ s[-1] = 0;
+ *lasts = s;
+ return (tok);
+ }
+ } while (sc != 0);
+ }
+ /* NOTREACHED */
+}
#endif
Index: src/helper/replacements.h
===
--- src/helper/replacements.h (revision 2405)
+++ src/helper/replacements.h (working copy)
@@ -157,6 +157,7 @@
#endif /* IS_MINGW */
int win_select(int max_fd, fd_set *rfds, fd_set *wfds, fd_set *efds, struct
timeval *tv);
+char *strtok_r(char *s, const char *delim, char **lasts);
#endif /* _WIN32 */
Index: src/flash/at91sam3.c
===
--- src/flash/at91sam3.c(revision 2405)
+++ src/flash/at91sam3.c(working copy)
@@ -2146,7 +2146,7 @@
return ERROR_FAIL;
}
- pagebuffer = alloca(pPrivate-page_size);
+ pagebuffer = malloc(pPrivate-page_size);
// what page do we start end in?
page_cur = offset / pPrivate-page_size;
@@ -2167,7 +2167,7 @@
LOG_DEBUG(Special case, all in one page);
r = sam3_page_read(pPrivate,
Re: [Openocd-development] ftd2xx - libftdi
On Saturday 27 June 2009 11:30:07 David Brownell wrote: Pavel's explanation matches with what I remember about this issue. I'm preparing a test setup to verify the numbers just now. ISTR Nicolas Pitre reported almost-the-same-speed too. At least, on Linux. I believe MS-Windows does have a speed difference, but that's not at issue here. - Dave Here are my test results: Target: AT91SAM9260 on a Olimex SAM9-L9260 (ARM926EJ-S) JTAG: Amontec JTAG-Key OS: (K)Ubuntu 9.04 Host: Core2Duo @ 2.6 GHz OpenOCD: SVN 2405, built just an hour ago libftdi: /usr/lib/libftdi.so.1.13.0 (9.04 stock version) dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 43.130390s (24.311 KB/s) arm7_9 fast_memory_access enable fast memory access is enabled dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 33.895313s (30.935 KB/s) load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 12.915277s (81.188 KB/s) arm7_9 dcc_downloads enable dcc downloads are enabled load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 4.363197s (204.322 KB/s) libftdi: /usr/local/lib/libftdi.so.1.16.0 (--with-async-mode) - dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 43.382168s (24.170 KB/s) arm7_9 fast_memory_access enable fast memory access is enabled dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 34.004364s (30.836 KB/s) load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 12.834919s (81.697 KB/s) arm7_9 dcc_downloads enable dcc downloads are enabled load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 4.368081s (240.054 KB/s) FTD2XX: /usr/local/lib/libftd2xx.so.0.4.13 -- dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 41.470509s (25.284 KB/s) arm7_9 fast_memory_access enable fast memory access is enabled dump_image /home/vmaster/test.img 0x2000 1048576 dumped 1048576 byte in 31.890425s (32.880 KB/s) load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 14.818524s (70.761 KB/s) arm7_9 dcc_downloads enable dcc downloads are enabled load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 5.044282s (207.874 KB/s) These tests show libftdi ahead of ftd2xx or only very slightly behind. This is by no means a complete performance evaluation and the devil might be in the details, but I think it shows that these days libftdi is on par with ftd2xx, at least on Linux. The libftdi 1.13 that comes with (K)Ubuntu 9.04 is already compiled --with-- async-mode. I don't have an older version that lacks this feature lying around. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 7:38 PM, Dominicdominic.r...@gmx.de wrote: These tests show libftdi ahead of ftd2xx or only very slightly behind. This is by no means a complete performance evaluation and the devil might be in the details, but I think it shows that these days libftdi is on par with ftd2xx, at least on Linux. http://www.nonpolynomial.com/archives/2008/04/libusb-libftdi-latency-and-my-own-stupid.php Just take note ftd2xx is based on libusb 0.1 under Linux. Whereas ftd2xx under Windows is not based on libusb-win32 0.1. The libftdi 1.13 that comes with (K)Ubuntu 9.04 is already compiled --with--async-mode. I don't have an older version that lacks this feature lying around. From the above link, it seems that moving to libusb 1.0 will further increase the performance for Linux (compared to libftdi). -- 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] Summer coding project proposal
On Thu, Jun 25, 2009 at 8:55 PM, Michael Bruckmbr...@digenius.de wrote: On Wed, Jun 24, 2009 at 17:34, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: The libusb improvements certainly sound interesting, however no one has stepped forward to implement them or to pay someone to implement them. They may or may not also require some reverse engineering plus extensive profiling that would make them more time-consuming than the wrapper. So they don't seem like a near-term solution at the moment. Others have stated emphatically that the specifications are open and available for the developers to take a whack at replacing their library. Unless it is incomplete or inaccurate, the matter should be straightforward enough. :) Heh. I have not seen a spec that documents the USB endpoints and how to interact with them. But if someone has a link to that it would be nice if that person could post that. The libftdi code may help. One more page through Google. http://yosemitefoothills.com/Electronics/FTDI_Chip_Commands.html -- 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] ftd2xx - libftdi
Dominic a écrit : load_image /home/vmaster/test.img 0x2000 bin 1048576 byte written at address 0x2000 downloaded 1048576 byte in 4.363197s (204.322 KB/s) That was the problem I had, I will give another try. With results like this I would say that I have no more objection. Flashing devices have always been so bad with the ftdi driver that I chose to ignore it. Does it work good on a 64 bits OS? I have installed Ubuntu 9.04 this week as it seems to have made some important performance progress. Actually it is Ubuntu Studio, a derivative of the official Ubuntu. Fedora 11 seems very slow compared to this. I haven't had time to try it on my 64 bits Linux yet. I have been too busy at work (unpaid overtime) Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Can someone check this on windows too?
Hello List, I want to test the performance like Dominic had done before: https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html But here I use r2348 with libftdi and ftd2xx. dump_image without the fast memory access was working, but if I enable the fast memory access (arm7_9 fast_memory_access enable) I got some error messages like: couldn't write MPSSE command to FT2232 With libftdi and FTD2XX, the same result. I could not compile r2405, even not with the patch from Freddie. The problem with the patch is, that the cygwin patch program will not accept the patch itself. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
This patch enables dynamic loading of ftd2xx.dll in ft2232.c on Win32
platform.
It's made to work only on Win32 and for ftd2xx.dll in ft2232.c - it
doesn't affect linux, libftdi or any other modules that could use that.
That's the first from a series that I am planing (win32 only):
1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c
2. enable dynamic loading of libusb0.dll in ft2232.c
3. make it possible to have support for both libftdi and ftd2xx at the
same time in ft2232.c
n. enable dynamic loading for some other modules - jlink, rlink, presto
n+1. make it possible to have support for both libftdi and ftd2xx at the
same time in presto.c
I can do the same for linux, but as I have no means for testing I'd
rather pass that to someone else. With help in testing I can try to do
that myself.
What would be the opinion of maintainers? Should I continue?
Anyone with FT2232 based dongle and Windows - please test. When
compiling enable ft2232 with ftd2xx.dll only, as there are other
interfaces that use dynamic libraries not yet converted to dynamic
loading. I can also provide you with a compiled executable, as current
trunk doesn't build on Windows - in such case contact me and I'll post
such executable somewhere.
The main difference is that patched copy would run WITHOUT ftd2xx.dll,
so you may test in the following way:
1. locate all ftd2xx.dll occurencies that can be reached through system
PATH (usually in /bin/ with openocd, Windows/system32, but sometimes may
be more) and rename them to anything else - for example ftd2xx.dl_
2. trying to run some earlier version would result in failure, as
windows would not be able to load library. even openocd -v will fail
3. Modified version shoud run and in case of using ft2232 based config
files should report an Error (on command line!) that the library cannot
be loaded. openocd -v shoud work without problems.
4. Rename at least one ftd2xx.dll to original name and try again -
modified version should work as expected.
4\/3!!
Index: src/jtag/ft2232.c
===
--- src/jtag/ft2232.c (revision 2405)
+++ src/jtag/ft2232.c (working copy)
@@ -63,6 +63,38 @@
#include ftdi.h
#endif
+/* Dynamic loading of libraries at runtime - only for Win32 and ftd2xx.dll
currently */
+
+#if defined(_WIN32) BUILD_FT2232_FTD2XX == 1
+#define FTD2XX_DYNAMIC 1
+#else
+#define FTD2XX_DYNAMIC 0
+#endif
+
+#if FTD2XX_DYNAMIC == 1
+
+// typedefs for all used functions from ftd2xx.dll library
+typedef FT_STATUS (WINAPI *FT_Write_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToWrite, LPDWORD lpBytesWritten);
+typedef FT_STATUS (WINAPI *FT_Read_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToRead, LPDWORD lpBytesReturned);
+typedef FT_STATUS (WINAPI *FT_OpenEx_t)(PVOID pArg1, DWORD Flags, FT_HANDLE
*pHandle);
+typedef FT_STATUS (WINAPI *FT_ListDevices_t)(PVOID pArg1, PVOID pArg2, DWORD
Flags);
+typedef FT_STATUS (WINAPI *FT_SetLatencyTimer_t)(FT_HANDLE ftHandle, UCHAR
ucLatency);
+typedef FT_STATUS (WINAPI *FT_GetLatencyTimer_t)(FT_HANDLE ftHandle, PUCHAR
pucLatency);
+typedef FT_STATUS (WINAPI *FT_SetTimeouts_t)(FT_HANDLE ftHandle, ULONG
ReadTimeout, ULONG WriteTimeout);
+typedef FT_STATUS (WINAPI *FT_SetBitMode_t)(FT_HANDLE ftHandle, UCHAR ucMask,
UCHAR ucEnable);
+typedef FT_STATUS (WINAPI *FT_GetDeviceInfo_t)(FT_HANDLE ftHandle, FT_DEVICE
*lpftDevice, LPDWORD lpdwID, PCHAR SerialNumber, PCHAR Description, LPVOID
Dummy);
+typedef FT_STATUS (WINAPI *FT_Purge_t)(FT_HANDLE ftHandle, ULONG Mask);
+typedef FT_STATUS (WINAPI *FT_Close_t)(FT_HANDLE ftHandle);
+
+// library handle
+static HINSTANCE dynamic_library;
+
+// global pointers for read and write functions
+static FT_Write_t FT_Write_ptr;
+static FT_Read_t FT_Read_ptr;
+
+#endif
+
/* max TCK for the high speed devices 3 kHz */
#defineFTDI_2232H_4232H_MAX_TCK3
@@ -343,7 +375,12 @@
#if BUILD_FT2232_FTD2XX == 1
FT_STATUS status;
DWORD dw_bytes_written;
+
+#if FTD2XX_DYNAMIC == 1
+ if ((status = (*FT_Write_ptr)(ftdih, buf, size, dw_bytes_written)) !=
FT_OK)
+#else
if ((status = FT_Write(ftdih, buf, size, dw_bytes_written)) != FT_OK)
+#endif
{
*bytes_written = dw_bytes_written;
LOG_ERROR(FT_Write returned: %lu, status);
@@ -381,8 +418,13 @@
while ((*bytes_read size) timeout--)
{
+#if FTD2XX_DYNAMIC == 1
+ if ((status = (*FT_Read_ptr)(ftdih, buf + *bytes_read, size -
+ *bytes_read, dw_bytes_read))
!= FT_OK)
+#else
if ((status = FT_Read(ftdih, buf + *bytes_read, size -
*bytes_read, dw_bytes_read)) !=
FT_OK)
+#endif
{
*bytes_read = 0;
LOG_ERROR(FT_Read returned: %lu, status);
@@ -1803,6 +1845,78 @@
[Openocd-development] clearing all breakpoints watch points
The cortexM3 - and perhaps other targets - have a problem. When GDB exits/disconnects/reconnects - these two functions get called: /* we must remove all breakpoints registered to the target as a previous * GDB session could leave dangling breakpoints if e.g. communication * timed out. */ breakpoint_clear_target(gdb_service-target); watchpoint_clear_target(gdb_service-target); REFERENCE: gdb_server.c - line 760 (or so) However, if the target is not HALTED.. The breakpoints are *NOT* removed. Example: @ arm7_9_unset_watchpoint() @ cortex_m3_remove_breakpoint() @ mips_m4k_remove_breakpoint() Perhaps - things went bad and you had to *reset* the target, or something - but did not *exit* openocd and *resetart* openocd - or other reasons. Slowly target resources are consumed/leaked - specifically hardware compare registers. Suggestions? At some point, the only solution is to bounce/reset/restart openocd. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Freddie, Thanks for this patch, I like the idea :-) I don't have any experience in OpenOCD development but I did have a look at the patch and have two questions/remarks: 1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a different place then all the others? Isn't it cleaner to keep all the initializations together? 2) Isn't it possible to define a macro function for the FT_xxx functions in case of FTD2XX_DYNAMIC? Something like: #if FTD2XX_DYNAMIC == 1 #define FT_Close( handler ) (*FT_Close_ptr)( handler ) /* same for all other functions */ #endif This way you don't have to add ifdef's around all function calls and it'll make the patch smaller and less possibilities for mistakes in the future. gr. Ronald Original Message Subject: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c From: Freddie Chopin freddie_cho...@op.pl To: openocd-development openocd-development@lists.berlios.de Date: Sat Jun 27 2009 19:08:20 GMT+0200 (Romance Standard Time) This patch enables dynamic loading of ftd2xx.dll in ft2232.c on Win32 platform. It's made to work only on Win32 and for ftd2xx.dll in ft2232.c - it doesn't affect linux, libftdi or any other modules that could use that. That's the first from a series that I am planing (win32 only): 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c 2. enable dynamic loading of libusb0.dll in ft2232.c 3. make it possible to have support for both libftdi and ftd2xx at the same time in ft2232.c n. enable dynamic loading for some other modules - jlink, rlink, presto n+1. make it possible to have support for both libftdi and ftd2xx at the same time in presto.c I can do the same for linux, but as I have no means for testing I'd rather pass that to someone else. With help in testing I can try to do that myself. What would be the opinion of maintainers? Should I continue? Anyone with FT2232 based dongle and Windows - please test. When compiling enable ft2232 with ftd2xx.dll only, as there are other interfaces that use dynamic libraries not yet "converted" to dynamic loading. I can also provide you with a compiled executable, as current trunk doesn't build on Windows - in such case contact me and I'll post such executable somewhere. The main difference is that patched copy would run WITHOUT ftd2xx.dll, so you may test in the following way: 1. locate all ftd2xx.dll occurencies that can be reached through system PATH (usually in /bin/ with openocd, Windows/system32, but sometimes may be more) and rename them to anything else - for example ftd2xx.dl_ 2. trying to run some earlier version would result in failure, as windows would not be able to load library. even "openocd -v" will fail 3. Modified version shoud run and in case of using ft2232 based config files should report an Error (on command line!) that the library cannot be loaded. "openocd -v" shoud work without problems. 4. Rename at least one ftd2xx.dll to original name and try again - modified version should work as expected. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clearing all breakpoints watch points
duane Slowly target resources are consumed/leaked - specifically hardware duane compare registers. duane Suggestions? BTW - this can also be caused by GDB croaking.. while leaving the target running. Examples - SVN 2408 - adds some useful debug information to help see this problem The general idea is a unique id for each breakpoint/watchpoint - ie: BPID.. below. Here, a breakpoint was added, the target went off a clif - and now GDB cannot *remove* the breakpoint because the target is in a bad state. Leak example. Debug: 1164 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,800c0,2' Debug: 1165 124671 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Debug: 1166 124671 target.c:1408 target_write_u32(): address: 0xe000201c, value: 0x400800c1 Debug: 1167 124671 cortex_m3.c:926 cortex_m3_set_breakpoint(): fpc_num 5 fpcr_value 0x400800c1 Debug: 1168 124671 cortex_m3.c:953 cortex_m3_set_breakpoint(): BPID: 6, Type: 0, Address: 0x000800c0 Length: 2 (set=6) Debug: 1169 124671 breakpoints.c:104 breakpoint_add(): added hardware breakpoint at 0x000800c0 of length 0x0002, (BPID: 6) Debug: 1170 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 's' Debug: 1171 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'g' Debug: 1172 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,800c0,2' Debug: 1173 124671 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Warn : 1174 124671 cortex_m3.c:1072 cortex_m3_remove_breakpoint(): target not halted Debug: 1175 124671 breakpoints.c:128 breakpoint_free(): BPID: 6 Example of final failure: Debug: 1911 139921 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,800c0,2' Debug: 1912 139921 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Info : 1913 139937 cortex_m3.c:1047 cortex_m3_add_breakpoint(): no flash patch comparator unit available for hardware breakpoint Info : 1914 139937 breakpoints.c:81 breakpoint_add(): can't add hardware breakpoint, resource not available (BPID=7) -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
I still am stuck and no breaky points ! Really? I'm confused. I'm seeing other problems - that are some what related - but I'm not sure (see earlier email subject: Clearing all breakpoints watch points) I see you only setting one breakpoint. I see the breakpoint working. If I look at the log - vrs - the source code - I see the following: Debug: 454 1297182 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 509 1352651 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 515 1627149 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 570 1867380 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 629 5711327 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 684 5723749 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' 1) All received packets are always printed during debug logs. see: gdb_server.c - line 2050 - 2) All Z (upper case) packets *set* breakpoints 3) All z (lower case) packets *clear* breakpoints The fields are: Z type COMMA address COMMA size See: gdb_breakpoint_watchpoint_add() - line 1375 of gdb_server.c GDB is always using the hardware breakpoint, type 1. Why? Because GDB knows the breakpoint location is in *FLASH* GDB knows this because of the memory map that was sent. ie: gdb_memory_map enable It is always setting/clearing the break point at address 0x196, always a thumb break point (length is 2) I don't see errors in your log - I see them in my log... -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Ronald Vanschoren pisze: I don't have any experience in OpenOCD development Just like me [; 1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a different place then all the others? Isn't it cleaner to keep all the initializations together? As a trV embedded engineer I've saved some memory [; Keeping all together would be clearer, but I decided to minimise the number of globals and: 1. read() and write() are global, as these are used all the time 2. in ft2232_init() I initialize above two globals and functions that are used only once in ft2232_init() 3. as close() and (probably?) purge() are not used very frequently, I initialize theirs function pointers there - locally. This way there are only 3 globals (hangle + 2 fn pointers) Anyone can tell me whether my assumption about ft2232_purge_ftd2xx() is correct? If that is called often, than I'll make a global pointer for FT_Purge... 2) Isn't it possible to define a macro function for the FT_xxx functions in case of FTD2XX_DYNAMIC? Something like: #if FTD2XX_DYNAMIC == 1 #define FT_Close( handler ) (*FT_Close_ptr)( handler ) /* same for all other functions */ #endif This way you don't have to add ifdef's around all function calls and it'll make the patch smaller and less possibilities for mistakes in the future. That would be very cool, but you'd get milions of errors like FT_Whatever redefined, previous definition was Somewhere, because the definitions of FT_Whatever() is in the header which has to be included, as there are many required constants (like FT_OK) and typedefs (like FT_STATUS) there. After the whole series of patches (everything loaded dynamically on all platforms), there won't be so many #ifs : I tried to make my changes an addition rather than modification - this way I'm pretty sure that this patch won't break anything else. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
1) Why do you initialize the FT_Close_ptr and FT_Purge_ptr in a different place then all the others? Isn't it cleaner to keep all the initializations together? As a trV embedded engineer I've saved some memory [; Keeping all together would be clearer, but I decided to minimise the number of globals and: 1. read() and write() are global, as these are used all the time 2. in ft2232_init() I initialize above two globals and functions that are used only once in ft2232_init() 3. as close() and (probably?) purge() are not used very frequently, I initialize theirs function pointers there - locally. This way there are only 3 globals (hangle + 2 fn pointers) Anyone can tell me whether my assumption about ft2232_purge_ftd2xx() is correct? If that is called often, than I'll make a global pointer for FT_Purge... Fair enough, us embedded engineers might be a bit too focussed on memory, but it's good practice anyway :-) 2) Isn't it possible to define a macro function for the FT_xxx functions in case of FTD2XX_DYNAMIC? Something like: #if FTD2XX_DYNAMIC == 1 #define FT_Close( handler ) (*FT_Close_ptr)( handler ) /* same for all other functions */ #endif This way you don't have to add ifdef's around all function calls and it'll make the patch smaller and less possibilities for mistakes in the future. That would be very cool, but you'd get milions of errors like "FT_Whatever redefined, previous definition was Somewhere", because the definitions of FT_Whatever() is in the header which has to be included, as there are many required constants (like FT_OK) and typedefs (like FT_STATUS) there Did you actually try it? There is no redefinition normally (depends on how the .h file of ftd2xx is made) and I think I used this approach before (although slightly different). Guess it's a 2 minute check for you (just one function will do), so if you don't mind :-) gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
Ronald Vanschoren pisze: Did you actually try it? There is no redefinition normally (depends on how the .h file of ftd2xx is made) and I think I used this approach before (although slightly different). Guess it's a 2 minute check for you (just one function will do), so if you don't mind :-) When I replace FT_Write_ptr with FT_Write, and define: #define FT_Write (*FT_Write) I get: ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
But you don't have to repace FT_Write_ptr with FT_Write, just keep it like that and do this: #define FT_Write (*FT_Write_ptr) but depending on how smart the preprocessor is, it might still complain about it, so likely it won't help. Thanks for trying, it's not that big of deal and actually I have nothing to say here anyways, so we can keep it as you made it :-) gr. Ronald Original Message Subject: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c From: Freddie Chopin freddie_cho...@op.pl To: openocd-development openocd-development@lists.berlios.de Date: Sat Jun 27 2009 20:16:41 GMT+0200 (Romance Standard Time) Ronald Vanschoren pisze: Did you actually try it? There is no redefinition normally (depends on how the .h file of ftd2xx is made) and I think I used this approach before (although slightly different). Guess it's a 2 minute check for you (just one function will do), so if you don't mind :-) When I replace FT_Write_ptr with FT_Write, and define: #define FT_Write (*FT_Write) I get: ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ft2232.c:94: error: 'FT_Write' redeclared as different kind of symbol C:/msys/1.0/home/chopin/openocd/ftd2xx/ftd2xx.h:251: error: previous declaration of 'FT_Write' was here ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
I take that back, what you propose is possible and works - I've done that wrong a while ago. I'll create a new version of patch soon. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
Does it seem to you like the reset process is flexible enough yet? The idea is that those targets where the tcl reset proc doesn't cut it would implement their own tcl reset proc from scratch. That seems undesirable when some key improvements can be more generically available. Like for starters, either a TAP event on TLR entry or a settable parameter saying how many TCK cycles must be issued in TLR before issuing JTAG commands. What we have now is jtag_ntrst_delay milliseconds, without clocks going. jtag_ntrst_clocks would address documented ICEpick and PXA255 constraints. And there are no doubt other similar small tweaks. Note the scaing problem with needing target-specific rewrites of ocd_process_reset: it's impractical to combine two such targets on one board... This avoids switching programming paradigm from procedural to event based, i.e. we could add events until the cows go home and still miss that crucial event for the next target. I'd call the current reset events procedural hooks, myself. Heck, they don't even accept any parameters ... :) I don't believe that it is possible to *ever* add a reset event that is flexible enough for all future targets. I'm in favour of adapting OpenOCD as we go along rather than create a hugely complicated monster reset scheme that still won't catch the next jtag router from hell problems. Routers weren't the only, or even the main, set of motivating examples... But you seem to agree that the reset process still has holes that need fixing (adapting); so that question is answered. I'm thinking .. no: - All those reset events go to debug targets ... but there's at least the ICEpick example, where a JRC needs 100+ TCK cycles after entering TLR, and it's easy to find others. Loading an FPGA, for one. Those aren't targets; so no events... I'm not even sure that the reset concept even applies to an FPGA. For Altera Nios I'd first like to program the FPGA, then reset the CPU. If I've got an FPGA *not* programmed with a Nios core, that model doesn't work. :) That issue isn't entirely reset. It's initialization, which is a separable chunk of reset processing. For a Nios core you could have system reset requiring both FPGA init loading the core, and then core reset. But other FPGA bitstreams might not have a target. - I was looking at DM355 documentation and it clearly distinguishes cold resets -- both TRST and SRST get cycled -- from warm ones -- SRST only. We don't seem to have a clean way to do warm today. soft_reset_halt? No, that's a different beast. It applies to the current target and doesn't involve SRST. One reason to want a warm reset is that it leaves all the debug/jtag stuff alone. Maybe you tweaked some settings so that some things become observable during the reset/reinit sequence. [I've deleted those items where I had no useful input at this time] And I suspect that if I looked around a bit, I'd find more such cases where the reset model isn't (yet!) advanced enough. Thoughts? A target/board config file can reimplement the reset proc from scratch. How far does that get you? As a user, way deeper into the undocumented innards of OpenOCD than I want to be. ;) As a developer, it's hard to say without doing it. My initial reaction is that the reset processes are not yet factored well enough to support everything that I've happened across. But experimenting with a few individual targets should help identify more of the holes. What I'd like to see is a kind of reset toolkit which would make that practical. But it's not really there yet. Reimplement ocd_process_reset is not a scalable approach. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
This avoids switching
programming paradigm from procedural to
event based, i.e. we could add events until
the cows go home and still miss that crucial
event for the next target.
I'd call the current reset events procedural
hooks, myself. Heck, they don't even accept
any parameters ... :)
The original idea/concept for the events was Tck/Tk bind - what i
wanted to do was add support for %T for target, and a host of other
things - much like Tk has %w for window name, and %x and %y for event
location - stuff like that. But never got around to it. Mostly because I
wanted the event stuff to 'gel' a little.
I don't believe that it is possible to *ever*
add a reset event that is flexible enough for
all future targets. I'm in favour of adapting OpenOCD
as we go along rather than create a hugely complicated
monster reset scheme that still won't catch the next
jtag router from hell problems.
Routers weren't the only, or even the main, set
of motivating examples...
But you seem to agree that the reset process
still has holes that need fixing (adapting);
so that question is answered.
Why don't we re-describe the reset process completely.
ie:We define a few models - ie: (A), and (B) - and call those complete.
(That would handle probably 90% of the simple situations).
Then - allow the reset command to be 100% re-written, perhaps what we
need is:
proc reset { } {
jtag assert TRST SRST
jtag sleep-msecs 250
jtag de-assert TRST
jtag ... scan command
jtag .. scan command
jtag .. scan command
jtag de-assert SRST
}
This would *DE*COUPLE* the entire process.
We could then - add a few *TARGET* specific commands, ie:
$TARGET reset-action NAME ... parameters
For example - ARM7/9 - support to do reset-halt, where you stop the
CPU @ the reset vector.
--
Today - the C code *controls* and *drives* the reset sequence.
I'm suggesting we turn that inside out - and make the TCL code - drive
the reset sequence - via commands above.
There would be a few *default* reset sequences - in tcl... that one
could point proc reset at.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Saturday 27 June 2009, Duane Ellis wrote:
Today - the C code *controls* and *drives* the reset sequence.
I'm suggesting we turn that inside out - and make the TCL code - drive
the reset sequence - via commands above.
That's a good direction, I think. Details TBD, but
certainly getting the current hard-coded SRST/TRST
reset policies from C into Tcl seems essential.
Tcl code would need to be able to query some of the
quirk flags -- srst pulling trst etc -- to figure out
how to diddle SRST and TRST in certain cases.
There would be a few *default* reset sequences - in tcl... that one
could point proc reset at.
I think I'd prefer to avoid that particular level of
need-to-rewrite. But maybe one having that handful of
standard models would remove the need for that, if the
models were sanely factored. (Initial design task:
come up with that factored handful of models.)
I'm not sure all the current events should be discarded,
for example, and the easiest way to preserve them would
involve less-than-wholesale replacement.
So for example, your:
proc reset { } {
jtag assert TRST SRST
jtag sleep-msecs 250
To my taste, msleep 250. ;)
jtag de-assert TRST
I'd like to see some jtag verify options here,
so that part of the reset sequence is likewise
not hard-wired in C code.
So maybe jtag verify from_trst [NBITS] would
verify the IR length of NBITs total against the
declared TAPs, and then the DR values for TAPs
that have an IDCODE instruction. And, harder,
do something sensible when there's no match...
today everything just continues to bull through.
jtag ... scan command
jtag .. scan command
jtag .. scan command
jtag de-assert SRST
}
That seems more like a component that should be plugged
into the reset sequence than a reset itself. (And it's
a good example of getting work done while SRST is
still asserted... something not all TAPS handle, but
some require.)
Doing a bit of brainstorming ... I think that should
be instead a proc hard_reset, with those scans
packaged not unlike the current *target* event ops,
except done as *TAP* events. Each TAP might need
different setup too.
That way for example if you've got a system that has
no SRST and must instead issue resets through JTAG ops,
just hard_reset would get overridden.
And from the user interaction perspective, my initial
thought is that being able to customize behavior of
resets by permitting reset hard, reset soft, and
other operations (reset fred, reset usb, etc)
would seem a bit nicer than needing to define a bunch
of custom operations. But those models can be argued.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sat, 2009-06-27 at 20:50 +0200, Freddie Chopin wrote:
Second version of previous patch improved with suggestions from Ronald.
Pls try (; Works for me :
This patch now looks 1000 times better with the changes from Ronald.
Thanks to both of you for producing and refining it.
My only remaining suggestion would be to add a macro that eliminates the
duplicate calls the GetProcAddress. From what I can see, each of those
5 line blocks can be reduced into a single macro call with the proper
symbol name as the only argument. The magic that I used to implement
the parse_type helpers in command.c will be helpful to see how to do it,
but you might also need to look up how to stringify too.
Thanks for making these improvements.
--Z
plain text document attachment (win32_ft2232_ftd2xx_dynamic_v2.patch)
Index: ft2232.c
===
--- ft2232.c (revision 2405)
+++ ft2232.c (working copy)
@@ -63,6 +63,51 @@
#include ftdi.h
#endif
+/* Dynamic loading of libraries at runtime - only for Win32 and ftd2xx.dll
currently */
+
+#if defined(_WIN32) BUILD_FT2232_FTD2XX == 1
+#define FTD2XX_DYNAMIC 1
+#else
+#define FTD2XX_DYNAMIC 0
+#endif
+
+#if FTD2XX_DYNAMIC == 1
+
+// typedefs for all used functions from ftd2xx.dll library
+typedef FT_STATUS (WINAPI *FT_Write_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToWrite, LPDWORD lpBytesWritten);
+typedef FT_STATUS (WINAPI *FT_Read_t)(FT_HANDLE ftHandle, LPVOID lpBuffer,
DWORD dwBytesToRead, LPDWORD lpBytesReturned);
+typedef FT_STATUS (WINAPI *FT_OpenEx_t)(PVOID pArg1, DWORD Flags, FT_HANDLE
*pHandle);
+typedef FT_STATUS (WINAPI *FT_ListDevices_t)(PVOID pArg1, PVOID pArg2, DWORD
Flags);
+typedef FT_STATUS (WINAPI *FT_SetLatencyTimer_t)(FT_HANDLE ftHandle, UCHAR
ucLatency);
+typedef FT_STATUS (WINAPI *FT_GetLatencyTimer_t)(FT_HANDLE ftHandle, PUCHAR
pucLatency);
+typedef FT_STATUS (WINAPI *FT_SetTimeouts_t)(FT_HANDLE ftHandle, ULONG
ReadTimeout, ULONG WriteTimeout);
+typedef FT_STATUS (WINAPI *FT_SetBitMode_t)(FT_HANDLE ftHandle, UCHAR
ucMask, UCHAR ucEnable);
+typedef FT_STATUS (WINAPI *FT_GetDeviceInfo_t)(FT_HANDLE ftHandle, FT_DEVICE
*lpftDevice, LPDWORD lpdwID, PCHAR SerialNumber, PCHAR Description, LPVOID
Dummy);
+typedef FT_STATUS (WINAPI *FT_Purge_t)(FT_HANDLE ftHandle, ULONG Mask);
+typedef FT_STATUS (WINAPI *FT_Close_t)(FT_HANDLE ftHandle);
+
+// library handle
+static HINSTANCE dynamic_library;
+
+// global pointers for read and write functions
+static FT_Write_t FT_Write_ptr;
+static FT_Read_t FT_Read_ptr;
+
+// replacements for original functions
+#define FT_Write (*FT_Write_ptr)
+#define FT_Read (*FT_Read_ptr)
+#define FT_OpenEx(*FT_OpenEx_ptr)
+#define FT_ListDevices (*FT_ListDevices_ptr)
+#define FT_SetLatencyTimer (*FT_SetLatencyTimer_ptr)
+#define FT_GetLatencyTimer (*FT_GetLatencyTimer_ptr)
+#define FT_SetTimeouts (*FT_SetTimeouts_ptr)
+#define FT_SetBitMode(*FT_SetBitMode_ptr)
+#define FT_GetDeviceInfo (*FT_GetDeviceInfo_ptr)
+#define FT_Purge (*FT_Purge_ptr)
+#define FT_Close (*FT_Close_ptr)
+
+#endif
+
/* max TCK for the high speed devices 3 kHz */
#define FTDI_2232H_4232H_MAX_TCK3
@@ -1803,6 +1848,78 @@
LOG_DEBUG('ft2232' interface using FTD2XX with '%s' layout
(%4.4x:%4.4x), ft2232_layout, vid, pid);
+#if FTD2XX_DYNAMIC == 1
+
+ FT_OpenEx_t FT_OpenEx_ptr;
+ FT_ListDevices_t FT_ListDevices_ptr;
+ FT_SetLatencyTimer_t FT_SetLatencyTimer_ptr;
+ FT_GetLatencyTimer_t FT_GetLatencyTimer_ptr;
+ FT_SetTimeouts_t FT_SetTimeouts_ptr;
+ FT_SetBitMode_t FT_SetBitMode_ptr;
+ FT_GetDeviceInfo_t FT_GetDeviceInfo_ptr;
+
+ dynamic_library = LoadLibrary(ftd2xx.dll);
+
+ if(dynamic_library == NULL)
+ {
+ LOG_ERROR(Can't open ftd2xx.dll);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+ else
+ {
+ BOOL fail = FALSE;
+
+ if((FT_Write_ptr = (FT_Write_t)GetProcAddress(dynamic_library,
FT_Write)) == NULL)
+ {
+ LOG_ERROR(Can't get FT_Write() function);
+ fail = TRUE;
+ }
+ if((FT_Read_ptr = (FT_Read_t)GetProcAddress(dynamic_library,
FT_Read)) == NULL)
+ {
+ LOG_ERROR(Can't get FT_Read() function);
+ fail = TRUE;
+ }
+ if((FT_OpenEx_ptr =
(FT_OpenEx_t)GetProcAddress(dynamic_library, FT_OpenEx)) == NULL)
+ {
+ LOG_ERROR(Can't get FT_OpenEx() function);
+ fail = TRUE;
+ }
+ if((FT_ListDevices_ptr =
(FT_ListDevices_t)GetProcAddress(dynamic_library, FT_ListDevices))
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On 27/06/2009, Freddie Chopin freddie_cho...@op.pl wrote: 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c 2. enable dynamic loading of libusb0.dll in ft2232.c So why loading libusb rather than libftdi? Is it because libftdi is only built (or linked to) as a static library on Windows but still needs the libusb DLL? 3. make it possible to have support for both libftdi and ftd2xx at the same time in ft2232.c n. enable dynamic loading for some other modules - jlink, rlink, presto n+1. make it possible to have support for both libftdi and ftd2xx at the same time in presto.c I can do the same for linux, but as I have no means for testing I'd rather pass that to someone else. With help in testing I can try to do that myself. Maybe it's worth trying something like GNU Libtool's libltdl which is a wrapper around dlopen (Linux), LoadLibrary (Windows) and apparently stranger things on other platforms as well. I guess you'd still have to hard code platform specific file names (ftd2xx.dll vs libftd2xx.so or similar) but it would get rid of most of the platform specific code. A disadvantage is the added complexity of yet another library to link to. There's a precompiled Windows libltdl3.dll, static library, ltdl.h etc available from gnu win32: http://gnuwin32.sourceforge.net/packages/libtool.htm ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] dynamic loading of ftd2xx.dll for windows in ft2232.c
On Sun, 2009-06-28 at 01:23 +, Martin Panter wrote: On 27/06/2009, Freddie Chopin freddie_cho...@op.pl wrote: 1. (this one) enable dynamic loading of ftd2xx.dll in ft2232.c 2. enable dynamic loading of libusb0.dll in ft2232.c So why loading libusb rather than libftdi? Is it because libftdi is only built (or linked to) as a static library on Windows but still needs the libusb DLL? 3. make it possible to have support for both libftdi and ftd2xx at the same time in ft2232.c n. enable dynamic loading for some other modules - jlink, rlink, presto n+1. make it possible to have support for both libftdi and ftd2xx at the same time in presto.c I can do the same for linux, but as I have no means for testing I'd rather pass that to someone else. With help in testing I can try to do that myself. Maybe it's worth trying something like GNU Libtool's libltdl which is a wrapper around dlopen (Linux), LoadLibrary (Windows) and apparently stranger things on other platforms as well. I guess you'd still have to hard code platform specific file names (ftd2xx.dll vs libftd2xx.so or similar) but it would get rid of most of the platform specific code. A disadvantage is the added complexity of yet another library to link to. I would also suggest using libltdl for these tasks; however, that should be a fairly easy change, after eliminating the existing redundancy. After thinking about this patch some more today, I have become confused about its motives. If the binary cannot be distributed with the FTD2XX driver in it, this patch does not help folks that must compile the code themselves anyway. You cannot have both libftdi and FTD2XX support in the same FT2232 driver binary, so this patch not even allowing testing them both using the same openocd binary (presumably by adding/removing the OS drivers between tests). The later suggestion shows that there could be some value of allowing dynamic loading like this, if you provided a second patch to fix the build system to produce both drivers. However, I think that such a patch will only be possible after adding more full dynamic loading for the JTAG interface drivers. Specifically, the proper place to use dynamic module loading will be to discover the jtag_interface structure from each OpenOCD driver module, adding the structure from each successfully loaded module to populate the interface list. With that, you no longer need this patch either, because the module will fail to load if its required libraries are missing. Personally, I think that I have failed to see the value of this patch, but maybe I have missed something. In contrast to the strategic solution, what problems does this current patch solve for OpenOCD users, today? Without a clear answer to this, I am not sure why we want it. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] simple refactor - target_state_name()
Replace common function call with simple refactorization. For example: OLD: LOG_DEBUG(target-state: %s, Jim_Nvp_value2name_simple(nvp_target_state, target-state)-name); NEW: LOG_DEBUG(target-state: %s, target_state_name(target)); -Duane. SVN Details === Author: duane Date: 2009-06-28 04:40:08 +0200 (Sun, 28 Jun 2009) New Revision: 2409 Modified: trunk/src/target/arm11.c trunk/src/target/arm7_9_common.c trunk/src/target/cortex_m3.c trunk/src/target/mips_m4k.c trunk/src/target/target.c trunk/src/target/target.h trunk/src/target/xscale.c Log: Refactor code, create target_state_name() ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn commit - - More details on GDB connect disconnect
== Author: duane Date: 2009-06-28 04:54:19 +0200 (Sun, 28 Jun 2009) New Revision: 2410 Example: Debug: 812 68734 gdb_server.c:823 gdb_connection_closed(): GDB Close, Target: sam3.cpu, state: halted, gdb_actual_connections=0 == Author: duane Date: 2009-06-28 05:09:15 +0200 (Sun, 28 Jun 2009) New Revision: 2411 Modified: trunk/src/target/target.c Log: Remove extra newline from debug log message (line 3400 - target.c) == -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
