[Openocd-development] OpenOCD failed to find libftdi in /usr/local
On Mon, Feb 15, 2010 at 9:47 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Mon, Feb 15, 2010 at 9:36 AM, CeDeROM tomek.ce...@gmail.com wrote: Ah yes, OpenOCD's configure script can also assume using /usr/local/lib and /usr/local/include to search for libraries and header files - it would be nice, however if it don't the Port will make it automatically :-) Actually I consider this a bug of OpenOCD. /usr/local should be searched, even under Linux. So I just tested it under Linux, if I install libftdi to /usr/local (which is the default if you build from source), it will fail to build. I will tend to think this is a bug. mc...@ubuntu:~/Desktop/build/openocd/build$ ../git/openocd/configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --enable-parport --enable-dummy checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... none required checking for library containing dlopen... -ldl checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for arpa/inet.h... yes checking elf.h usability... yes checking elf.h presence... yes checking for elf.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for ifaddrs.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking for netinet/in.h... yes checking for netinet/tcp.h... yes checking pthread.h usability... yes
Re: [Openocd-development] [RFC, PATCH for 0.5] arm920t: data cache full support
same patch rebased as requested!
0001-step1.patch is Øyvind Harboe's patch rebased
0002-atm920t-cleanup-data-cache-handling.patch my patch for data cache support
From 06c2935ba15ae54d33612315ce3cbef3a2481c92 Mon Sep 17 00:00:00 2001
From: Marc Pignat marc.pig...@hevs.ch
Date: Tue, 16 Feb 2010 10:08:18 +0100
Subject: [PATCH 1/2] step1
---
src/target/arm920t.c | 64 +++---
1 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/src/target/arm920t.c b/src/target/arm920t.c
index 3b75ca9..0fbf031 100644
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -559,37 +559,73 @@ static int arm920t_write_phys_memory(struct target *target,
/** Writes a buffer, in the specified word size, with current MMU settings. */
-int arm920t_write_memory(struct target *target, uint32_t address, uint32_t size, uint32_t count, uint8_t *buffer)
+int arm920t_write_memory(struct target *target, uint32_t address,
+ uint32_t size, uint32_t count, uint8_t *buffer)
{
int retval;
+ struct arm920t_common *arm920t = target_to_arm920(target);
- if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
- return retval;
-
- /* This fn is used to write breakpoints, so we need to make sure
- * that the data cache is flushed and the instruction cache is
- * invalidated
- */
- if (((size == 4) || (size == 2)) (count == 1))
+ /* FIX this should be cleaned up and made much more general. The
+ * plan is to write up and test on arm920t specifically and
+ * then generalize and clean up afterwards. */
+ if (arm920t-armv4_5_mmu.mmu_enabled (count == 1) ((size==2) || (size==4)))
{
- struct arm920t_common *arm920t = target_to_arm920(target);
-
+ /* special case the handling of single word writes to bypass MMU
+ * to allow implementation of breakpoints in memory marked read only
+ * by MMU */
if (arm920t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled)
{
LOG_DEBUG(D-Cache enabled, flush and invalidate cache line);
- /* MCR p15,0,Rd,c7,c10,2 */
- retval = arm920t_write_cp15_interpreted(target, 0xee070f5e, 0x0, address);
+
+ /* flush and invalidate data cache
+ *
+ * MCR p15,0,Rd,c7,c14,2 - flush and invalidate cache line using virtual address
+ *
+ */
+ retval = arm920t_write_cp15_interpreted(target, 0xee070f5e, 0x0, address~0x3);
if (retval != ERROR_OK)
return retval;
}
- if (arm920t-armv4_5_mmu.armv4_5_cache.i_cache_enabled)
+ uint32_t pa;
+ retval = target-type-virt2phys(target, address, pa);
+ if (retval != ERROR_OK)
+ return retval;
+
+ /* write directly to physical memory bypassing any read only MMU bits, etc. */
+ retval = armv4_5_mmu_write_physical(target, arm920t-armv4_5_mmu, pa, size, count, buffer);
+ if (retval != ERROR_OK)
+ return retval;
+ } else
+ {
+ if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
+ return retval;
+ }
+
+ /* If ICache is enabled, we have to invalidate affected ICache lines
+ * the DCache is forced to write-through, so we don't have to clean it here
+ */
+ if (arm920t-armv4_5_mmu.armv4_5_cache.i_cache_enabled)
+ {
+ if (count = 1)
{
+ /* invalidate ICache single entry with MVA
+ * ee070f35 mcr 15, 0, r0, cr7, cr5, {1}
+ */
LOG_DEBUG(I-Cache enabled, invalidating affected I-Cache line);
retval = arm920t_write_cp15_interpreted(target, 0xee070f35, 0x0, address);
if (retval != ERROR_OK)
return retval;
}
+ else
+ {
+ /* invalidate ICache
+ * 8: ee070f15 mcr 15, 0, r0, cr7, cr5, {0}
+ * */
+ retval = arm920t_write_cp15_interpreted(target, 0xee070f15, 0x0, address);
+ if (retval != ERROR_OK)
+return retval;
+ }
}
return retval;
--
1.6.6.1
From 4d8ecb8f4ae1fbb5d199a211873fc5d2f8b767e9 Mon Sep 17 00:00:00 2001
From: Marc Pignat marc.pig...@hevs.ch
Date: Tue, 16 Feb 2010 17:56:40 +0100
Subject: [PATCH 2/2] atm920t : cleanup data cache handling
---
src/target/arm920t.c | 82 --
1 files changed, 66 insertions(+), 16 deletions(-)
diff --git a/src/target/arm920t.c b/src/target/arm920t.c
index 0fbf031..1d755cf 100644
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -563,6 +563,7 @@ int arm920t_write_memory(struct target *target, uint32_t address,
uint32_t size, uint32_t count, uint8_t *buffer)
{
int retval;
+ const uint32_t cache_mask = ~0x1f; /* cache line size : 32 byte */
struct arm920t_common *arm920t = target_to_arm920(target);
/* FIX this should be cleaned up and made much more general. The
@@ -573,24 +574,73 @@ int arm920t_write_memory(struct target *target, uint32_t address,
/* special case the handling of single word writes to bypass MMU
* to allow implementation of breakpoints in memory marked read only
* by MMU */
+ int type;
+ uint32_t cb;
+ int domain;
+ uint32_t ap;
+ uint32_t pa;
+
+ /*
+ * We need physical address and cb
+ */
+ pa =
Re: [Openocd-development] [bisected] Re: arm920t regression cache support
Hi all! On Wednesday 17 February 2010 00:10:43 David Brownell wrote: On Tuesday 16 February 2010, Øyvind Harboe wrote: ... But rather complicated, compared with using real flush ops (not via scanchain 15). Sure, I will the execute one instruction method today! Regards Marc ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD failed to find libftdi in /usr/local
On Wed, Feb 17, 2010 at 4:00 PM, Xiaofan Chen xiaof...@gmail.com wrote: Actually I consider this a bug of OpenOCD. /usr/local should be searched, even under Linux. So I just tested it under Linux, if I install libftdi to /usr/local (which is the default if you build from source), it will fail to build. I will tend to think this is a bug. Maybe it is not a real bug after all since there is a work-around to specify CFLAGS and LDFLAGS to get it built. mc...@ubuntu:~/Desktop/build/openocd/build$ CFLAGS=-I/usr/local/include/libftdi LDFLAGS=-L/usr/local/lib ../git/openocd/configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --enable-parport --enable-dummy checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... none required checking for library containing dlopen... -ldl checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for arpa/inet.h... yes checking elf.h usability... yes checking elf.h presence... yes checking for elf.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for ifaddrs.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking for netinet/in.h... yes checking for netinet/tcp.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strings.h... (cached) yes checking
Re: [Openocd-development] [RFC, PATCH for 0.5] arm920t: data cache full support
Does it work?
I've tried to clean up the patch a bit(I can't test this version, so you would
have to do that...).
If that nicer execute any instruction approach pans out then this patch
can be simplified...
--
Øyvind Harboe
Visit us at Embedded World, March 2nd-4th. IS2T's stand, HALL 10 - 118
http://www.zylin.com/events_embeddedworld.html
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 8d45f4ce38b5535df8a8c1967d352dfdeb3b Mon Sep 17 00:00:00 2001
From: Marc Pignat marc.pig...@hevs.ch
Date: Tue, 16 Feb 2010 10:08:18 +0100
Subject: [PATCH] atm920t : fix breakpoints and data cache handling
Breakpoints did not work because the data cache was not flushed
properly.
As a bonus add capability to write to memory marked as read only
by the MMU, which allows software breakpoints in such memory
regions.
---
src/target/arm920t.c | 120 +++---
1 files changed, 103 insertions(+), 17 deletions(-)
diff --git a/src/target/arm920t.c b/src/target/arm920t.c
index 3b75ca9..1d755cf 100644
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -559,34 +559,120 @@ static int arm920t_write_phys_memory(struct target *target,
/** Writes a buffer, in the specified word size, with current MMU settings. */
-int arm920t_write_memory(struct target *target, uint32_t address, uint32_t size, uint32_t count, uint8_t *buffer)
+int arm920t_write_memory(struct target *target, uint32_t address,
+ uint32_t size, uint32_t count, uint8_t *buffer)
{
int retval;
+ const uint32_t cache_mask = ~0x1f; /* cache line size : 32 byte */
+ struct arm920t_common *arm920t = target_to_arm920(target);
- if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
- return retval;
-
- /* This fn is used to write breakpoints, so we need to make sure
- * that the data cache is flushed and the instruction cache is
- * invalidated
- */
- if (((size == 4) || (size == 2)) (count == 1))
+ /* FIX this should be cleaned up and made much more general. The
+ * plan is to write up and test on arm920t specifically and
+ * then generalize and clean up afterwards. */
+ if (arm920t-armv4_5_mmu.mmu_enabled (count == 1) ((size==2) || (size==4)))
{
- struct arm920t_common *arm920t = target_to_arm920(target);
+ /* special case the handling of single word writes to bypass MMU
+ * to allow implementation of breakpoints in memory marked read only
+ * by MMU */
+ int type;
+ uint32_t cb;
+ int domain;
+ uint32_t ap;
+ uint32_t pa;
+
+ /*
+ * We need physical address and cb
+ */
+ pa = armv4_5_mmu_translate_va(target, arm920t-armv4_5_mmu, address, type, cb, domain, ap);
+ if (type == -1)
+ {
+ return pa;
+ }
if (arm920t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled)
{
- LOG_DEBUG(D-Cache enabled, flush and invalidate cache line);
- /* MCR p15,0,Rd,c7,c10,2 */
- retval = arm920t_write_cp15_interpreted(target, 0xee070f5e, 0x0, address);
- if (retval != ERROR_OK)
-return retval;
+ if (cb 0x1)
+ {
+LOG_DEBUG(D-Cache buffered, drain write buffer);
+/*
+ * Buffered ?
+ * Drain write buffer - MCR p15,0,Rd,c7,c10,4
+ */
+
+retval = arm920t_write_cp15_interpreted(target, 0xee070f9a, 0x0, 0);
+if (retval != ERROR_OK)
+ return retval;
+ }
+
+ if (cb == 0x3)
+ {
+/*
+ * Write back memory ? - clean cache
+ *
+ * There is no way for cleaning a data cache line using
+ * cp15 scan chain, so copy the full cache line from
+ * cache to physical memory.
+ */
+uint8_t data[32];
+
+LOG_DEBUG(D-Cache in 'write back' mode, flush cache line);
+
+retval = target_read_memory(target, address cache_mask, 1, sizeof(data), data[0]);
+if (retval != ERROR_OK)
+ return retval;
+
+retval = armv4_5_mmu_write_physical(target, arm920t-armv4_5_mmu, pa cache_mask, 1, sizeof(data), data[0]);
+if (retval != ERROR_OK)
+ return retval;
+ }
+
+ /* Cached ? */
+ if (cb 0x2)
+ {
+/*
+ * Cached ? - Invalidate data cache using MVA
+ *
+ * MCR p15,0,Rd,c7,c6,1
+ */
+LOG_DEBUG(D-Cache enabled, invalidate cache line);
+
+retval = arm920t_write_cp15_interpreted(target, 0xee070f36, 0x0, address cache_mask);
+if (retval != ERROR_OK)
+ return retval;
+ }
}
- if (arm920t-armv4_5_mmu.armv4_5_cache.i_cache_enabled)
+ /* write directly to physical memory bypassing any read only MMU bits, etc. */
+ retval = armv4_5_mmu_write_physical(target, arm920t-armv4_5_mmu, pa, size, count, buffer);
+ if (retval != ERROR_OK)
+ return retval;
+ } else
+ {
+ if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
+ return retval;
+ }
+
+ /* If ICache is enabled, we have to invalidate affected ICache lines
+ * the DCache is forced to write-through, so we don't have to clean it here
+ */
+ if
Re: [Openocd-development] FreeBSD status of 0.4.0-RC2 (was: FreeBSD status of 0.4.0-RC1)
On Mon, Feb 15, 2010 at 8:43 AM, Xiaofan Chen xiaof...@gmail.com wrote: I just want to use plain git if possible without using the port system. Yes it is possible now. I do not need to use the port system after all. [mc...@myfreebsd ~/Desktop/build/openocd/build]$ CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../openocd/configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --enable-dummy [mc...@myfreebsd ~/Desktop/build/openocd/build]$ CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ../openocd/configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --enable-dummy checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ../openocd/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i386-unknown-freebsd8.0 checking host system type... i386-unknown-freebsd8.0 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... no checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd8.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... no checking for library containing dlopen... none required checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for arpa/inet.h... yes checking elf.h usability... yes checking elf.h presence... yes checking for elf.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for ifaddrs.h... no checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking for netinet/in.h... yes checking for netinet/tcp.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strings.h... (cached) yes
Re: [Openocd-development] FreeBSD status of 0.4.0-RC2 (was: FreeBSD status of 0.4.0-RC1)
On Wed, Feb 17, 2010 at 4:35 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Mon, Feb 15, 2010 at 8:43 AM, Xiaofan Chen xiaof...@gmail.com wrote: I just want to use plain git if possible without using the port system. Yes it is possible now. I do not need to use the port system after all. The first run with EK-LM3S1968 seems to work. But J-Link does not seem to work. [mc...@myfreebsd ~/Desktop/build/openocd/luminary/lm3s1968]$ openocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.4.0-rc2-dev-6-gaa8db98 (2010-02-17-16:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 3000 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : clock speed 3000 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints ^C [mc...@myfreebsd ~/Desktop/build/openocd/luminary/lm3s1968]$ sudo openocd -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.4.0-rc2-dev-6-gaa8db98 (2010-02-17-16:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 3000 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0xde failed (-6) Error: J-Link command 0xdc failed (-6) Error: J-Link command 0x01 failed (-6) Error: J-Link command EMU_CMD_VERSION failed (-60) Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: J-Link setting speed failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Info : clock speed 3000 kHz Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: J-Link command 0xdc failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. -- 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] OpenOCD failed to find libftdi in /usr/local
On Wednesday 17 February 2010, Xiaofan Chen wrote: So I just tested it under Linux, if I install libftdi to /usr/local (which is the default if you build from source), it will fail to build. I will tend to think this is a bug. Maybe it is not a real bug after all since there is a work-around to specify CFLAGS and LDFLAGS to get it built. That's how it's installed on one of my machines. configure needs to be fed those flags ... otherwise openocd won't link. Configure it correctly ... and all is fine. (FWIW this is an older Ubuntu system, where I had to install a newer version of libftdi than apt-get would install.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC, PATCH for 0.5] arm920t: data cache full support
Take #2 using MCR macro
--
Øyvind Harboe
Visit us at Embedded World, March 2nd-4th. IS2T's stand, HALL 10 - 118
http://www.zylin.com/events_embeddedworld.html
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 56203a96b1208aae6fdf04ef6ba2f8d5837dd98b Mon Sep 17 00:00:00 2001
From: Marc Pignat marc.pig...@hevs.ch
Date: Tue, 16 Feb 2010 10:08:18 +0100
Subject: [PATCH] atm920t : fix breakpoints and data cache handling
Breakpoints did not work because the data cache was not flushed
properly.
As a bonus add capability to write to memory marked as read only
by the MMU, which allows software breakpoints in such memory
regions.
---
src/target/arm920t.c | 120 +++---
1 files changed, 103 insertions(+), 17 deletions(-)
diff --git a/src/target/arm920t.c b/src/target/arm920t.c
index 3b75ca9..7cc228d 100644
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -559,34 +559,120 @@ static int arm920t_write_phys_memory(struct target *target,
/** Writes a buffer, in the specified word size, with current MMU settings. */
-int arm920t_write_memory(struct target *target, uint32_t address, uint32_t size, uint32_t count, uint8_t *buffer)
+int arm920t_write_memory(struct target *target, uint32_t address,
+ uint32_t size, uint32_t count, uint8_t *buffer)
{
int retval;
+ const uint32_t cache_mask = ~0x1f; /* cache line size : 32 byte */
+ struct arm920t_common *arm920t = target_to_arm920(target);
- if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
- return retval;
-
- /* This fn is used to write breakpoints, so we need to make sure
- * that the data cache is flushed and the instruction cache is
- * invalidated
- */
- if (((size == 4) || (size == 2)) (count == 1))
+ /* FIX this should be cleaned up and made much more general. The
+ * plan is to write up and test on arm920t specifically and
+ * then generalize and clean up afterwards. */
+ if (arm920t-armv4_5_mmu.mmu_enabled (count == 1) ((size==2) || (size==4)))
{
- struct arm920t_common *arm920t = target_to_arm920(target);
+ /* special case the handling of single word writes to bypass MMU
+ * to allow implementation of breakpoints in memory marked read only
+ * by MMU */
+ int type;
+ uint32_t cb;
+ int domain;
+ uint32_t ap;
+ uint32_t pa;
+
+ /*
+ * We need physical address and cb
+ */
+ pa = armv4_5_mmu_translate_va(target, arm920t-armv4_5_mmu, address, type, cb, domain, ap);
+ if (type == -1)
+ {
+ return pa;
+ }
if (arm920t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled)
{
- LOG_DEBUG(D-Cache enabled, flush and invalidate cache line);
- /* MCR p15,0,Rd,c7,c10,2 */
- retval = arm920t_write_cp15_interpreted(target, 0xee070f5e, 0x0, address);
- if (retval != ERROR_OK)
-return retval;
+ if (cb 0x1)
+ {
+LOG_DEBUG(D-Cache buffered, drain write buffer);
+/*
+ * Buffered ?
+ * Drain write buffer - MCR p15,0,Rd,c7,c10,4
+ */
+
+retval = arm920t_write_cp15_interpreted(target, ARMV4_5_MCR(15, 0, 0, 7, 10, 4), 0x0, 0);
+if (retval != ERROR_OK)
+ return retval;
+ }
+
+ if (cb == 0x3)
+ {
+/*
+ * Write back memory ? - clean cache
+ *
+ * There is no way for cleaning a data cache line using
+ * cp15 scan chain, so copy the full cache line from
+ * cache to physical memory.
+ */
+uint8_t data[32];
+
+LOG_DEBUG(D-Cache in 'write back' mode, flush cache line);
+
+retval = target_read_memory(target, address cache_mask, 1, sizeof(data), data[0]);
+if (retval != ERROR_OK)
+ return retval;
+
+retval = armv4_5_mmu_write_physical(target, arm920t-armv4_5_mmu, pa cache_mask, 1, sizeof(data), data[0]);
+if (retval != ERROR_OK)
+ return retval;
+ }
+
+ /* Cached ? */
+ if (cb 0x2)
+ {
+/*
+ * Cached ? - Invalidate data cache using MVA
+ *
+ * MCR p15,0,Rd,c7,c6,1
+ */
+LOG_DEBUG(D-Cache enabled, invalidate cache line);
+
+retval = arm920t_write_cp15_interpreted(target, ARMV4_5_MCR(15, 0, 0, 7, 6, 1), 0x0, address cache_mask);
+if (retval != ERROR_OK)
+ return retval;
+ }
}
- if (arm920t-armv4_5_mmu.armv4_5_cache.i_cache_enabled)
+ /* write directly to physical memory bypassing any read only MMU bits, etc. */
+ retval = armv4_5_mmu_write_physical(target, arm920t-armv4_5_mmu, pa, size, count, buffer);
+ if (retval != ERROR_OK)
+ return retval;
+ } else
+ {
+ if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
+ return retval;
+ }
+
+ /* If ICache is enabled, we have to invalidate affected ICache lines
+ * the DCache is forced to write-through, so we don't have to clean it here
+ */
+ if (arm920t-armv4_5_mmu.armv4_5_cache.i_cache_enabled)
+ {
+ if (count = 1)
{
+ /* invalidate ICache single entry with MVA
+ * ee070f35 mcr 15, 0,
Re: [Openocd-development] OpenOCD failed to find libftdi in /usr/local
On Wed, Feb 17, 2010 at 4:47 PM, David Brownell davi...@pacbell.net wrote: Maybe it is not a real bug after all since there is a work-around to specify CFLAGS and LDFLAGS to get it built. That's how it's installed on one of my machines. configure needs to be fed those flags ... otherwise openocd won't link. Configure it correctly ... and all is fine. (FWIW this is an older Ubuntu system, where I had to install a newer version of libftdi than apt-get would install.) Before using CFLAGS and LDFLAGS, I just remove the system libftdi and then use -prefix=/usr when building libftdi. Still I tend to think that /usr/local/include and /usr/local/lib should be searched as well, even with higher priority that /usr/include and /usr/lib. But I am not sure if this is a normal practice. -- 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] FreeBSD status of 0.4.0-RC2 (was: FreeBSD status of 0.4.0-RC1)
On Wed, Feb 17, 2010 at 4:41 PM, Xiaofan Chen xiaof...@gmail.com wrote: The first run with EK-LM3S1968 seems to work. But J-Link does not seem to work. J-Link V3 (black, IAR OEM) does not seem to work at all under FreeBSD. [mc...@myfreebsd /usr/home/mcuee/Desktop/build/openocd/luminary/lm3s1968]$ openocd -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.4.0-rc2-dev-6-gaa8db98 (2010-02-17-16:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 600 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : J-Link initialization started / target CPU reset initiated Error: J-Link command 0xde failed (-6) Error: J-Link command 0xdc failed (-6) Error: J-Link command 0x01 failed (-6) Error: J-Link command EMU_CMD_VERSION failed (-60) Info : J-Link JTAG Interface ready Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: J-Link setting speed failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Info : clock speed 600 kHz Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: J-Link command 0xdc failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Error: J-Link command 0xdd failed (-6) Error: J-Link command 0xdf failed (-6) Error: usb_bulk_write failed (requested=6, result=-6) Error: jlink_tap_execute, wrong result -107 (expected 1) Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. ^C J-Link V7 (black, ADI OEM-- mIDAS-Link) seems to work. [mc...@myfreebsd /usr/home/mcuee/Desktop/build/openocd/luminary/lm3s1968]$ openocd -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.4.0-rc2-dev-6-gaa8db98 (2010-02-17-16:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 600 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V7 compiled Jun 30 2009 11:05:27 Info : JLink caps 0xb9ff7bbf Info : JLink hw version 7 Info : JLink max mem block 9152 Info : Vref = 3.196 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 600 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints -- 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] FreeBSD status of 0.4.0-RC2 (was: FreeBSD status of 0.4.0-RC1)
On Wed, Feb 17, 2010 at 8:33 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Feb 17, 2010 at 4:41 PM, Xiaofan Chen xiaof...@gmail.com wrote: The first run with EK-LM3S1968 seems to work. But J-Link does not seem to work. J-Link V3 (black, IAR OEM) does not seem to work at all under FreeBSD. J-Link V7 (black, ADI OEM-- mIDAS-Link) seems to work. I guess I need some time to fix my FreeBSD installation due to the massive JPEG 8 library upgrade. Now many programs do not work. I just delete many packages (from mplayer to piklab/pikdev, from KDE3/KDE4 to LXDE, from evince to eog) to cut down the update time but I think it will take quite some time to update all the ports related to libjpeg. The famous error is like this. /libexec/ld-elf.so.1: Shared object libjpeg.so.10 not found, required by x http://forums.freebsd.org/showthread.php?t=11187 Luckily gnome and firefox still work so I can type this reply. So my experiment with FreeBSD and OpenOCD will stop for a while due to this port system. Even worse, it is not even mentioned in the UPDATING file. http://www.mail-archive.com/freebsd-po...@freebsd.org/msg25467.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] FreeBSD status of 0.4.0-RC2 (was: FreeBSD status of 0.4.0-RC1)
On Thu, Feb 18, 2010 at 5:23 AM, CeDeROM tomek.ce...@gmail.com wrote: Ah, there were reports from Australia even for 0.2.0 that this JLink does not work on FreeBSD, but the patch is provided - please take a look at patch for current openocd port (/usr/ports/devel/openocd/files) and try to (somehow) apply this patch with current 0.4.0-RC2. Unfortunately I dont have this JLink interface so I cannot perform this task :-( I see. Thanks. I will look into this. ps/2: Does anybody know how to reply to a message hidden in a plaintext-digest as in this situation? ;P Hmm, I thought you were not using the digest. It is a bad idea to use the digest format when you become a regular of the list. -- 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] FYI -- SWD work
Le 17/02/2010 15:59, CeDeROM a écrit : Partially - the Primer1 use RLink in JTAG mode, Primer2 use RLink in SWD mode. I am planning to work on SWD support soon (probably start/mid march) - I have even downloaded some documentation few days ago :-) I have a question on RLink. I have a RLINK-ST which I use for µPSD devices. Is this one supported by OpenOCD? It comes with a 14 pins JTAG connector. 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
Re: [Openocd-development] FYI -- SWD work
On Tue, Feb 16, 2010 at 8:10 AM, David Brownell davi...@pacbell.net wrote: Then the other stuff will be more focussed specifically on SWD low level stuff. I figure that'll be the easiest place for other folk to help out with code ... new driver support, in particular, but also testing and all that. I believe newer version of J-Link support SWD as well (V6 and later?). It seems to me you can choose to use SWD or JTAG in IAR EWARM. http://www.segger.com/cms/jlink.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] FYI -- SWD work
Le 17/02/2010 22:18, Xiaofan Chen a écrit : On Tue, Feb 16, 2010 at 8:10 AM, David Brownelldavi...@pacbell.net wrote: Then the other stuff will be more focussed specifically on SWD low level stuff. I figure that'll be the easiest place for other folk to help out with code ... new driver support, in particular, but also testing and all that. I believe newer version of J-Link support SWD as well (V6 and later?). It seems to me you can choose to use SWD or JTAG in IAR EWARM. http://www.segger.com/cms/jlink.html This is correct. I used it on my STM32 marine device. All the new device that we bought from IAR in the past year are like that. 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] OpenOCD auto-config
Just starting to write a wrapper to auto-config openocd. Using python, it's a class that attempts to wrap openocd configuration. So far it doesn't do much, but I would appreciate any comments anyone has. Go ahead and run it on your machines (only Linux supported ATM) as it doesn't write to any files except /dev/null. Be sure to edit the top to locate openocd correctly (Right now, it assumes /usr/local). I'll comment it tomorrow when I'm less brain- fried. Enjoy, - Alex Austin openocd.py Description: openocd.py ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD auto-config
Why do you prefer writing this *outside* OpenOCD, rather than *inside* using tcl? -- Øyvind Harboe Visit us at Embedded World, March 2nd-4th. IS2T's stand, HALL 10 - 118 http://www.zylin.com/events_embeddedworld.html US toll free 1-866-980-3434 / International +47 51 63 25 00 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
