Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem - SOLVED
Hi all, good news, I got my NS9360 working. So thanks for all the ideas and inputs, it helped a lot. The NS9360 has a BIST_EN bit. Unfortunately there is not much documentation about it in the spec. However, when set to low, the TAP controller detected seems to be the boundary scan register with the ID 0x9105031. When BIST_EN is set to high, the boundary scan register disappears and a TAP controller with the ID 0x07926031 is reported. And this one has a working EmbeddedICE and debugging is possible. The board configuration digi_connectcore_wi-9c.cfg worked fine for me. So it was just this single PIN after all. Best regards, Henry -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] jim-eventloop for MinGW-w64
Hi David, Looking further at the jim-eventloop issue, I found that jim.h already had provisions for the modifier to use with jim_wide #ifdef HAVE_LONG_LONG_INT # if defined(_MSC_VER) || defined(__MSVCRT__) #define JIM_WIDE_MODIFIER I64d # else #define JIM_WIDE_MODIFIER lld # endif #else #define JIM_WIDE_MODIFIER ld #endif It looks like everything was already in there to take care of the 32/64 bit issue. I'm therefore submitting a more satisfying patch that takes advantage of it, by adding a __MINGW32__ check in jim.h as well NB: __MINGW32__ should work on both w32 and w64, as per http://gmplib.org/list-archives/gmp-devel/2009-September/000963.html Regards, NIL: patch_jim-eventloop_mingw_w64.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb
Thanks for the pointers.
I'm slowly crawling my way to addressing the remaining MinGW-w64 poratbility
issues.
Neither -std=gnu99, -std=c99 or -D__USE_MINGW_ANSI_STDIO=1 seem to leave
MinGW happy with %lld co (even with the latest build on MinGW-w64), so I'm
pretty much resigned to patching the remaining files individually.
I see you posted some comments on the bug list as well. Hopefully a future
version of the compiler will address this.
Now, before I submit further patches, I would like to know if you are OK
with a patch that goes like this, to address some of the warnings I get with
size_t values:
size_t value;
...
printf(value = ZU \n, (unsigned) value);
The change would be to add a casting of a size_t to unsigned in printf.
I don't think it should break much of anything, since we're still telling
printf to expect a size_t, but without the unsigned cast, MinGW-w64 does not
accept it.
Also,
2009/10/15 David Brownell davi...@pacbell.net
Another thing to try: update the format specifiers in the
headers (src/helper/{command,log}.h) to say gnu_printf
instead of printf. Maybe that will work without changing
so much code for the %lld, %zd, and %jd issues.
This seems to address some of the issue indeed.
I'm planning to go with something like this:
#ifdef IS_MINGW
extern void log_printf(enum log_levels level, const char *file, int line,
const char *function, const char *format, ...)
__attribute__ ((format (gnu_printf, 5, 6)));
extern void log_printf_lf(enum log_levels level, const char *file, int line,
const char *function, const char *format, ...)
__attribute__ ((format (gnu_printf, 5, 6)));
#else
extern void log_printf(enum log_levels level, const char *file, int line,
const char *function, const char *format, ...)
__attribute__ ((format (printf, 5, 6)));
extern void log_printf_lf(enum log_levels level, const char *file, int line,
const char *function, const char *format, ...)
__attribute__ ((format (printf, 5, 6)));
#endif
Or do you reckon we should safely be able to use gnu_printf for all
platforms and remove the need for an ifdef?
Regards,
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] xscale_debug.S: Error: junk at end of line when using cygwin/mingw
On 2009-10-16, Redirect Slash NIL redirect.slash@gmail.com wrote: Any ideas how to fix that? My guess is you've you've got DOS line endings instead of Unix line endings. -- Grant ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] xscale_debug.S: Error: junk at end of line when using cygwin/mingw
Yes, that's the first thing I checked, as that's what google will tell you, but this is the latest unmodified version from git, and it's 0x0A all the way for line endings. Unless the compiler itself converts files to DOS on the fly, I don't think this is the issue here... That xscale_debug.S was only recently added to the git tree. Will have to wait to see if others report the same problem. 2009/10/16 Grant Edwards grant.b.edwa...@gmail.com On 2009-10-16, Redirect Slash NIL redirect.slash@gmail.com wrote: Any ideas how to fix that? My guess is you've you've got DOS line endings instead of Unix line endings. -- Grant ___ 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: 64 bit fixes for Windows x64 compilation using libftdi/libusb
2009/10/16 Redirect Slash NIL redirect.slash@gmail.com Now, before I submit further patches, I would like to know if you are OK with a patch that goes like this, to address some of the warnings I get with size_t values: size_t value; ... printf(value = ZU \n, (unsigned) value); Scratch that. I just saw the ZU definition in the arm11.h header. I will work with that. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb
I'm planning to go with something like this: #ifdef IS_MINGW extern void log_printf(enum log_levels level, const char *file, int line, const char *function, const char *format, ...) __attribute__ ((format (gnu_printf, 5, 6))); extern void log_printf_lf(enum log_levels level, const char *file, int line, const char *function, const char *format, ...) __attribute__ ((format (gnu_printf, 5, 6))); #else extern void log_printf(enum log_levels level, const char *file, int line, const char *function, const char *format, ...) __attribute__ ((format (printf, 5, 6))); extern void log_printf_lf(enum log_levels level, const char *file, int line, const char *function, const char *format, ...) __attribute__ ((format (printf, 5, 6))); #endif Or do you reckon we should safely be able to use gnu_printf for all platforms and remove the need for an ifdef? Scratch that one too. It seems using -D__USE_MINGW_ANSI_STDIO=1 with MinGW-w64 cancels the need to set gnu_printf. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On 15 Oct, 2009, at 06:39, David Brownell wrote: On Monday 28 September 2009, Brian Hutchinson wrote: I have a BeagleBoard now :) It was a good but busy week! Thanks for the report. ESC can be fun. TI didn't happen to have XDS100 v2 prototypes did they? http://wiki.davincidsp.com/index.php/XDS100 How does the Beagle board compare to TI's OMAP35x Evaluation Module (EVM) (with the 720 MHz OMAP3530 @ $ 1500)? I just came across the Beagle board yesterday, whilst looking for OMAP3530 chips from somewhere in Europe... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb
On Friday 16 October 2009, Redirect Slash NIL wrote: Or do you reckon we should safely be able to use gnu_printf for all platforms and remove the need for an ifdef? That's what I had in mind. Rule of thumb: #ifdef == bad. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On Friday 16 October 2009, Colin Howarth wrote: How does the Beagle board compare to TI's OMAP35x Evaluation Module (EVM) (with the 720 MHz OMAP3530 @ $ 1500)? I just came across the Beagle board yesterday, whilst looking for OMAP3530 chips from somewhere in Europe... The EVM is clearly a lot more capable in terms of extensibility and add-on hardware. Beagle is designed to be an ultra-low cost introduction to OMAP3, and to open up new developer communities (universities, even high schools) ... EVM is more in line with traditional TI handset development boards. (But if you need one of those ... get an SDP, or Zoom-II.) http://beagleboard.org/ http://www.mistralsolutions.com/products/omap_3evm.php So EVM has for example an LCD touchscreen and a keypad, plus an on-board Ethernet adapter, and Beagle doesn't. Likewise with video and camera inputs. EVM supports battery powered operation, including a charger and (I think) battery gauge. Re 720 MHz, that speed grade is kind of new ... Beagles might be upgraded to use it at some point. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jim-eventloop for MinGW-w64
How about MinGW-w64 portability patch for jim (embeddable Tcl interpreter) then? 2009/10/16 David Brownell davi...@pacbell.net On Friday 16 October 2009, you wrote: Hi David, Looking further at the jim-eventloop issue, I found that jim.h already had provisions for the modifier to use with jim_wide Good. Can you give a _real_ name for this patch? Pseudonyms are fine for general use, but in terms of patch and copyright attribution they don't quite have the same legal presence... - Dave #ifdef HAVE_LONG_LONG_INT # if defined(_MSC_VER) || defined(__MSVCRT__) #define JIM_WIDE_MODIFIER I64d # else #define JIM_WIDE_MODIFIER lld # endif #else #define JIM_WIDE_MODIFIER ld #endif It looks like everything was already in there to take care of the 32/64 bit issue. I'm therefore submitting a more satisfying patch that takes advantage of it, by adding a __MINGW32__ check in jim.h as well NB: __MINGW32__ should work on both w32 and w64, as per http://gmplib.org/list-archives/gmp-devel/2009-September/000963.html Regards, NIL: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On 16 Oct, 2009, at 19:01, David Brownell wrote: On Friday 16 October 2009, Colin Howarth wrote: How does the Beagle board compare to TI's OMAP35x Evaluation Module (EVM) (with the 720 MHz OMAP3530 @ $ 1500)? I just came across the Beagle board yesterday, whilst looking for OMAP3530 chips from somewhere in Europe... The EVM is clearly a lot more capable in terms of extensibility and add-on hardware. Beagle is designed to be an ultra-low cost introduction to OMAP3, and to open up new developer communities (universities, even high schools) ... Ah! There wasn't a price on the Arrow (or wherever) site. 150 $ is a much nicer price than $1500 :-) EVM is more in line with traditional TI handset development boards. (But if you need one of those ... get an SDP, or Zoom-II.) No, I'm a hobbyist. I had an Acorn Archimedes when it came out: 4 Mhz ARM2. Damn! It was fast! :-) http://beagleboard.org/ http://www.mistralsolutions.com/products/omap_3evm.php Thanks for the links. So EVM has for example an LCD touchscreen and a keypad, plus an on-board Ethernet adapter, and Beagle doesn't. Likewise with video and camera inputs. EVM supports battery powered operation, including a charger and (I think) battery gauge. Re 720 MHz, that speed grade is kind of new ... Beagles might be upgraded to use it at some point. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jim-eventloop for MinGW-w64
On Friday 16 October 2009, Redirect Slash NIL wrote: How about MinGW-w64 portability patch for jim (embeddable Tcl interpreter) then? I meant like something which might appear in any other legal document. Unless your legal name is really Redirect Slash NIL? 2009/10/16 David Brownell davi...@pacbell.net On Friday 16 October 2009, you wrote: Hi David, Looking further at the jim-eventloop issue, I found that jim.h already had provisions for the modifier to use with jim_wide Good. Can you give a _real_ name for this patch? Pseudonyms are fine for general use, but in terms of patch and copyright attribution they don't quite have the same legal presence... - Dave #ifdef HAVE_LONG_LONG_INT # if defined(_MSC_VER) || defined(__MSVCRT__) #define JIM_WIDE_MODIFIER I64d # else #define JIM_WIDE_MODIFIER lld # endif #else #define JIM_WIDE_MODIFIER ld #endif It looks like everything was already in there to take care of the 32/64 bit issue. I'm therefore submitting a more satisfying patch that takes advantage of it, by adding a __MINGW32__ check in jim.h as well NB: __MINGW32__ should work on both w32 and w64, as per http://gmplib.org/list-archives/gmp-devel/2009-September/000963.html Regards, NIL: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On Friday 16 October 2009, Colin Howarth wrote: No, I'm a hobbyist. I had an Acorn Archimedes when it came out: 4 Mhz ARM2. Damn! It was fast! :-) Somehow I suspect you're not going to submit OpenOCD support for ARM2 though. Sigh. ;) Beagle is a very nice little board. Enjoy! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin and libtool build problems
On Saturday 10 October 2009, David Brownell wrote: I was doing some test builds on Cygwin and seem to have reached an impasse. At least part of it looks to be related to libtool. See below. Will someone report good fixes? Partial answer found. These problems seem to have been caused by some other version of make getting picked up, from a MinGW based toolchain. It didn't quite work right. :( Remaining issue: libtool fails since it keeps trying to do something with a libpopt from /usr/lib, which it doesn't find. - Dave (1) options.c build failure. The GCC commands going into libtool look fine, but libtool mangles the PKGDATA declaration ... which breaks the build. -Dx=\value\ becomes -Dx=\\value\\ , and that's obviously utter garbage. C:/cygwin/bin/sh.exe ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/server -I../../src/target -DPKGDATADIR=\/usr/local/share/openocd\ -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libhelper_la-options.lo -MD -MP -MF .deps/libhelper_la-options.Tpo -c -o libhelper_la-options.lo `test -f 'options.c' || echo './'`options.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/server -I../../src/target -DPKGDATADIR=\\/usr/local/share/openocd\\ -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libhelper_la-options.lo -MD -MP -MF .deps/libhelper_la-options.Tpo -c options.c -o libhelper_la-options.o options.c: In function `add_default_dirs': options.c:106: error: stray '\' in program options.c:106: error: parse error before '/' token options.c:106: error: stray '\' in program options.c:107: error: stray '\' in program options.c:107: error: parse error before '/' token options.c:107: error: stray '\' in program make[3]: *** [libhelper_la-options.lo] Error 1 (2) openocd.c also fails; this time -DRELSTR=... is removed, PKGBLDDATE gets different mangling, and neither backquoted command gets executed. I suspect a partial fix for that one might be just to expand its value in some other way ... both shell invocations (date and guess-rev.sh) fail. Given the error above, that won't suffice... C:/cygwin/bin/sh.exe ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DPKGBLDDATE=\`date +%F-%R`\ -DRELSTR=\`../guess-rev.sh ..`\ -I../src -I../src/helper -I../src/jtag -I../src/target -I../src/xsvf -I../src/svf -I../src/server -I../src/flash -I../src/pld-g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libopenocd_la-openocd.lo -MD -MP -MF .deps/libopenocd_la-openocd.Tpo -c -o libopenocd_la-openocd.lo `test -f 'openocd.c' || echo './'`openocd.c /usr/bin/sh: \: command not found libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DPKGBLDDATE=\\\`date +%F-%R\\ -I../src -I../src/helper -I../src/jtag -I../src/target -I../src/xsvf -I../src/svf -I../src/server -I../src/flash -I../src/pld -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libopenocd_la-openocd.lo -MD -MP -MF .deps/libopenocd_la-openocd.Tpo -c openocd.c -o libopenocd_la-openocd.o gcc: +%F-%R\ -I../src: No such file or directory openocd.c: In function `handle_version_command': openocd.c:75: error: parse error before RELSTR openocd.c:75: error: stray '\' in program openocd.c:75: error: stray '`' in program openocd.c: In function `setup_command_handler': openocd.c:211: error: parse error before RELSTR openocd.c:211: error: stray '\' in program openocd.c:211: error: stray '`' in program make[3]: *** [libopenocd_la-openocd.lo] Error 1 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] xscale_debug.S: Error: junk at end of line when using cygwin/mingw
Try with current GIT. I checked in a patch that solves this problem a bit differently -- no ASM, no ELF. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] xscale: better fix for debug_handler.bin
Generate a C struct with the data, and use that, instead of an
assembly language file. The assembly language causes issues on
Darwin and MS-Windows, which don't necessarily use GNU AS; or
if they do, don't necessarily use its ELF syntax.
It's also better in two other ways: fewer global symbols; and
the init-time size check gets optimized away at compile time.
(Unless it fails, in which case bigger chunks of the file vanish.)
---
configure.in |1 -
src/helper/Makefile.am| 10 +++---
src/target/Makefile.am| 12 +++-
src/target/xscale.c | 15 +--
src/target/xscale.h |6 --
src/target/xscale_debug.S | 13 -
6 files changed, 27 insertions(+), 30 deletions(-)
--- a/configure.in
+++ b/configure.in
@@ -16,7 +16,6 @@ AC_LANG_C
AC_PROG_CC
AC_PROG_CC_C99
AM_PROG_CC_C_O
-AM_PROG_AS
AC_PROG_RANLIB
dnl disable checks for C++, Fortran and GNU Java Compiler
--- a/src/helper/Makefile.am
+++ b/src/helper/Makefile.am
@@ -52,12 +52,16 @@ noinst_HEADERS = \
startup.tcl \
bin2char.c
-bin2char$(EXEEXT_FOR_BUILD): bin2char.c
+BIN2C = bin2char$(EXEEXT_FOR_BUILD)
+
+BUILT_SOURCES = $(BIN2C)
+
+$(BIN2C): bin2char.c
${CC_FOR_BUILD} ${CFLAGS_FOR_BUILD} $(srcdir)/bin2char.c -o $@
# Convert .tcl to cfile
-startup_tcl.c: startup.tcl bin2char$(EXEEXT_FOR_BUILD)
- ./bin2char$(EXEEXT_FOR_BUILD) startup_tcl $(srcdir)/startup.tcl $@
+startup_tcl.c: startup.tcl $(BIN2C)
+ ./$(BIN2C) startup_tcl $(srcdir)/startup.tcl $@
# add startup_tcl.c to make clean list
CLEANFILES = startup_tcl.c bin2char$(EXEEXT_FOR_BUILD)
--- a/src/target/Makefile.am
+++ b/src/target/Makefile.am
@@ -10,11 +10,10 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/src/jtag \
-I$(top_srcdir)/src/xsvf
-# ideally this would be specific to xscale_debug.S ...
-libtarget_la_CCASFLAGS = \
- -Wa,-I$(top_srcdir)/src/target \
- $(AM_CCASFLAGS)
+BIN2C = $(top_srcdir)/src/helper/bin2char$(EXEEXT_FOR_BUILD)
+xscale_debug.h: $(BIN2C) xscale/debug_handler.bin
+ $(BIN2C) xscale/debug_handler.bin xscale_debug_handler
xscale_debug.h
METASOURCES = AUTO
noinst_LTLIBRARIES = libtarget.la
@@ -41,7 +40,6 @@ libtarget_la_SOURCES = \
feroceon.c \
etb.c \
xscale.c \
- xscale_debug.S \
arm_simulator.c \
image.c \
armv7m.c \
@@ -62,6 +60,9 @@ libtarget_la_SOURCES = \
mips_ejtag.c \
avrt.c
+BUILT_SOURCES = \
+ xscale_debug.h
+
noinst_HEADERS = \
target.h \
target_type.h \
@@ -85,6 +86,7 @@ noinst_HEADERS = \
arm926ejs.h \
etb.h \
xscale.h \
+ xscale_debug.h \
arm_simulator.h \
image.h \
armv7m.h \
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -69,6 +69,17 @@ static int xscale_unset_breakpoint(struc
static int xscale_read_trace(target_t *);
+/* This XScale debug handler is loaded into the processor's
+ * mini-ICache, which is 2K of code writable only via JTAG.
+ *
+ * FIXME the OpenOCD bin2char utility currently doesn't handle
+ * binary files cleanly. It's string oriented, and terminates them
+ * with a NUL character. Better would be to generate the constants
+ * and let other code decide names, scoping, and other housekeeping.
+ */
+static /* unsigned const char xscale_debug_handler[] = ... */
+#include xscale_debug.h
+
static char *const xscale_reg_list[] =
{
XSCALE_MAINID,/* 0 */
@@ -1594,7 +1605,7 @@ static int xscale_deassert_reset(target_
* force that, so writing new contents is reliable...
*/
address = xscale-handler_address;
- for (unsigned binary_size = xscale_debug_handler_size;
+ for (unsigned binary_size = sizeof xscale_debug_handler - 1;
binary_size 0;
binary_size -= buf_cnt, buffer += buf_cnt)
{
@@ -3030,7 +3041,7 @@ static int xscale_target_create(struct t
{
xscale_common_t *xscale;
- if (xscale_debug_handler_size 0x800) {
+ if (sizeof xscale_debug_handler - 1 0x800) {
LOG_ERROR(debug_handler.bin: larger than 2kb);
return ERROR_FAIL;
}
--- a/src/target/xscale.h
+++ b/src/target/xscale.h
@@ -170,10 +170,4 @@ enum
#define ERROR_XSCALE_NO_TRACE_DATA (-1500)
-/* This XScale debug handler is loaded into the processor's
- * mini-ICache, which is 2K of code writable only via JTAG.
- */
-extern const uint8_t xscale_debug_handler[];
-extern const uint32_t xscale_debug_handler_size;
-
#endif /* XSCALE_H */
--- a/src/target/xscale_debug.S
+++ /dev/null
@@ -1,13 +0,0 @@
- .section.rodata
-
- .align 4
- .global xscale_debug_handler
-xscale_debug_handler:
- .incbin xscale/debug_handler.bin
- .size xscale_debug_handler, . -
Re: [Openocd-development] ESC Boston report
On 16 Oct, 2009, at 20:29, David Brownell wrote: On Friday 16 October 2009, Colin Howarth wrote: No, I'm a hobbyist. I had an Acorn Archimedes when it came out: 4 Mhz ARM2. Damn! It was fast! :-) Somehow I suspect you're not going to submit OpenOCD support for ARM2 though. Sigh. ;) I don't think it has any TAPs :-) It's funny, but my Mac Pro has eight 2.66 GHz 64 bit cores, and another 240 1.5 GHz double precision FPU cores (used for CUDA), so that's getting on for half a teraflop, but I'm sure my 4 MHz ARM2 (and later, 25 Mhz ARM3) booted up its windowed RiscOS (with anti-aliased text/graphics) faster... *sigh* :-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jim-eventloop for MinGW-w64
2009/10/16 David Brownell davi...@pacbell.net I meant like something which might appear in any other legal document. Unless your legal name is really Redirect Slash NIL? This is gonna get OT quite fast, but do we really have to go with legal names? I don't want to sound like a prima donna here, but for privacy reasons, I'm quite happy with using an alias rather than my real name for anything that is meant to stay on the internet, and I would prefer keeping it that way. Now, if you just want more legally sounding name, I'm sure I can come up with something... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A little Git repo cleanup
I thought the large binaries were cleaned out already from openocd git already. We should definitely perfom this sort of cleanup *BEFORE* 0.3. The large binaries were afterwards committed to the zy1000 project. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] A little Git repo cleanup
I have a tree that removes those commits plus a few other bits of noise that crept in. Thing is, pushing it would NOT be enough to achieve the full cleanup. The existing clones would need some cleanup/updating... Do you have a description of your changes? Could you email me the repository directly. Don't want to dump 5mByte into the mailing list, but my mailbox won't mind! We should perform this cleanup before 0.3. It would be nice to review the cleanup and get the servers updated next week sometime. Review + a day's notice during the working week is called for here... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] xscale_debug.S: Error: junk at end of line when using cygwin/mingw
Try with current GIT. Much better! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] More MinGW GNU C99 printf compliance
This one is addressing the remaining warning issues when using %lld or %zu with MinGW. The purpose of this patch it to remove warnings when the -D__USE_MINGW_ANSI_STDIO flag is used in MinGW. This flag is intended to make MinGW more C99 compliant with regards to printfs, and should become the recommended way of compiling OpenOCD on MinGW platforms. Unlike what I thought earlier, I wasn't able to remove the need to patch helper/log.h and helper/command.h, so the change of __attribute__ ((format (printf, x, y))) to __attribute__ ((format (gnu_printf, x, y))) is part of the patch. The only other file that needs modification is /target/arm11.h as, with __USE_MINGW_ANSI_STDIO enabled, %zu becomes a valid modifier for size_t printout and should be used to prevent warnings on 64bit platforms. A couple of separate patches will follow for the 2 remaining Win64 issues. Regards patch_mingw_ansi_stdio.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
This fix addresses the cast warnings issued on MinGW-W64 when casting a long to HANDLER in replacement.c Also removes the need for a temporary variable. patch_long_to_handler_mingw_w64.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] AT91SAM9 NAND Flash Support
Hi list, Is there support in OpenOCD for AT91SAM9 NAND flash programming? If so, are there any config examples in the trunk? If not, any one working on it? // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] wsock32 MinGW-W64
This is the last in the series of fixes required for successful compilation of OpenOCD on MinGW-W64. With the previous patches applied, one should now be able to compile on MinGW-W64 through: ./configure --build=x86_64-w64-mingw32 CFLAGS=-D__USE_MINGW_ANSI_STDIO ... This fix addresses the requirement to use the ws2_32 library instead of wsock32 as the later doesn't exist on W64. Unfortunately, this requires detection of MinGW-W64 or MinGW-W32 during the autoconf phase. Rather than create a MinGW-W64 specific variable, I opted for the creation of a more generic IS_WIN64 one, as it could have its uses for other environments. Of course we could try to go even more generic with this patch, and set an IS_64BIT detection variable for all platforms rather than just the Windows ones. Regards NIL: patch_wsock32_mingw_w64.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] proc jtag_init {}
I tried to use jtag_init {} but it freezes my system (arm11).
openocd recognizes my jtag dongle but it does not show jtag chain.
If jtag_init {} is empty, openocd works. As soon as I put something
there (such as 'puts 'hello world') it freezes.
I am running at this revision:
commit 9aab763fa555f049f03a242114ade0d1978f4291
Author: Øyvind Harboe oyvind.har...@zylin.com
Date: Mon Oct 12 15:25:00 2009 +0200
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
