Re: [Openocd-development] Relase 0.4.0 is out ... 0.5.0-dev started
On Wed, 24 Feb 2010, David Brownell wrote: More like: the nested lists structure of the NEWS file got mangled on its way through WordPress. The several bullets after the trailing ARM11 should have nested under an ARM11 heading ... similarly with Cortex-A8. Things look much better for the Target Layer now. However all the other sections (especially Flash Layer and Board, Target, and Interface Configuration Scripts) still look awkward. Me, I'm happier to just edit HTML directly, and not argue with (not-really-)smart editors that Do The Wrong Thing. I know the feeling. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Relase 0.4.0 is out ... 0.5.0-dev started
On Sun, 21 Feb 2010, David Brownell wrote: Archives are in the Berlios and SourceForge files areas. The berlios web page shows the highlights strangely in some cases: - basic semihosting support (ARM7/ARM9 only, for now) ARM11 - Should act much more like other ARM cores: [...] - Shares some core debug code with Cortex-A8 Cortex-A8 - Should act much more like other ARM cores: [...] Looks like there is a spurious ARM11 and Cortex-A8 there. Nicolas Mainline git is now tagged as 0.5.0-dev; the merge window is open. If we need a bugfix release, it'll branch off from the commit with the 0.4.0 tag. I've committed a few patches from my pending queue, most notably: - Making the ARMv7m stuff use struct arm so that the Cortex-M semihosting support can use most of the existing semihosting code (except for the small bit which will need to know it's using a different entry mechanism - The cleanup portion of the ADIv5 work, which will help with the SWD support. (Sanity checked on both M3 and A8 Cortex cores.) We're not sure who will be release manager for 0.5.0 ... but we do know it's someone else's turn!! If we keep to the kind of schedule we've had so far, one might anticipate this release ships no sooner than the end of April. I'm not sure what else will be merging soon. There are some feature patches which have been posted to the list, and held until the 0.5 window. And Spen has a bunch of performance work upcoming too (not all for MIPS, ISTR). Clearly we want to see major progress on SWD during this release cycle ... but it's not ready yet, and I'm not sure what other stuff will be happening. I guess this means 0.5.0 will surprise us all! :) - Dave ___ 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] build: fix problems with struct stat not being defined under eCos
On Mon, 1 Feb 2010, Øyvind Harboe wrote: On Mon, Feb 1, 2010 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Øyvind Harboe wrote: should this include not be going in helper/system.h ? I generally try to avoid include everything everywhere... so I think it is nice that it goes into that one .c file. I thought that the whole idea of creating the system.h is to stop including system headers in the main openocd source. Sounds like two noble and very slightly conflicting goals... In such case, only one of those noble goals should be pursued, not a mixup of both, or the nobility is lost. At the moment it seems that the system.h solution is way more prevalent. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] bug with semihosting SYS_READ fixed
FYI, I just pushed the following:
commit 3d2d5dcc9c27b84dc2e5e9ed53be0f784a450042
Author: Nicolas Pitre n...@fluxnic.net
Date: Tue Feb 2 00:05:42 2010 -0500
ARM semihosting: fix EOF handling with SYS_READ
The semihosting interface has a strange convention for read/write where
the unused amount of buffer must be returned. We failed to return the
total buffer size when the local read() call returned 0.
Signed-off-by: Nicolas Pitre n...@marvell.com
diff --git a/src/target/arm_semihosting.c b/src/target/arm_semihosting.c
index c41c5a0..9b853d9 100644
--- a/src/target/arm_semihosting.c
+++ b/src/target/arm_semihosting.c
@@ -190,7 +190,7 @@ static int do_semihosting(struct target *target)
} else {
result = read(fd, buf, l);
armv4_5-semihosting_errno = errno;
- if (result 0) {
+ if (result = 0) {
retval = target_write_buffer(target, a,
result, buf);
if (retval != ERROR_OK) {
free(buf);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] ARM semihosting: win32 and cygwin fixes
On Wed, 27 Jan 2010, Spencer Oliver wrote:
Cygwin would fail to reopen a previously written file if the mode is
not given.
What do you mean?
Simplified converting the open flags and made sure the win32 O_BINARY
bit is set.
ACK.
Added define for systems that do not support O_BINARY.
ACK.
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
You fail to mention this though:
if (strcmp((char *)fn, :tt) == 0) {
- if ((mode 3) == 0)
- result = dup(0);
+ if (m 4)
+ result = STDIN_FILENO;
else
- result = dup(1);
+ result = STDOUT_FILENO;
Why are you removing the dup()?
The remote application does open stdin/stdout explicitly, and may well
close them explicitly as well. It is therefore a bad idea to pass our
own stdin/stdout straight to the remote application.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ARM semihosting: add armv7m support
On Tue, 26 Jan 2010, Spencer Oliver wrote: David Brownell wrote: On Tuesday 26 January 2010, Spencer Oliver wrote: I could not get the original implementation from Nicolas Pitr working when outputting to stdout. For the record: I did get that working with an ARM9, no changes, using the latest CodeSourcery EABI toolchain. strange, i tested on arm9 aswell. fileio was ok, just printf to stdout/stderr failed. It is used in production settings here, so if it didn't work on ARM9 I would have fixed it long ago. ;-) The only moderately surprising behavior was seeing the output mixed with server logging stuff, without any particular fanfare ... I had expected to see it with the telnet console I was using at the time. (Didn't try it with GDB.) I went for the easiest setup. Typically this is used with applications on the target that don't need debugging but only a communication channel. Here openocd is fired up with a script that loads the application on the target and the application starts talking to you right away on the same console without having to telnet anywhere (works fine with pipes and redirects, such as through interaction with a chat script). Of course when the remote application calls out to gets() when asking user input then openocd is completely stalled by the synchronous read() on the local stdin, which means this doesn't interact well with gdb nor the telnet session in that case of course. The fix might require quite significant rearchitecturing of openocd. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ARM semihosting: add armv7m support
On Tue, 26 Jan 2010, David Brownell wrote: On Tuesday 26 January 2010, Nicolas Pitre wrote: For the record: I did get that working with an ARM9, no changes, using the latest CodeSourcery EABI toolchain. strange, i tested on arm9 aswell. fileio was ok, just printf to stdout/stderr failed. It is used in production settings here, so if it didn't work on ARM9 I would have fixed it long ago. ;-) Comments on any other parts of Spen's patches? Not the changes to make v7M work, but the other semihosting changes. When do_semihosting() returns with an error, the caller should return right away with 1 as the original code did and not 0 like the patch does. Also I don't like the fact that the introduced arm_semi_hosting structure (which could have been done in a patch of its own btw) is carrying fields that are valid only for one particular instance of a semihosting call and therefore should have been kept local to the implementation rather than growing the arm structure uselessly. Those are result and core_cache. I think that getting r0 and r1 should be abstracted out of do_semihosting() and passed directly by both callers instead, etc. Finally the fix for FLEN could be split in a patch of its own too as this is clearly an orthogonal issue. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ARM semihosting: add armv7m support
On Tue, 26 Jan 2010, David Brownell wrote: On Tuesday 26 January 2010, Nicolas Pitre wrote: Finally the fix for FLEN could be split in a patch of its own too as this is clearly an orthogonal issue. If you agree this is a bug, then it should get fixed before the 0.4 code freezes ... If things don't work for someone then this is indeed a bug. I just don't experience it and neither my Windows afflicted colleagues. I'm glad to see a bit more testing of the semihosting code before it gets into a release! :) Indeed. I wrote the code so it obviously just works for me(TM). Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ARM semihosting: add armv7m support
On Wed, 27 Jan 2010, Spencer Oliver wrote: When do_semihosting() returns with an error, the caller should return right away with 1 as the original code did and not 0 like the patch does. I am confused as the code in git master is: if ((*retval = do_semihosting(target, arm-semi_hosting_info)) != ERROR_OK) return 0; this codepath has not changed. Where is that? My repository is currently at: 33fc60b SVF: all content between parentheses is one parameter and the code that your patch changed is still: *retval = do_semihosting(target); return 1; at the very end of arm_semihosting(). Nicolas Also I don't like the fact that the introduced arm_semi_hosting structure (which could have been done in a patch of its own btw) is carrying fields that are valid only for one particular instance of a semihosting call and therefore should have been kept local to the implementation rather than growing the arm structure uselessly. Those are result and core_cache. I think that getting r0 and r1 should be abstracted out of do_semihosting() and passed directly by both callers instead, etc. it is wip, and so can be cleaned up quite a bit. Sure, hence my comments. But David apparently has a better solution in mind. Finally the fix for FLEN could be split in a patch of its own too as this is clearly an orthogonal issue. this can be done no problem. Thanks. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New object-orientated C++ architecture for OpenOCD?
On Wed, 9 Dec 2009, Pieter Conradie wrote: I get the impression that you (the developers) are butting your head against the limitations of C. What limitations? I never considered the C language to bare any limitations what so ever. You can do much more in C, and with way more control and performance, than with most other languages. The inconvenient is that C requires better programming skills. And C is amenable to object oriented programming just fine. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New object-orientated C++ architecture for OpenOCD?
On Wed, 9 Dec 2009, Freddie Chopin wrote: Nicolas Pitre pisze: What limitations? I never considered the C language to bare any limitations what so ever. You can do much more in C, and with way more control and performance, than with most other languages. The inconvenient is that C requires better programming skills. And C is amenable to object oriented programming just fine. Now replace C with assembler - this will still be perfectly true, but are there any sane ppl who write software for PC in assembly? Assembler is not portable while C is. And my focus when writing code is rarely restricted to PCs. And C is still more portable than C++ by far. So saying that C is limited is just B/S. Why everyone sees only the bad sides of C++ and completely forgets the good ones? Templates? Stronger compilation-time-error-checks? Easier error handling? Easier abstraction? Easier polymorphism? Easier - well - everything? Probably because the bad sides of C++ are just too easy to run into. Personally, I don't see the bad sides of C++. I simply don't care about C++ at all as I don't need it. And incidentally I don't see the need for C++ for OpenOCD either. But this is Open Source and anyone who feels differently can fork the code and make it fully C++. As far as my own contributions go, they will be directed to the C version only. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] commit 81aec6be list number of HW breakpoints/watchpoints
This commit adds in src/target/embeddedice.c a plain LOG_INFO(%s: hardware has 2 breakpoints or watchpoints, ... This is wrong for Feroceon and Dragonite which have only one of them. In that case arm7_9-wp_available_max is initialized to 1 in the target_create method, but the above message is still wrong and misleading. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] commit 81aec6be list number of HW breakpoints/watchpoints
On Wed, 9 Dec 2009, David Brownell wrote: On Wednesday 09 December 2009, Nicolas Pitre wrote: This is wrong for Feroceon and Dragonite which have only one of them. In that case arm7_9-wp_available_max is initialized to 1 in the target_create method, but the above message is still wrong and misleading. OK, got patch? :) Actually I'm still wondering where to move that LOG_INFO(). I guess that's another way that module isn't exactly the same as the EmbeddedICE(-RT) modules from ARM. Look at the notes at the top of feroceon.c for a quick list. And my official statement is: no comment. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] ARM: move opcode macros to target/arm_opcodes.h
On Mon, 7 Dec 2009, David Brownell wrote: Move the ARM opcode macros from target/armv4_5.h, and a few Thumb2 ones from target/armv7m.h, to more appropriate homes in a new target/arm_opcodes.h file. What about changing the names of a couple of those macros as well? Say ARMV4_5_STMIA(). This isn't an instruction for ARMv4 or ARMv5 only. I think all ARM architecture version always had them. I can understand the logic to add the architecture level from which an instructionwas introduced e.g. ARMV5_BKPT(). But all ARMV4_5_* are rather misleading. Tightening up some of the line lengths turned up a curious artifact: the macros for the Thumb opcodes are all 32 bits wide, not 16 bits. There's currently no explanation for why it's done that way... When pushing instruction in the CPU pipeline through scan chain 1 on an ARM9TDMI (or compatible) CPU core, you need to use 32 bits for the instruction field. If in Thumb mode, the 16-bit Thumb instructions have to be duplicated on both 16-bit nibbles of the 32-bit field. From Section B.7 Determining the core and system state of ARM9E-S Core Technical Reference Manual (DDI0240A.pdf): | Note | | Because all Thumb instructions are only 16 bits long, the simplest | method, when shifting scan chain 1, is to repeat the instruction. For | example, the encoding for BX R0 is 0x4700, so when 0x47004700 shifts | into scan chain 1, the debugger does not have to keep track of the half | of the bus on which the processor expects to read the data. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] ARM: semihosting entry cleanup
On Fri, 4 Dec 2009, David Brownell wrote: Clean up arm_semihosting() entry a bit, comment some issues and just which SVC opcodes are getting intercepted. Microcontroller profile cores will need a new entry, since they don't use SVC there (or even have an SVC mode). In that case they use BKPT 0xAB instead of SVC 0xAB. And the microcontroller profile has only thumb2 mode so no need to bother with (the non existing) spsr. - struct arm *armv4_5 = target_to_armv4_5(target); + struct arm *arm = target_to_armv4_5(target); Wouldn't it be time to s/target_to_armv4_5/target_to_arm/ everywhere? + /* Check for PC == 8: Supervisor Call vector + * REVISIT: assumes low exception vectors, not hivecs... + * safer to test was this entry from a vector catch. + */ There is no universal vector catch facility. Some targets might have to use a breakpoint instead. And hardware breakpoints are precious resources i.e. Feroceon/Dragonite have only one of those already involved in single-step support for example. So software breakpoints are preferable when there is no vector catch. But yet some targets have the vectors in ROM (or flash) pointing to a jump table located in RAM. In that case the breakpoint has to be placed in the jump table instead. So there is more to it than just 0x08 or 0x0008. This is why the enabling of semihosting is really architecture dependent. + /* Core-specific code should make sure SPSR is retrieved + * when the above checks pass... + */ + if (!arm-spsr-valid) + LOG_WARNING(SPSR not valid!); Better return an error and stop rather than continuing with wrong information in that case. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] ARM semihosting: work with both low and high vectors
Signed-off-by: Nicolas Pitre n...@marvell.com
---
src/target/arm_semihosting.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/target/arm_semihosting.c b/src/target/arm_semihosting.c
index 39625f6..d448d54 100644
--- a/src/target/arm_semihosting.c
+++ b/src/target/arm_semihosting.c
@@ -414,18 +414,16 @@ static int do_semihosting(struct target *target)
int arm_semihosting(struct target *target, int *retval)
{
struct arm *arm = target_to_arm(target);
- uint32_t lr, spsr;
+ uint32_t pc, lr, spsr;
struct reg *r;
if (!arm-is_semihosting || arm-core_mode != ARM_MODE_SVC)
return 0;
- /* Check for PC == 8: Supervisor Call vector
-* REVISIT: assumes low exception vectors, not hivecs...
-* safer to test was this entry from a vector catch.
-*/
+ /* Check for PC == 0x0008 or 0x0008: Supervisor Call vector. */
r = arm-core_cache-reg_list + 15;
- if (buf_get_u32(r-value, 0, 32) != 0x08)
+ pc = buf_get_u32(r-value, 0, 32);
+ if (pc != 0x0008 pc != 0x0008)
return 0;
r = arm_reg_current(arm, 14);
--
1.6.6.rc0.314.gc4469
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] basic ARM semihosting support
On Thu, 3 Dec 2009, Zach Welch wrote: On Thu, 2009-12-03 at 10:39 +0100, Øyvind Harboe wrote: I added a missing #include sys/stat.h, but it is not quite ready to commit yet I think. Does it build under Windows? Perhaps it does, I didn't try. I don't think we should try to make this work under anything but POSIX API for now, but the build should not fail. Autotools magic? Some docs to openocd.texi would be great. Okay, one more nit to pick from me too: use a static function to encapsulate the hunk of new code that's being added 4-tabs to the wind. Please, I beg you :) I know... My problem initially is that I had 3 cases: return error right away, return success right away, or fall through the code that follows. This was akward to express with a single return value so I just left the code inline and didn't revisit it. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] basic ARM semihosting support
On Thu, 3 Dec 2009, Øyvind Harboe wrote: I added a missing #include sys/stat.h, but it is not quite ready to commit yet I think. Does it build under Windows? Perhaps it does, I didn't try. It probably does. We maintain both a Linux and Windows build internally and I didn't get any complaint yet. I don't think we should try to make this work under anything but POSIX API for now, but the build should not fail. Autotools magic? It might even just work, at least under Cygwin. The way to make it more portable is to stick to stdio calls. Problem with that is that fopen() and friends are using FILE* pointers which can't be passed directly (think of 64-bit hosts). So a mapping table would have to be maintained, etc. That might be the way to go anyway for added security, but I was not that motivated, at least for a first shot at it. And this code as is fulfills my need already. Some docs to openocd.texi would be great. It sure would. ;-) Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] basic ARM semihosting support
On Thu, 3 Dec 2009, Igor Skochinsky wrote: Hello Nicolas, Thursday, December 3, 2009, 7:58:05 AM, you wrote: NP Semihosting enables code running on an ARM target to use the I/O NP facilities on the host computer. The target application must be linked NP against a library that forwards operation requests by using the SVC NP instruction that is trapped at the SWI vector by the debugger. The hosted NP library version provided with CodeSourcery's Sourcery G++ Lite for ARM EABI NP is one example. NP This is currently available for ARM9 processors, but any ARM variant should NP be able to support this with little additional work. GDB protocol has support for target syscalls: http://sourceware.org/gdb/download/onlinedocs/gdb_37.html#SEC686 Might be worth adding an option to translate semihosting calls into File-I/O requests. I think this should e.g. allow IDEs to print the target output into the Console window. That would be great indeed. I don't anticipate doing that work myself in a near future though, so please be my guest. ;-) Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] basic ARM semihosting support
On Thu, 3 Dec 2009, Zach Welch wrote: On Thu, 2009-12-03 at 12:27 -0500, Nicolas Pitre wrote: On Thu, 3 Dec 2009, Zach Welch wrote: On Thu, 2009-12-03 at 10:39 +0100, Øyvind Harboe wrote: I added a missing #include sys/stat.h, but it is not quite ready to commit yet I think. Does it build under Windows? Perhaps it does, I didn't try. I don't think we should try to make this work under anything but POSIX API for now, but the build should not fail. Autotools magic? Some docs to openocd.texi would be great. Okay, one more nit to pick from me too: use a static function to encapsulate the hunk of new code that's being added 4-tabs to the wind. Please, I beg you :) I know... My problem initially is that I had 3 cases: return error right away, return success right away, or fall through the code that follows. This was akward to express with a single return value so I just left the code inline and didn't revisit it. Feel free to submit additional patches to clean up the surrounding code before your existing patch, if that will make the current patch cleaner. The fact that there are already 3 levels of indent in that function indicates such work would only improve the surrounding code. ;) Please don't commit anything yet. I'm coming up with another version Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH v2] basic ARM semihosting support
Semihosting enables code running on an ARM target to use the I/O
facilities on the host computer. The target application must be linked
against a library that forwards operation requests by using the SVC
instruction that is trapped at the SWI vector by the debugger. The hosted
library version provided with CodeSourcery's Sourcery G++ Lite for ARM EABI
is one example.
This is currently available for ARM9 processors, but any ARM variant should
be able to support this with little additional work.
Tested using binaries compiled with Sourcery G++ Lite 2009q1-161 and
ARM RVCT 3.0.
Signed-off-by: Nicolas Pitre n...@marvell.com
---
Changes from version 1:
- abstracted the semihosting hook away for easy reuse by other ARM
archs plus some usage comment
- stat() is no more: used lseek() instead to increase portability
- added include guard and copyright in arm_semihosting.h
- added basic documentation in openocd.texi
(be my guest if you wish to expand the documentation on this topic)
- adjusted include paths needed by latest changes in the source tree
- added missing arm_semihosting.h in Makefile.am
doc/openocd.texi |9 +
src/target/Makefile.am |2 +
src/target/arm7_9_common.c | 44
src/target/arm_semihosting.c | 443 ++
src/target/arm_semihosting.h | 28 +++
5 files changed, 526 insertions(+), 0 deletions(-)
create mode 100644 src/target/arm_semihosting.c
create mode 100644 src/target/arm_semihosting.h
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 7e23211..8979314 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5674,6 +5674,15 @@ cables (FT2232), but might be unsafe if used with
targets running at very low
speeds, like the 32kHz startup clock of an AT91RM9200.
@end deffn
+...@deffn Command {arm7_9 semihosting} (@option{enable}|@option{disable})
+Enable or disable ARM semihosting support. Semihosting allows for code
+executing on an ARM target to use the I/O facilities on the host computer
+i.e. the system where OpenOCD is running. The target application must be
+linked against a library implementing the ARM semihosting convention that
+forwards operation requests by using a special SVC instruction that is
+trapped at the SWI vector by the debugger.
+...@end deffn
+
@subsection ARM720T specific commands
@cindex ARM720T
diff --git a/src/target/Makefile.am b/src/target/Makefile.am
index 7631bea..bd7bf7a 100644
--- a/src/target/Makefile.am
+++ b/src/target/Makefile.am
@@ -78,6 +78,7 @@ ARM_DEBUG_SRC = \
arm_jtag.c \
arm_disassembler.c \
arm_simulator.c \
+ arm_semihosting.c \
arm_adi_v5.c \
embeddedice.c \
trace.c \
@@ -101,6 +102,7 @@ noinst_HEADERS = \
arm_adi_v5.h \
arm_disassembler.h \
arm_simulator.h \
+ arm_semihosting.h \
arm7_9_common.h \
arm7tdmi.h \
arm720t.h \
diff --git a/src/target/arm7_9_common.c b/src/target/arm7_9_common.c
index 255a85f..7318b5f 100644
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -36,6 +36,7 @@
#include etm.h
#include helper/time_support.h
#include arm_simulator.h
+#include arm_semihosting.h
#include algorithm.h
#include register.h
@@ -915,6 +916,9 @@ int arm7_9_poll(struct target *target)
}
}
+ if (arm_semihosting(target, retval) != 0)
+ return retval;
+
if ((retval = target_call_event_callbacks(target,
TARGET_EVENT_HALTED)) != ERROR_OK)
{
return retval;
@@ -2814,6 +2818,39 @@ COMMAND_HANDLER(handle_arm7_9_dcc_downloads_command)
return ERROR_OK;
}
+COMMAND_HANDLER(handle_arm7_9_semihosting_command)
+{
+ struct target *target = get_current_target(CMD_CTX);
+ struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
+
+ if (!is_arm7_9(arm7_9))
+ {
+ command_print(CMD_CTX, current target isn't an ARM7/ARM9
target);
+ return ERROR_TARGET_INVALID;
+ }
+
+ if (CMD_ARGC 0)
+ {
+ COMMAND_PARSE_ENABLE(CMD_ARGV[0], semihosting_active);
+
+ /* TODO: support other methods if vector catch is unavailable */
+ if (arm7_9-has_vector_catch) {
+ struct reg *vector_catch =
arm7_9-eice_cache-reg_list[EICE_VEC_CATCH];
+ if (!vector_catch-valid)
+ embeddedice_read_reg(vector_catch);
+ buf_set_u32(vector_catch-value, 2, 1,
semihosting_active);
+ embeddedice_store_reg(vector_catch);
+ } else if (semihosting_active) {
+ command_print(CMD_CTX, vector catch unavailable);
+ semihosting_active = 0;
+ }
+ }
+
+ command_print(CMD_CTX
Re: [Openocd-development] [PATCH] basic ARM semihosting support
On Thu, 3 Dec 2009, David Brownell wrote:
Cool!
On Thursday 03 December 2009, Nicolas Pitre wrote:
Some docs to openocd.texi would be great.
It sure would. ;-)
More like essential. ;)
I provided the minimum in version 2 of the patch. For improved prose
I'll defer to those amongst us with better English writing skills.
Also, NEWS; and surely a few TODO list updates (like that
mapping table, etc).
I'll let someone else modify the NEWS. As to the TODO items: they're
already commented in the code. So please just commit v2 as is now and
let's put incremental improvements on top. I want other people to get
involved too! ;-)
What's the story on how one would *use* this? Must target
code be linked with pay-money-for-software from ARM? Or
do other options exist?
Did you read my patch commit log?
OK let's make it easy (for those who are eager to contribute extra
documentation... hint hint).
Semihosting crash HOWTO
---
1) Get Sourcery G++ Lite 2009q1-161 for ARM EABI from
http://www.codesourcery.com/sgpp/lite/arm/portal/release830
Maybe there is a newer release now which should work just as well. I'm
still using the one above so...
2) Install it (how to install is out of the scope for this HOWTO)
Documentation on proper installation is provided through the above site.
3) Create test code
$ cat foobar.c EOF
#include stdio.h
#include stdlib.h
int main()
{
printf(\n\nHello World!\n\n\n);
exit(0);
}
EOF
4) Compile it
$ arm-none-eabi-gcc -T generic-hosted.ld -o foobar.elf foobar.c
For more control on things like heap and stack placement you'll have to
read the accompanying documentation (or dig in the provided linker
script).
5) Using OpenOCD, load onto target
| soft_reset_halt
| load_image foobar.elf
| arm7_9 semihosting enable
| resume 0
Interaction with the remote application then happens on the console
where OpenOCD is running.
It seems to just use SVC, so that means no particular constraints (as
would be the case if it required DCC and precluded using libdcc).
Right. And documentation on the semihosting interface is publicly
available (see reference in the code).
Please start us with a brief how to... email, and recap
who would be interested (and why). Done well that'd be
the seeed of the User's Guide coverage.
Interest is pretty evident when you want to display debugging
information from code running on a target without a serial port for
example, or during early board bringup when there is simply no code yet
to drive the serial port. This is also pretty handy when writing, say,
SPI flash programming utilities which are best ran on the target
directly but with the ability to provide interactive menus and read (or
write) data files directly from the host. Etc. Etc...
Code-wise ... I'd rather see an explicit flag stored in
the struct arm, rather than depend on nobody setting
their own values for the vector catch flag. Instead of
that global. (Resolve before merge please.)
Not sure that I follow you here. But like I said above: please merge it
now and let's improve it later. This is already plenty functional as is
and further cleanups should be trivial.
It'd also make sense to have the semhosting active
status appear in armv4_5_arch_state(); but nothing if
it's inactive. Maybe just an optional string at the
end of the line with CPSR and PC.
Indeed. Same argument apply.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] basic ARM semihosting support
On Thu, 3 Dec 2009, David Brownell wrote: On Thursday 03 December 2009, Nicolas Pitre wrote: Semihosting enables code running on an ARM target to use the I/O facilities on the host computer. The target application must be linked against a library that forwards operation requests by using the SVC instruction that is trapped at the SWI vector by the debugger. The hosted Nit: it's now called the Supervisor Call vector; not SWI vector. :) Bah. I originally had the SWI instruction there. library version provided with CodeSourcery's Sourcery G++ Lite for ARM EABI is one example. I have arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ... where is that library? Or do I need a different EABI package? Get arm-2009q1-161-arm-none-eabi-i686-pc-linux-gnu.tar.bz2 instead. The set of included libraries are completely different. Both may coexist. This is currently available for ARM9 processors, but any ARM variant should be able to support this with little additional work. Yeah, I seem to be poking at those parts of ARM11 and Cortex-A8... If possible, I'd like to see 0.4.0 ship with this expected to work on all ARMs except maybe Cortex-M chips. (They aren't yet able to plug into the arm subcommand ... infrastructure.) That should be trivial, especially with v2 of my patch. All that is needed is to set up a trap on the SVC vector. Either with a vector trap or a breakpoint. This is about the only thing that is ARM variant dependent. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] basic ARM semihosting support
Semihosting enables code running on an ARM target to use the I/O
facilities on the host computer. The target application must be linked
against a library that forwards operation requests by using the SVC
instruction that is trapped at the SWI vector by the debugger. The hosted
library version provided with CodeSourcery's Sourcery G++ Lite for ARM EABI
is one example.
This is currently available for ARM9 processors, but any ARM variant should
be able to support this with little additional work.
Tested using binaries compiled with Sourcery G++ Lite 2009q1-161 and
ARM RVCT 3.0.
Signed-off-by: Nicolas Pitre n...@marvell.com
diff --git a/src/target/Makefile.am b/src/target/Makefile.am
index cb473a3..b083a55 100644
--- a/src/target/Makefile.am
+++ b/src/target/Makefile.am
@@ -80,6 +80,7 @@ ARM_DEBUG_SRC = \
arm_jtag.c \
arm_disassembler.c \
arm_simulator.c \
+ arm_semihosting.c \
arm_adi_v5.c \
embeddedice.c \
trace.c \
diff --git a/src/target/arm7_9_common.c b/src/target/arm7_9_common.c
index b5553cd..e4ae4f9 100644
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -36,6 +36,7 @@
#include etm.h
#include time_support.h
#include arm_simulator.h
+#include arm_semihosting.h
#include algorithm.h
#include register.h
@@ -867,6 +868,7 @@ int arm7_9_poll(struct target *target)
{
int retval;
struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
+ struct arm *armv4_5 = arm7_9-armv4_5_common;
struct reg *dbg_stat = arm7_9-eice_cache-reg_list[EICE_DBG_STAT];
/* read debug status register */
@@ -915,6 +917,38 @@ int arm7_9_poll(struct target *target)
}
}
+ if (semihosting_active
+ armv4_5-core_mode == ARMV4_5_MODE_SVC
+
buf_get_u32(armv4_5-core_cache-reg_list[15].value, 0, 32) == 0x08)
+ {
+ uint32_t lr =
buf_get_u32(ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, ARMV4_5_MODE_SVC,
14).value, 0, 32);
+ uint32_t spsr =
buf_get_u32(armv4_5-spsr-value, 0, 32);
+ int semihosting_ok;
+
+ /* check instruction that triggered this trap */
+ if (spsr (1 5)) {
+ /* was in Thumb mode */
+ uint8_t insn_buf[2];
+ uint16_t insn;
+ retval = target_read_memory(target,
lr-2, 2, 1, insn_buf);
+ if (retval != ERROR_OK)
+ return retval;
+ insn = target_buffer_get_u16(target,
insn_buf);
+ semihosting_ok = (insn == 0xdfab);
+ } else {
+ /* was in ARM mode */
+ uint8_t insn_buf[4];
+ uint32_t insn;
+ retval = target_read_memory(target,
lr-4, 4, 1, insn_buf);
+ if (retval != ERROR_OK)
+ return retval;
+ insn = target_buffer_get_u32(target,
insn_buf);
+ semihosting_ok = (insn == 0xef123456);
+ }
+ if (semihosting_ok)
+ return do_arm_semihosting(target);
+ }
+
if ((retval = target_call_event_callbacks(target,
TARGET_EVENT_HALTED)) != ERROR_OK)
{
return retval;
@@ -2814,6 +2848,39 @@ COMMAND_HANDLER(handle_arm7_9_dcc_downloads_command)
return ERROR_OK;
}
+COMMAND_HANDLER(handle_arm7_9_semihosting_command)
+{
+ struct target *target = get_current_target(CMD_CTX);
+ struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
+
+ if (!is_arm7_9(arm7_9))
+ {
+ command_print(CMD_CTX, current target isn't an ARM7/ARM9
target);
+ return ERROR_TARGET_INVALID;
+ }
+
+ if (CMD_ARGC 0)
+ {
+ COMMAND_PARSE_ENABLE(CMD_ARGV[0], semihosting_active);
+
+ /* TODO: support other methods if vector catch is unavailable */
+ if (arm7_9-has_vector_catch) {
+ struct reg *vector_catch =
arm7_9-eice_cache-reg_list[EICE_VEC_CATCH];
+ if (!vector_catch-valid)
+ embeddedice_read_reg(vector_catch);
+ buf_set_u32(vector_catch-value, 2, 1,
semihosting_active
[Openocd-development] [PATCH] feroceon.c should be part of ARM7_9_SRC
The Feroceon and Dragonite cores are similar to the ARM926 and ARM966 cores respectively. Signed-off-by: Nicolas Pitre n...@marvell.com --- diff --git a/src/target/Makefile.am b/src/target/Makefile.am index b083a55..df42413 100644 --- a/src/target/Makefile.am +++ b/src/target/Makefile.am @@ -58,11 +58,11 @@ ARM7_9_SRC = \ arm9tdmi.c \ arm920t.c \ arm966e.c \ - arm926ejs.c + arm926ejs.c \ + feroceon.c ARM_MISC_SRC = \ fa526.c \ - feroceon.c \ xscale.c ARMV6_SRC = \ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/6:0/84] command registration
On Tue, 24 Nov 2009, Zach Welch wrote: On Tue, 2009-11-24 at 16:33 -0600, Dean Glazeski wrote: First of all, screw you for all of these patches. Frekin' 80+ emails! Yeah, sorry. ;) I particularly apologize for 'git send-email' failing to properly thread the messages for each series under their summaries. Did you invoke 'git send-email' for each series separately? If no then you should have. If yes then this is definitively a send-email bug. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/6:0/84] command registration
On Tue, 24 Nov 2009, Zach Welch wrote: On Tue, 2009-11-24 at 21:55 -0500, Nicolas Pitre wrote: On Tue, 24 Nov 2009, Zach Welch wrote: On Tue, 2009-11-24 at 16:33 -0600, Dean Glazeski wrote: First of all, screw you for all of these patches. Frekin' 80+ emails! Yeah, sorry. ;) I particularly apologize for 'git send-email' failing to properly thread the messages for each series under their summaries. Did you invoke 'git send-email' for each series separately? If no then you should have. If yes then this is definitively a send-email bug. I did it in one line, assuming that it would work as it did when I ran it by hand. We both seem to have expected it to have worked better: for i in $(seq 1 6); do git send-email patches/reg$i \ --to=openocd-developm...@lists.berlios.de \ --from...@superlucidity.net \ --in-reply-to=1259100144.20337.4503.ca...@localhost done Your usage of --in-reply-to is wrong. That made all patch series to end up in the same thread. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/6:0/84] command registration
On Tue, 24 Nov 2009, Zach Welch wrote: On Tue, 2009-11-24 at 22:08 -0500, Nicolas Pitre wrote: Your usage of --in-reply-to is wrong. That made all patch series to end up in the same thread. How could I have done it right? Of course, this assumes that sending 6 patche series in reply to a top-level summary is desirable Anyway, here is the relevant output from 'git send-email --help': --in-reply-to=identifier Specify the contents of the first In-Reply-To header. Subsequent emails will refer to the previous email instead of this if --chain-reply-to is set (the default) Only necessary if --compose is also set. If --compose is not set, this will be prompted for. It said the first header, darn it! I trusted the documentation! :) It also says ... if --chain-reply-to is set which doesn't appear to be your case despite the fact that it is said to be the default. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3.0 fatal bug
On Sat, 7 Nov 2009, David Brownell wrote: The other is that we really don't have a team of folk set up to build for different Linux distros, BSDs, MacOS, Windows, etc; and IMO, we shouldn't. There *are* teams of folk set up to build for those ... e.g. the Fedora project builds regularly, so do Debian, Ubuntu, SuSE, and so forth. Building sources on Unix systems is usually trivial and pleasant. The same can't be said about Windows. This is why many projects provide Windows binaries and only sources otherwise. I don't think that would be way out of line if we did the same, given that someone is already performing that build and advertising it on his personal website. We could as well just put that package on SF. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] release numbering
On Fri, 6 Nov 2009, CeDeROM wrote: Hello guys! I try to maintain OpenOCD port for FreeBSD, and I think current numbering scheme sux and brings great confusion - there are two unused digits in the release number and now there is also a -rc0 suffix. This is a MESS! I don' like it. Well, I do like it. And -rc only means release candidate, so you're not supposed to ever use that for the FreeBSD port. So if the latest version is a -rc version then that means you probably should wait a bit until it is turned into a real release. Why don't we name a release 0.3.0, make it public, That just happened. fix errors for a week, release 0.3.1, fix errors for next week then release 0.3.2, That's also the plan, although there is no weekly fixed schedule. if there are no errors add some features and release 0.3.3... With new features, the release will be 0.4.0 instead. if there are releases where only the middle number changes, why to use others? See above. By the way - is 0.3.0 supposed to be an unstable release while the 0.4.0 is the next stable release (as in Linux kernel numbering)? No. And Linux stopped using that stable/unstable numbering scheme a long long time ago BTW. Is all these numbers really necessary? Does anybody have control over these numbers? I think so. What is more - a 0.3.0 release is available already on the download page (openocd 0.3.0 November 4, 2009) - is it 0.3.0 already or still the 0.3.0-rc0? If rc0 why it is named 0.3.0? :-( If advertised as 0.3.0 then there is a pretty good chance it is the true 0.3.0. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] release numbering
On Thu, 5 Nov 2009, David Brownell wrote: On Thursday 05 November 2009, Nicolas Pitre wrote: If advertised as 0.3.0 then there is a pretty good chance it is the true 0.3.0. Only if pretty good means 100%. ;) Of course, that means 0.3.0 from the official repository. We currently are not signing releases with GPG or anything. What I meant is 0.3.0 vs 0.3.0-rc, where true means without -rc. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-0.3.0-rc0 bug: Fail to write to Intel NOR Flash on AT91SAM9260
On Mon, 2 Nov 2009, David Brownell wrote: That is, git describe efef05870d726fe4cb6786d785fae4628fe7ec1e will tell you that it's 125 commits after the v0.2.0 tag. BTW, when using that 40 character hex string, you can abbreviate it to the first 7 or 8 characters. Git will accept it as long as it uniquely describe an object (and 8 chars is normally sufficient): git describe efef0587 Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] ARM926: fix arm926ejs_mmu() reading from bad pointer
On Fri, 30 Oct 2009, David Brownell wrote:
I'm suspecting this code can never have worked, since the
original commit (svn #335) in early 2008.
Fix is just copy/paste from another (working) function.
---
src/target/arm926ejs.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/src/target/arm926ejs.c
+++ b/src/target/arm926ejs.c
@@ -906,7 +906,9 @@ static int arm926ejs_virt2phys(struct ta
static int arm926ejs_mmu(struct target_s *target, int *enabled)
{
armv4_5_common_t *armv4_5 = target-arch_info;
- arm926ejs_common_t *arm926ejs = armv4_5-arch_info;
+ arm7_9_common_t *arm7_9 = armv4_5-arch_info;
+ arm9tdmi_common_t *arm9tdmi = arm7_9-arch_info;
+ arm926ejs_common_t *arm926ejs = arm9tdmi-arch_info;
if (target-state != TARGET_HALTED)
{
Well...
I really don't like this pointer business. No type checking at all,
etc. This should be turned upside down as you suggested already: embed
more generic structures within the more specific ones, and copy the
container_of() macro from Linux to get at the outer structure when
needed.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] ARM926: fix arm926ejs_mmu() reading from bad pointer
On Fri, 30 Oct 2009, David Brownell wrote: On Friday 30 October 2009, Nicolas Pitre wrote: I really don't like this pointer business. No type checking at all, etc. This should be turned upside down as you suggested already: embed more generic structures within the more specific ones, and copy the container_of() macro from Linux to get at the outer structure when needed. I was working on such patches when I noticed this goof ... arm926ejs = target_to_arm926(target); without all that other crap is a *LOT* cleaner IMO. Very few of the functions need pointers to the inner structs; that idiom just makes things confusing. Goodie! However, such changes would be wrong to merge before we finally let 0.3.x out the door. No question about that. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clever handling of working areas
On Thu, 29 Oct 2009, Øyvind Harboe wrote: In OpenOCD there is a bit of clever handling of working areas. You can essentially allocate a piece of working memory on the target and store e.g. an algorithm into that working area over an extended period of time to improve performance. If a reset or similar happens, then OpenOCD will iterate through all the working areas and null out the pointers to the working area so that e.g. the flash routines know to reallocate and repopulate the working areas. The neat side effect of this is that it will leave algorithms in target memory for a long time, increasing performance. The nasty side effect is that it *really* complicates the code path... I have an unsubstantiated suspicion that this breaks e.g. flash programming on arm926ejs. If I can catch this handling of working memory red-handed in causing bugs, my instinct would be to remove it. I'm hopeful that e.g. flash programming routines would be able to recover the performance with slight rewriting My instinct tells me otherwise. But you know, now that we have Git, you can do that rewrite in a branch of your own and let people try it out in parallel with the master branch. Only when factual results are confirmed by enough people that the rewrite is really better then should that branch be merged in the master branch. Please let's not recreate that tantrum in the repository like what happened a few months ago. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clever handling of working areas
On Thu, 29 Oct 2009, Øyvind Harboe wrote: If the particular issue above is caught red-handed we'll be able to evaluate whether or not we have something which is optimized too much for marginal speed gains and too little for stability... The work area is used for far more things than just NOR flash support. Some of my code rely on that functionalyty and I know that a great speed gain is obtained by not having to reload the code on the target over and over. So to me this is not too much optimizing. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Clever handling of working areas
On Thu, 29 Oct 2009, Øyvind Harboe wrote: How's this branch btw? (comments, signoff, etc.) It's where I exercise my rebase skills :-) http://repo.or.cz/w/openocd/oharboe.git?a=shortlog;h=refs/heads/mrcmcr You're making progress! One example where improvements could be made though: http://repo.or.cz/w/openocd/oharboe.git?a=commit;h=a6be8d289568b |arm11: retire obsolete mrc/mcr commands. | |Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com This commit message on its own raises the obvious question: why? Explaining that those are redundant since the introduction of the xyz commands by the would help understand the why. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] removing exports and forward decls
On Wed, 28 Oct 2009, David Brownell wrote: On Wednesday 28 October 2009, Zach Welch wrote: I am becoming fairly discouraged by the ongoing high-pace use of the central repository, seeing this type of commit pushed without sufficient review period. Are we trying for 0.3.0, or not?!? I was kind of expecting you to cut an RC some time ago; so I've been wondering the same thing ... OK then. What about cutting it _now_ ? Please make it 0.3.0-rc1 right away. If something is really screwed and require a big patch then just merge the fix and call it -rc2. Otherwise let's ship 0.3.0 final in a week and accept small and only obvious bug fixes until then. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] http://repo.or.cz/w/openocd.git developer repositories
On Tue, 27 Oct 2009, John Devereux wrote: Øyvind Harboe oyvind.har...@zylin.com writes: From a developer point of view, I'm satisified with pushing dev branches to http://repo.or.cz/w/openocd.git. I have not yet used a shared developer branch... Who in their right mind would get involved in the mrcmcr branch? :-) I would like to see users test those branches though... What's the best way to make that happen? Isn't the best way to just simply have the branches in the main repository? Then when a user does a git clone, they get them locally and they can do a git branch whenever they are motivated to do so. Amen. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] http://repo.or.cz/w/openocd.git developer repositories
On Tue, 27 Oct 2009, Øyvind Harboe wrote: On Tue, Oct 27, 2009 at 2:27 PM, John Devereux j...@devereux.me.uk wrote: Øyvind Harboe oyvind.har...@zylin.com writes: From a developer point of view, I'm satisified with pushing dev branches to http://repo.or.cz/w/openocd.git. I have not yet used a shared developer branch... Who in their right mind would get involved in the mrcmcr branch? :-) I would like to see users test those branches though... What's the best way to make that happen? Isn't the best way to just simply have the branches in the main repository? It's the best, until something goes horribly wrong. Like what? Someone messes up the master branch? There are ways to mitigate that risk. And in the worst case you have plenty of full backups all around the globe already. Also the new site allows anyone to set up a repository without asking anyone for permission. That still can be done. There is no incompatibility with the idea of having more significant development branches offered for free to users through the main repository, and people like myself putting proposed work in a separate repo until it is made available through the main repo in a branch of its own, or pulled into the master branch, or rejected outright. With a small clever script, would you really be able to tell if you used sf or the new site for some dev branch? It's the principle of asking users to use an otherwise unneeded script to achieve the same result that somehow bothers me. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/3] more fixes to Thumb mode single stepping
On Tue, 27 Oct 2009, David Brownell wrote: On Monday 26 October 2009, Nicolas Pitre wrote: Here are 3 patches to fix all the remaining issues I've encountered with single-step support and Thumb mode. [PATCH 1/3] call thumb_pass_branch_condition() only for actual branch opcodes [PATCH 2/3] allow proper single stepping of Thumb BL and BLX instructions [PATCH 3/3] fix Thumb mode handling when single-stepping register based branch insns Merged all three ... Thanks for both the patches, and the good patch comments. I like having those. :) I do too. Long tradition of patch contributions to some other Open Source projects. See for example one of my best here: http://git.kernel.org/?p=git/git.git;a=commit;h=0e8189e270 While the above is quite an extreme example, I still do think that patch contributors to OpenOCD should be a bit more verbose in their commit messages. Without naming anyone, some commits have extremely light messages which are rather useless without actually looking at the patch directly. And I know that those unamed individuals have good writing skills given their track records on this mailing list. I hope those people know who they are and will consider this as a gentle request to improve their patch logs. Now... People might be unaware of the fact that Git interprets the first line of a commit message a bit specially. It is used by tools such as shortlog or format-patch to provide a subject line or a short summary. Therefore, when composing a commit message text, it is a good idea to include the following elements: 1) A short summary for the patch that is ideally 80 characters or less. Good examples are: Fix incorrect line endings SVF: fix parsing hex strings containing leading '0' characters ETM: rename registers, doc tweaks 2) An empty line. That's how Git distinguishes the summary line from the main commit explanation text. 3) Explanations on the commit. Here is the place to provide details justifying the change, like a description of the issue, the way this patch is solving it, any remaining issues after that patch is applied, etc. Of course there are patches that are so trivial to justify any more explanation other than what was already provided in the summary line (the Fix incorrect line endings being one such example). But most patches certainly deserves to be justified with more than one line of text as can be seen from many email threads following their initial posts on the list. There are good examples in the repository already. So please take some time to look at the output from 'git log' and think about making that log understandable to people other than the patch author by following those good examples. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] ARM: fix target address when disassembling Thumb BLX
A Thumb BLX instruction is branching to ARM code, and therefore the first 2 bits of the target address must be cleared. Signed-off-by: Nicolas Pitre n...@marvell.com --- src/target/arm_disassembler.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/target/arm_disassembler.c b/src/target/arm_disassembler.c index 5b0046b..ee087b1 100644 --- a/src/target/arm_disassembler.c +++ b/src/target/arm_disassembler.c @@ -1768,6 +1768,7 @@ static int evaluate_b_bl_blx_thumb(uint16_t opcode, case 1: instruction-type = ARM_BLX; mnemonic = BLX; + target_address = 0xfffc; break; /* BL/BLX prefix */ case 2: -- 1.6.5.1.101.g325e5 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] putting developer branches on sourceforge
On Mon, 26 Oct 2009, Zach Welch wrote: Your suggestion reflects client-server thinking. Really, Git is P2P. There are few good reasons to do active branch development in the main repository. I established the openocd/testing fork on repo.or.cz to do exactly what you describe. Setting this up requires adding that remote one time, and everyone can create a fork to push. While SF.net offers no forking, maintainers can follow progress of an entire flock of forks here: http://repo.or.cz/w/openocd.git?a=forks You said it: developers. Testing, however, comes from users. And they sure won't make the effort of tracking and merging multiple scattered repositories in order to provide feedback to developers. And considering the importance of my contributions to OpenOCD so far, I still consider myself as a user. To me the stake is not high enough for me to bother with separate repositories just to test Øyvind (or anyone else's) work. The incentive is just not there. I cannot overemphasize that SF.net should be treated like the goose that laid the golden egg. We put the repository there because their hosting virtually ensures its uptime (and backups... let's hope they never forget or fail those). It exists to provide the master copy of our repository, barring their server's failure -- but they we all have a fresh up-to-date clone handy, right? It hosts the _master_ branch, indeed. But where do you get that idea that it can't serve development and proposed feature branches? Sure Git is p2p, but that is good for a huge development community to scale. I don't think OpenOCD has faced this issue so far. And for casual users/testers, a single central point to get work in progress is just so convenient. Doesn't mean that every branches from every developers have to be pushed on sourceforge of course. But for those who think their stuff is worth publishing for public feedback then why not having extra branches for that along the sacred master branch? Technically, Git can deal with both: separate repositories and/or separate branches. In the end, if you set up a remote and fetch it you end up with those multiple branches locally. But the advantage of having them already gathered in the remote repository greatly simplifies the effort for those who might be interested to provide some testing by not having to hunt for them in other repositories and configure their retrieval locally. And to those who maintain that repository on sourceforge... really there is no real cost, is there? That tree is our proverbial Tree of Linus. Do you really want to be playing in that garden? And rough housing? That sounds reckless to me! Bad comparison. Linus is the gate keeper for a project that is a couple order of magnitude bigger than OpenOCD. We are still a bunch hacking together in one's basement or garage here. It is not relevant to erect fences yet I think. Of course I'm not proposing to give everyone who asks the privilege to push branches to the sourceforge repo. That privilege may remain with those who have it now due to their significant implication with the project. However if I come up with a sizeable patch series and put it in a Git repo somewhere and there is some value in it, then I think that one of the sourceforge repo maintainer could pull that branch and make it available along with other proposed changes in the sourceforge repository for wider visibility. There is no reason to _ever_ restore the repository because you made a mistake, but you seem to suggest this would be an acceptable practice. Is this really a serious issue? The idea is for people to mess with their own branches, not the master one. That's why I suggested a model for branch namespace. If you're really concerned about the validity and coherency of the master branch, then some extra security mechanism can be applied to it with the Git update hook for example. Simultaneously, that characterization seems like a Red Herring -- it's still a commons, not a private tree. No one is suggesting to make the sourceforge tree everyone's private tree. Neither should be repo.or.cz for that matter. Common sense should be applied concerning the suitability of a branch to a public repo, and to the _reference_ repo. [...] So, yes, I object to putting active branches on SF.net that will be maintained by mere fleshy human brains. This approach fails to embrace the distributed Git workflow. If I were to take things to their logical extreme, I might try to require one fork be created per branch (sound familiar to anyone?), but Git has rendered that nonsensical. We may agree to disagree and leave it at that. After all, I said already that I'm not a major contributor hence my opinion has little weight. But for one last time, I'm stating that such rigid arrangement will simply turn away a sizeable portion of the very few testers OpenOCD might need to get to the next
Re: [Openocd-development] git development forks
On Mon, 26 Oct 2009, Zach Welch wrote: On Mon, 2009-10-26 at 00:12 +0100, Øyvind Harboe wrote: What about testers, how should they behave? Any way they please. ;) Seriously, that's perfectly valid question. Testers should: 1) Clone/pull from a branch that interests them. 2) Run tests. 3) Provide feedback to the branch's maintainer. If maintainers each have their own fork on repo.or.cz, then ownership of branches can be determined by the repository's gitweb information. ... or the branch name prefix. Yet I don't think branch owner is really important for testers. They really should post feedback and test results to this mailing list for everyone to see, assess and contribute. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git line endings
On Mon, 26 Oct 2009, Spencer Oliver wrote: Hi, While i have been away openocd certainly has been busy, while i have used git i am no expert - a git guide for devs may be a good idea :) The following files seem to now be in CRLF format (linux host), whether this was a svn-git issue i am not sure. While this is not a major issue it is nice to keep things correct. Text files should ideally be stored with LF-only line endings in Git. People on Windows may set their core.autocrlf Git config variable to true in order to deal with the conversion automatically (this might even be the default on Windows already). Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/3] more fixes to Thumb mode single stepping
Here are 3 patches to fix all the remaining issues I've encountered with single-step support and Thumb mode. [PATCH 1/3] call thumb_pass_branch_condition() only for actual branch opcodes [PATCH 2/3] allow proper single stepping of Thumb BL and BLX instructions [PATCH 3/3] fix Thumb mode handling when single-stepping register based branch insns Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] call thumb_pass_branch_condition() only for actual branch opcodes
Calling it first with every opcodes and then testing if the opcode
was indeed a branch instruction is wasteful and rather strange.
If ever thumb_pass_branch_condition() has side effects (say, like
printing a debugging traces) then the result would be garbage for most
Thumb instructions which have no condition code.
While at it, let's make the nearby code more readable by reducing some of
the redundant brace noise and reworking the error handling construct.
Signed-off-by: Nicolas Pitre n...@marvell.com
---
src/target/arm_simulator.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index e2f49c3..646baea 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -309,19 +309,17 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
{
uint16_t opcode;
- if ((retval = target_read_u16(target, current_pc, opcode)) !=
ERROR_OK)
- {
+ retval = target_read_u16(target, current_pc, opcode);
+ if (retval != ERROR_OK)
return retval;
- }
- if ((retval = thumb_evaluate_opcode(opcode, current_pc,
instruction)) != ERROR_OK)
- {
+ retval = thumb_evaluate_opcode(opcode, current_pc,
instruction);
+if (retval != ERROR_OK)
return retval;
- }
instruction_size = 2;
/* check condition code (only for branch instructions) */
- if ((!thumb_pass_branch_condition(sim-get_cpsr(sim, 0, 32),
opcode))
- (instruction.type == ARM_B))
+ if (instruction.type == ARM_B
+ !thumb_pass_branch_condition(sim-get_cpsr(sim, 0, 32),
opcode))
{
if (dry_run_pc)
{
--
1.6.5.1.101.g325e5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] fix Thumb mode handling when single-stepping register based branch insns
Currently, OpenOCD is always caching the PC value without the T bit.
This means that assignment to the PC register must clear that bit and set
the processor state to Thumb when it is set. And when the PC register
value is transferred to another register or stored into memory then
the T bit must be restored.
Discussion: It is arguable if OpenOCd should have preserved the original
PC value which would have greatly simplified this code. The processor
state could then be obtained simply by getting at bit 0 of the PC. This
however would require special handling elsewhere instead since the T bit
is not always relevant (like when PC is used with ALU insns or as an index
with some addressing modes). It is unclear which way would be simpler in
the end.
Signed-off-by: Nicolas Pitre n...@marvell.com
---
src/target/arm_simulator.c | 55 ++-
1 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 5af2c12..c50a52c 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -380,7 +380,8 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
else if (instruction.type == ARM_BL)
{
uint32_t old_pc = sim-get_reg(sim, 15);
- sim-set_reg_mode(sim, 14, old_pc + 4);
+ int T = (sim-get_state(sim) ==
ARMV4_5_STATE_THUMB);
+ sim-set_reg_mode(sim, 14, old_pc + 4 + T);
sim-set_reg(sim, 15, target);
}
else if (instruction.type == ARM_BX)
@@ -398,7 +399,8 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
else if (instruction.type == ARM_BLX)
{
uint32_t old_pc = sim-get_reg(sim, 15);
- sim-set_reg_mode(sim, 14, old_pc + 4);
+ int T = (sim-get_state(sim) ==
ARMV4_5_STATE_THUMB);
+ sim-set_reg_mode(sim, 14, old_pc + 4 + T);
if (target 0x1)
{
@@ -465,24 +467,24 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
if (dry_run_pc)
{
if (instruction.info.data_proc.Rd == 15)
- {
- *dry_run_pc = Rd;
- return ERROR_OK;
- }
+ *dry_run_pc = Rd ~1;
else
- {
*dry_run_pc = current_pc + instruction_size;
- }
return ERROR_OK;
}
else
{
+ if (instruction.info.data_proc.Rd == 15) {
+ sim-set_reg_mode(sim, 15, Rd ~1);
+ if (Rd 1)
+ sim-set_state(sim,
ARMV4_5_STATE_THUMB);
+ else
+ sim-set_state(sim, ARMV4_5_STATE_ARM);
+ return ERROR_OK;
+ }
sim-set_reg_mode(sim, instruction.info.data_proc.Rd,
Rd);
LOG_WARNING(no updating of flags yet);
-
- if (instruction.info.data_proc.Rd == 15)
- return ERROR_OK;
}
}
/* compare instructions (CMP, CMN, TST, TEQ) */
@@ -566,15 +568,9 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
if (dry_run_pc)
{
if (instruction.info.load_store.Rd == 15)
- {
- *dry_run_pc = load_value;
- return ERROR_OK;
- }
+ *dry_run_pc = load_value ~1;
else
- {
*dry_run_pc = current_pc + instruction_size;
- }
-
return ERROR_OK;
}
else
@@ -584,10 +580,16 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
{
sim-set_reg_mode(sim,
instruction.info.load_store.Rn, modified_address);
}
- sim-set_reg_mode(sim, instruction.info.load_store.Rd,
load_value);
- if (instruction.info.load_store.Rd == 15)
+ if (instruction.info.load_store.Rd == 15
[Openocd-development] [PATCH 2/3] allow proper single stepping of Thumb BL and BLX instructions
Whenever an unconditional branch with the H bits set to 0b10 is met, the
offset must be combined with the offset from the following opcode and not
ignored like it is now.
A comment in evaluate_b_bl_blx_thumb() suggests that the Thumb2 decoder
would be a simpler solution. That might be true when single-stepping of
Thumb2 code is implemented. But for now this appears to be the simplest
solution to fix Thumb1 support.
Signed-off-by: Nicolas Pitre n...@marvell.com
---
src/target/arm_simulator.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 646baea..5af2c12 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -332,6 +332,18 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
return ERROR_OK;
}
+
+ /* Deal with 32-bit BL/BLX */
+ if ((opcode 0xf800) == 0xf000) {
+ uint32_t high =
instruction.info.b_bl_bx_blx.target_address;
+ retval = target_read_u16(target, current_pc+2, opcode);
+ if (retval != ERROR_OK)
+ return retval;
+ retval = thumb_evaluate_opcode(opcode, current_pc,
instruction);
+ if (retval != ERROR_OK)
+ return retval;
+ instruction.info.b_bl_bx_blx.target_address += high;
+ }
}
/* examine instruction type */
--
1.6.5.1.101.g325e5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 schedule
On Sun, 25 Oct 2009, David Brownell wrote: Now, if I could only find out why nontrivial merges with git never seem to work right for me. :( You may have a look at 'git mergetool'. [...] Eventually, when OpenOCD will become a project as big as the Linux kernel ;-) then major developers could keep separate Git repositories of their own that get pulled in the main repository. But for now I think the above suggestion should be good enough and simple. Yes. Zach suggest repositories on non-SF sites for other developers; same sort of stuff. Sure. But I still think that stuff that is in need of testers should still be published through the main repository in some side branches. Call it laziness, but I'm not that excited about having to configure an additional remote spec just to fetch the new proposed mcr/mrc stuff. If instead I get it for free along with updates to the master branch during my next 'git fetch' then I might be tempted to have a look. So I'm not entirely in agreement with Zach on that front. Asking for extra steps/efforts from potential testers doesn't usually work that well. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 schedule
On Sat, 24 Oct 2009, David Brownell wrote: On Saturday 24 October 2009, Igor Skochinsky wrote: I think you need to fix your client unless some relay server screwed up the message. Here, David's email headers say: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hmm ... while that message was indeed 8859/1 when I sent it, quoted-printable wasn't AFACT involved. At least, not in the copy archived in my mailbox. That seems to have been added somewhere. Maybe some SMTP server is doing 8-bit -- 7-bit conversion wrong. Well, I somehow doubt it. Converting from 8-bit to quoted-printable is really hard to mess up for a few characters only as it is a direct transform. And the quoted-printable I received did decode and display correctly. Similarly for other people on the list. Seems to me that it is Øyvind's (let's see how this one gets through) MTA that is messing up incoming ISO-8859-1 and/or quoted-printable. Emails from him are UTF-8 with a base64 encoding which seems even more strange to me. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.3 schedule
On Sat, 24 Oct 2009, David Brownell wrote: I'm very pleased we have successfully migrated to git before 0.3. Yes; though as Nico pointed out, doing some work in branches would be a good thing. (I'm thinking of checking out stgit myself ... ) I was a quilt user before Git. These days however I do all my stuff with native Git branches only. I looked at StGit at some point and came back to native Git. When you get used to it, you don't want to look back. Creating a new branch is easy: git branch new_branch_name And then: git checkout new_branch_name You can add new commits as usual. Then if you want to do the equivalent of quilt pop -a; (update repo); quilt push -a then you can do that and much more with git fetch; git rebase The --interactive mode to 'git rebase' is incredibly useful. No need for quilt nor stgit anymore at that point (IMHO of course). During a bugfix-only RC phase, it'd be natural for folk to have ongoing development in branches. Then there would be some post-release merges of those branches into the mainline. Right. And to let people have easy access to those branches, my suggestion is for major contributors to publish those branches in the main Git repo on sourceforge. Suffice to establish a branch namespace such as: oyvind/mcrmrc oyvind/vector_catch david/thumb2 zach/install_script and so on. Once a branch is ready then someone simply checks out master and merges that branch: git checkout master git merge foobar/perfect_feature And at that point the branch can be deleted from the main repository. And so on. Unlike CVS, and even SVN to a certain extent, Branches are extremely easy to work with Git and people should not be afraid of using them at will. Eventually, when OpenOCD will become a project as big as the Linux kernel ;-) then major developers could keep separate Git repositories of their own that get pulled in the main repository. But for now I think the above suggestion should be good enough and simple. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix corruption of r0 when resuming Thumb mode on Feroceon
The wrong variable (pc instead of r0) was used. Furthermore, someone did cover this error by stupidly silencing the compiler warning that occurred before a dummy void reference to r0 was added to the code. --- diff --git a/src/target/feroceon.c b/src/target/feroceon.c index 8eea33e..f084201 100644 --- a/src/target/feroceon.c +++ b/src/target/feroceon.c @@ -335,7 +335,6 @@ void feroceon_branch_resume_thumb(target_t *target) arm_jtag_t *jtag_info = arm7_9-jtag_info; uint32_t r0 = buf_get_u32(armv4_5-core_cache-reg_list[0].value, 0, 32); uint32_t pc = buf_get_u32(armv4_5-core_cache-reg_list[15].value, 0, 32); - (void)(r0); // use R0... arm9tdmi_clock_out(jtag_info, ARMV4_5_NOP, 0, NULL, 0); arm9tdmi_clock_out(jtag_info, ARMV4_5_NOP, 0, NULL, 0); @@ -351,7 +350,7 @@ void feroceon_branch_resume_thumb(target_t *target) arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, 0, NULL, 0); arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, 0, NULL, 0); - arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, pc, NULL, 0); + arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, r0, NULL, 0); arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, 0, NULL, 0); arm9tdmi_clock_out(jtag_info, ARMV4_5_T_NOP, 0, NULL, 0); ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix single step of bx instruction going into Thumb mode
Without this fix, the following code cannot be single stepped:
add ip, pc, #1
bx ip
[thumb code here]
---
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 93fb3dd..e2f49c3 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -358,7 +358,7 @@ int arm_simulate_step_core(target_t *target, uint32_t
*dry_run_pc, struct arm_si
if (dry_run_pc)
{
- *dry_run_pc = target;
+ *dry_run_pc = target ~1;
return ERROR_OK;
}
else
___
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
On Sun, 18 Oct 2009, David Brownell wrote: On Sunday 18 October 2009, Øyvind Harboe wrote: I'm not quite up to speed on this graft stuff(first I heard of it), but I trust you on how to execute this in the best manner. I didn't know about graft (in the non-political sense!) before I started exploring how to fix this either. ;) To cleanup/fix a git repository, what you usually want to use is git filter-branch. The man page is quite comprehensive with examples. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Wed, 7 Oct 2009, Raúl Sánchez Siles wrote: I said I didn't want to start a flamewar and provided there has been, at least, a slight interest on my messages, I'll try to clear up some point and leave the thread alone. I cannot resist correcting you on one point though. [...] That benchmark is not taking into account wire protocol, very important for operations like clone, where I think Mercurial is more efficient. All VCS comparisons (and not only DVCS_ I've seen, Git always came out as having the tightest repository format, better than CVS, svN, HG, Bazaar, etc. And git uses the same format on thewire for clone transfer or even for bringing your local copy up to date. And I happen to know a bit about this since a significant part of the Git code involved in transfer operations is actually mine. So I don't really believe that Mercurial is more efficient in that regard. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thu, 8 Oct 2009, David Brownell wrote: On Thursday 08 October 2009, Zach Welch wrote: - Improve interactive support (e.g. 'pause', etc.). - https://developer.berlios.de/feature/?func=detailfeaturefeature_id=4086group_id=4148 pause ~= sleep text output == echo ... close this feature request as resolved. For the XScale and Sheevaplug things, I suggest Nicolas Pitre tell us what to do. I don't know anything about OpenOCD and XScale ((I guess that should be Øyvind). As for the sheevaPlug patch, I don't mind if it is applied... although the 0x4 for the size looks suspicious to me (why not 0x2?). In general I'd be inclined to close many of those patches with some kind of resubmit the normal way if this is still a problem status. There are several patches for random JTAG adapters, which surely need updating and re-testing by someone who actually has that hardware ... That's a classical problem with patch tracking systems. they get cluttered with patches that become outdated and/or obsolete. Also if there is no one to actually do the patch assignment then I certainly won't go have a look periodically just in case some random patch could interest me. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thu, 8 Oct 2009, David Brownell wrote: On Thursday 08 October 2009, Nicolas Pitre wrote: For the XScale and Sheevaplug things, I suggest Nicolas Pitre tell us what to do. I don't know anything about OpenOCD and XScale ((I guess that should be Øyvind). I was thinking XScale ~= Marvell and that you've recently been affiliated there ... but if you're no longer the XScale guru you once were, that's understandable. ;) Yep. Life moved on. Eric Miao is Linux PXA guru these days. but I never got involved with OpenOCd+XScale though. That's a classical problem with patch tracking systems. they get cluttered with patches that become outdated and/or obsolete. Which is why Linux uses mailing lists and relies on reposting, instead of a database that needs much more attention than is available. Yep. And so does git and other projects. Now let's hope that the move to Git will allow proper patch attributions to be recorded in the repository, instead of only committer information as it was the case with SVN (attribution in the commit log isn't good enough). that would allow for 'blame' to work properly which helps a lot when it's time to CC the biggest contributor of a file (which usually happens to be the best person to review the patch). For example, I'd be interested to be CC'd on Feroceon related patches, otherwise chances for me to miss them are much greater. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Dragonite target script
Dragonite target script
Dragonite target script
diff --git a/tcl/target/dragonite.cfg b/tcl/target/dragonite.cfg
new file mode 100644
index 000..d2e7e32
--- /dev/null
+++ b/tcl/target/dragonite.cfg
@@ -0,0 +1,31 @@
+##
+# Target:Marvell Dragonite CPU core
+##
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME dragonite
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x121003d3
+}
+
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME dragonite -endian $_ENDIAN -chain-position
$_TARGETNAME
+
+reset_config trst_and_srst
+jtag_nsrst_delay 200
+jtag_ntrst_delay 200
+
--
1.6.2.5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] silence bad EICE version number complaint for Dragonite
Dragonite has the same affliction as feroceon. Dragonite has the same affliction as feroceon. diff --git a/src/target/embeddedice.c b/src/target/embeddedice.c index 0d23c12..39f87c7 100644 --- a/src/target/embeddedice.c +++ b/src/target/embeddedice.c @@ -264,7 +264,8 @@ reg_cache_t* embeddedice_build_reg_cache(target_t *target, arm7_9_common_t *arm7 * in some unusual bits. Let feroceon.c validate it * and do the appropriate setup itself. */ - if (strcmp(target_get_name(target), feroceon) == 0) + if (strcmp(target_get_name(target), feroceon) == 0 || + strcmp(target_get_name(target), dragonite) == 0) break; LOG_ERROR(unknown EmbeddedICE version (comms ctrl: 0x%8.8 PRIx32 ), buf_get_u32(reg_list[EICE_COMMS_CTRL].value, 0, 32)); } -- 1.6.2.5 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] silence bad EICE version number complaint for Dragonite
On Tue, 6 Oct 2009, David Brownell wrote: I committed both of yoru Dragonite patches. Thx. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Nicolas Pitre has a new email address
Due to problems at cam.org, my n...@cam.org email address is no longer valid. FRom now on, n...@fluxnic.net should be used instead. diff --git a/src/flash/nand_ecc_kw.c b/src/flash/nand_ecc_kw.c index 54b1ee1..b2ab6b2 100644 --- a/src/flash/nand_ecc_kw.c +++ b/src/flash/nand_ecc_kw.c @@ -3,7 +3,7 @@ * Copyright (C) 2009 Marvell Semiconductor, Inc. * * Authors: Lennert Buytenhek buyt...@wantstofly.org - * Nicolas Pitre n...@cam.org + * Nicolas Pitre n...@fluxnic.net * * This file is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
On Mon, 14 Sep 2009, David Brownell wrote: What code do we have which wants JTAG chitchat during SRST? Have a look at sheevaplug_init in tcl/board/sheevaplug.cfg. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] libftdi regression since rev 2573
The SheevaPlug interface is now unusable since rev 2573: Error: unable to open ftdi device: device not found Runtime error, file command.c, line 469: Backing out changes from that revision does indeed fix the issue. So what was the point of that patch? Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Dragonite support
Dragonite is similar to the Feroceon core but has no MMU.
This can be found in chips such as the Marvell 8686 wireless chip.
Dragonite support. It is similar to the Feroceon core but has no MMU.
---
src/target/arm966e.c |3 --
src/target/arm966e.h |2 +
src/target/feroceon.c | 89 +++-
src/target/target.c |1 +
4 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/src/target/arm966e.c b/src/target/arm966e.c
index d8e8281..badcd4f 100644
--- a/src/target/arm966e.c
+++ b/src/target/arm966e.c
@@ -32,9 +32,6 @@
#define _DEBUG_INSTRUCTION_EXECUTION_
#endif
-/* cli handling */
-int arm966e_register_commands(struct command_context_s *cmd_ctx);
-
/* forward declarations */
int arm966e_target_create(struct target_s *target, Jim_Interp *interp);
int arm966e_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
diff --git a/src/target/arm966e.h b/src/target/arm966e.h
index 64641ea..c7a5b1b 100644
--- a/src/target/arm966e.h
+++ b/src/target/arm966e.h
@@ -34,6 +34,8 @@ typedef struct arm966e_common_s
uint32_t cp15_control_reg;
} arm966e_common_t;
+extern int arm966e_init_arch_info(target_t *target, arm966e_common_t *arm966e,
jtag_tap_t *tap);
+extern int arm966e_register_commands(struct command_context_s *cmd_ctx);
extern int arm966e_read_cp15(target_t *target, int reg_addr, uint32_t *value);
extern int arm966e_write_cp15(target_t *target, int reg_addr, uint32_t value);
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 536b678..5bbf72c 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -1,5 +1,5 @@
/***
- * Copyright (C) 2008 by Marvell Semiconductors, Inc.*
+ * Copyright (C) 2008-2009 by Marvell Semiconductors, Inc.
*
* Written by Nicolas Pitre n...@marvell.com *
* *
* Copyright (C) 2008 by Hongtao Zheng *
@@ -22,10 +22,10 @@
***/
/*
- * Marvell Feroceon support, including Orion and Kirkwood SOCs.
+ * Marvell Feroceon/Dragonite support.
*
- * The Feroceon core mimics the ARM926 ICE interface with the following
- * differences:
+ * The Feroceon core, as found in the Orion and Kirkwood SoCs amongst others,
+ * mimics the ARM926 ICE interface with the following differences:
*
* - the MOE (method of entry) reporting is not implemented
*
@@ -43,6 +43,9 @@
*
* - the DCC channel is half duplex (only one FIFO for both directions) with
* seemingly no proper flow control.
+ *
+ * The Dragonite core is the non-mmu version based on the ARM966 model, and
+ * it shares the above issues as well.
*/
#ifdef HAVE_CONFIG_H
@@ -50,11 +53,13 @@
#endif
#include arm926ejs.h
+#include arm966e.h
#include target_type.h
int feroceon_examine(struct target_s *target);
int feroceon_target_create(struct target_s *target, Jim_Interp *interp);
+int dragonite_target_create(struct target_s *target, Jim_Interp *interp);
int feroceon_bulk_write_memory(target_t *target, uint32_t address, uint32_t
count, uint8_t *buffer);
int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
int feroceon_quit(void);
@@ -111,6 +116,44 @@ target_type_t feroceon_target =
.quit = feroceon_quit
};
+target_type_t dragonite_target =
+{
+ .name = dragonite,
+
+ .poll = arm7_9_poll,
+ .arch_state = armv4_5_arch_state,
+
+ .target_request_data = arm7_9_target_request_data,
+
+ .halt = arm7_9_halt,
+ .resume = arm7_9_resume,
+ .step = arm7_9_step,
+
+ .assert_reset = feroceon_assert_reset,
+ .deassert_reset = arm7_9_deassert_reset,
+ .soft_reset_halt = arm7_9_soft_reset_halt,
+
+ .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
+
+ .read_memory = arm7_9_read_memory,
+ .write_memory = arm7_9_write_memory,
+ .bulk_write_memory = feroceon_bulk_write_memory,
+ .checksum_memory = arm7_9_checksum_memory,
+ .blank_check_memory = arm7_9_blank_check_memory,
+
+ .run_algorithm = armv4_5_run_algorithm,
+
+ .add_breakpoint = arm7_9_add_breakpoint,
+ .remove_breakpoint = arm7_9_remove_breakpoint,
+ .add_watchpoint = arm7_9_add_watchpoint,
+ .remove_watchpoint = arm7_9_remove_watchpoint,
+
+ .register_commands = arm966e_register_commands,
+ .target_create = dragonite_target_create,
+ .init_target = feroceon_init_target,
+ .examine = feroceon_examine,
+ .quit = feroceon_quit
+};
int feroceon_dummy_clock_out(arm_jtag_t *jtag_info, uint32_t instr)
{
@@ -621,16 +664,10 @@ int feroceon_quit(void)
return ERROR_OK;
}
-int feroceon_target_create(struct target_s *target, Jim_Interp
[Openocd-development] [PATCH] feroceon: tighten error checking in bulk_write
Make sure the target is actually halted at the end of the transfer and
confirm from the target's r0 content that the right amount of data was
actually received.
feroceon: tighten error checking in bulk_write
---
src/target/feroceon.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 5bbf72c..6a673b7 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -634,9 +634,20 @@ int feroceon_bulk_write_memory(target_t *target, uint32_t
address, uint32_t coun
buffer += 4;
}
- target_halt(target);
- while (target-state != TARGET_HALTED)
- target_poll(target);
+ retval = target_halt(target);
+ if (retval == ERROR_OK)
+ retval = target_wait_state(target, TARGET_HALTED, 500);
+ if (retval == ERROR_OK) {
+uint32_t endaddress =
+ buf_get_u32(armv4_5-core_cache-reg_list[0].value, 0,
32);
+ if (endaddress != address + count*4) {
+ LOG_ERROR(DCC write failed,
+expected end address 0x%08 PRIx32
+got 0x%0 PRIx32 ,
+ address + count*4, endaddress);
+ retval = ERROR_FAIL;
+ }
+ }
/* restore target state */
for (i = 0; i = 5; i++)
@@ -650,7 +661,7 @@ int feroceon_bulk_write_memory(target_t *target, uint32_t
address, uint32_t coun
armv4_5-core_cache-reg_list[15].dirty = 1;
armv4_5-core_state = core_state;
- return ERROR_OK;
+ return retval;
}
int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target)
--
1.6.5.rc0.164.g5f6b0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] small feroceon.c cleanup
feroceon.c: put feroceon target definition at the end so to avoid a
bunch of useless forward declarations.
feroceon.c: put feroceon target definition at the end so to avoid a bunch of
forward declarations.
---
src/target/feroceon.c | 165 +++-
1 files changed, 79 insertions(+), 86 deletions(-)
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 6a673b7..8eea33e 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -56,14 +56,6 @@
#include arm966e.h
#include target_type.h
-
-int feroceon_examine(struct target_s *target);
-int feroceon_target_create(struct target_s *target, Jim_Interp *interp);
-int dragonite_target_create(struct target_s *target, Jim_Interp *interp);
-int feroceon_bulk_write_memory(target_t *target, uint32_t address, uint32_t
count, uint8_t *buffer);
-int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
-int feroceon_quit(void);
-
int feroceon_assert_reset(target_t *target)
{
armv4_5_common_t *armv4_5 = target-arch_info;
@@ -77,84 +69,6 @@ int feroceon_assert_reset(target_t *target)
return arm7_9_assert_reset(target);
}
-target_type_t feroceon_target =
-{
- .name = feroceon,
-
- .poll = arm7_9_poll,
- .arch_state = arm926ejs_arch_state,
-
- .target_request_data = arm7_9_target_request_data,
-
- .halt = arm7_9_halt,
- .resume = arm7_9_resume,
- .step = arm7_9_step,
-
- .assert_reset = feroceon_assert_reset,
- .deassert_reset = arm7_9_deassert_reset,
- .soft_reset_halt = arm926ejs_soft_reset_halt,
-
- .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
-
- .read_memory = arm7_9_read_memory,
- .write_memory = arm926ejs_write_memory,
- .bulk_write_memory = feroceon_bulk_write_memory,
- .checksum_memory = arm7_9_checksum_memory,
- .blank_check_memory = arm7_9_blank_check_memory,
-
- .run_algorithm = armv4_5_run_algorithm,
-
- .add_breakpoint = arm7_9_add_breakpoint,
- .remove_breakpoint = arm7_9_remove_breakpoint,
- .add_watchpoint = arm7_9_add_watchpoint,
- .remove_watchpoint = arm7_9_remove_watchpoint,
-
- .register_commands = arm926ejs_register_commands,
- .target_create = feroceon_target_create,
- .init_target = feroceon_init_target,
- .examine = feroceon_examine,
- .quit = feroceon_quit
-};
-
-target_type_t dragonite_target =
-{
- .name = dragonite,
-
- .poll = arm7_9_poll,
- .arch_state = armv4_5_arch_state,
-
- .target_request_data = arm7_9_target_request_data,
-
- .halt = arm7_9_halt,
- .resume = arm7_9_resume,
- .step = arm7_9_step,
-
- .assert_reset = feroceon_assert_reset,
- .deassert_reset = arm7_9_deassert_reset,
- .soft_reset_halt = arm7_9_soft_reset_halt,
-
- .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
-
- .read_memory = arm7_9_read_memory,
- .write_memory = arm7_9_write_memory,
- .bulk_write_memory = feroceon_bulk_write_memory,
- .checksum_memory = arm7_9_checksum_memory,
- .blank_check_memory = arm7_9_blank_check_memory,
-
- .run_algorithm = armv4_5_run_algorithm,
-
- .add_breakpoint = arm7_9_add_breakpoint,
- .remove_breakpoint = arm7_9_remove_breakpoint,
- .add_watchpoint = arm7_9_add_watchpoint,
- .remove_watchpoint = arm7_9_remove_watchpoint,
-
- .register_commands = arm966e_register_commands,
- .target_create = dragonite_target_create,
- .init_target = feroceon_init_target,
- .examine = feroceon_examine,
- .quit = feroceon_quit
-};
-
int feroceon_dummy_clock_out(arm_jtag_t *jtag_info, uint32_t instr)
{
scan_field_t fields[3];
@@ -765,3 +679,82 @@ int feroceon_examine(struct target_s *target)
return ERROR_OK;
}
+
+target_type_t feroceon_target =
+{
+ .name = feroceon,
+
+ .poll = arm7_9_poll,
+ .arch_state = arm926ejs_arch_state,
+
+ .target_request_data = arm7_9_target_request_data,
+
+ .halt = arm7_9_halt,
+ .resume = arm7_9_resume,
+ .step = arm7_9_step,
+
+ .assert_reset = feroceon_assert_reset,
+ .deassert_reset = arm7_9_deassert_reset,
+ .soft_reset_halt = arm926ejs_soft_reset_halt,
+
+ .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
+
+ .read_memory = arm7_9_read_memory,
+ .write_memory = arm926ejs_write_memory,
+ .bulk_write_memory = feroceon_bulk_write_memory,
+ .checksum_memory = arm7_9_checksum_memory,
+ .blank_check_memory = arm7_9_blank_check_memory,
+
+ .run_algorithm = armv4_5_run_algorithm,
+
+ .add_breakpoint = arm7_9_add_breakpoint,
+ .remove_breakpoint = arm7_9_remove_breakpoint,
+ .add_watchpoint = arm7_9_add_watchpoint,
+ .remove_watchpoint = arm7_9_remove_watchpoint,
+
+ .register_commands = arm926ejs_register_commands,
+ .target_create = feroceon_target_create,
+
Re: [Openocd-development] why --disable-parport-ppdev ?
On Mon, 13 Jul 2009, Zach Welch wrote: On Wed, 2009-07-08 at 01:02 -0400, Nicolas Pitre wrote: Before, the ./configure --help used to list --enable-parport-ppdev instead of the current --disable-parport-ppdev. The later suggests that parport-ppdev is now set by default when using --enable-parport (which would be a good thing I think) but this is apparently not the case. Since I changed that text, I clearly meant for it to be enabled by default on x86; it always gets set on other hosts. When I factored that configure code, I also changed the help text. I thought that I got the logic right, but I just verified it to see if it was correct. It's not. The attached patch ensures this feature has been enabled when the user does not pass either option to the configure script. This may force some developers to add --disable-parport-ppdev, though I am not sure which platform(s) will require that. If others will ACK this, I can shove it into the trunk for 0.2.0. This seems like it could be a regression that I caused, and the fix appears easy and obvious. I certainly ACK the principle. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] why --disable-parport-ppdev ?
Before, the ./configure --help used to list --enable-parport-ppdev instead of the current --disable-parport-ppdev. The later suggests that parport-ppdev is now set by default when using --enable-parport (which would be a good thing I think) but this is apparently not the case. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license vs D2XX library
On Mon, 15 Jun 2009, David Brownell wrote: On Sunday 14 June 2009, Nicolas Pitre wrote: Now... who can make that call? Is there someone with code in OpenOCD who is against such a relicensing? Not the right process. Every OpenOCD copyright holder must explicitly agree. Lack-of-NAK is not the same thing as agreement. They contributed under a particular legal agreement. They can agree to change it later. It can't be changed for them. I'm looking for the easy solution first, that is, if only _one_ person provides a NACK then we simply forget about this relicensing idea right away (unless someone is willing to strip out that person's code and rewrite it which is silly IMHO). Personally I'd try to fix the libftdi issue first... if I was using Windows that is. Yet, it must be noted that libftd2xx is dynamically linked on Linux. If the Windows version is also a DLL then it is arguable whether or not they are already linked when the OpenOCD binary is distributed. Currently the library must be available for openocd to execute at all, but if dlopen() was used instead then the libftd2xx usage would be merely equivalent to a plugin. And aren't loadable modules for OpenOCD on the roadmap? Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license vs D2XX library
On Mon, 15 Jun 2009, Freddie Chopin wrote: Nicolas Pitre pisze: If libftd2xx is not statically linked, or even not distributed along with the compiled OpenOCD binary, then the case against it is highly arguable and far from being a black and white picture but rather a large gray spot. That's the problem, because OpenOCD compiled with --enable-ft2232_ftd2xx won't start if there is no ftd2xx.dll library somewhere. This solution is not good, because when one downloads a complete package, one expects it to just work. PPL who use wiggler and have no idea about FTDI would than be forced to learn about that, find the library somewhere and install (copy) it into the system. That's a technical issue with an easy solution. I wouldn't know how to go about it on Windows though, but on Linux this is only a matter of using dlopen() and a couple function pointers. Zach Welch was looking forward to make many parts of OpenOCD dynamically loadable. Maybe the FTDI support would be the best place to start with. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license vs D2XX library
On Mon, 15 Jun 2009, Zach Welch wrote: Nicolas, I figured a simple NACK would not suffice, given the range of topics this thread has covered. This is not all meant for you, as I expect you have heard these arguments once or twice in the past. :) I just wanted to post to this thread once (and for all). In all honesty, I'm playing devil advocate all along, and prodding for opinions with a stick. ;-) On Mon, 2009-06-15 at 00:28 -0400, Nicolas Pitre wrote: [snip] Now... who can make that call? Is there someone with code in OpenOCD who is against such a relicensing? Yes. OpenOCD *is* GPL. I would _not_ have contributed as much as I have to the code, if I thought anyone could later distribute versions with proprietary extensions. I will vehemently oppose and challenge all such use cases, though this statement deserves some clarification. Clarifications are good, but at least this settles the licensing issue, as I was expecting. I'm even surprised it took so long for someone to stand up and proclaim a veto. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license vs D2XX library
On Sat, 13 Jun 2009, David Brownell wrote: It's my understanding that verions of OpenOCD built using the libftd2xx library (FTDI's binary code) can not be redistributed without violating the OpenOCD license (GPL). http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs Reason: the libftd2xx code clearly isn't a system library since it's third-party code, and there's no license exception granted by OpenOCD. Unless someone has a particularly strong contrary argument (like relicensing all of OpenOCD) my suggestion is to merge the attached patch. It updates the User's Guide to discourage its use except in personal builds. Agreed. Furthermore, my own testing with both libraries showed libftd2xx marginally faster, and not many times faster as the doc is claiming. OTOH, libftdi is already packaged by most distributions. On Fedora you only need to do yum install libftdi-devel and you're set to compile openocd. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license vs D2XX library
On Sun, 14 Jun 2009, Xiaofan Chen wrote: On Sun, Jun 14, 2009 at 9:45 AM, Nicolas Pitren...@cam.org wrote: Furthermore, my own testing with both libraries showed libftd2xx marginally faster, and not many times faster as the doc is claiming. OTOH, libftdi is already packaged by most distributions. On Fedora you only need to do yum install libftdi-devel and you're set to compile openocd. I do not use FTDI based Jtag tools. But I think libftdi is based on libusb. So it will not work under Vista 64 bit (and the upcoming Windows 7 64bit) since libusb-win32 does not work under Vista 64. I presume this will get fixed eventually. Otherwise, strictly speaking, it is simply illegal to _distribute_ a compiled binary of openocd that works on Vista 64. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
On Sat, 30 May 2009, Øyvind Harboe wrote: On Fri, May 29, 2009 at 12:14 AM, David Brownell davi...@pacbell.net wrote: than just conform to JTAG spec. No problem when docs are available ... but sometimes they aren't. XScale is under Marvell NDA for instance :-) Some of it has been opened up: http://www.marvell.com/products/cellular/application/PXA3xx_series.jsp No idea if the JTAG interface is documented in there though. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 4/6] openocd.texi tweaks
On Sun, 31 May 2009, David Brownell wrote: Various updates, mostly small/formatting changes: * Small content tweaks: - Re-title: OpenOCD User's Guide. - For users, URLs for latest doc and SparkFun forum - Mention GIT-SVN You suggest: git svn clone svn://svn.berlios.de/openocd/trunk openocd I'd suggest this instead: git svn clone -s svn://svn.berlios.de/openocd The -s tells git-svn to assume svn standard layout for trunk, branches and tags, and then converts them into proper git branches and tags automatically. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: struct cleanup and more
On Sun, 31 May 2009, David Brownell wrote: On Sunday 31 May 2009, Zach Welch wrote: While I think this would help the code and documentation a lot, I would even go further to suggest s/_s// from all struct names. Most certainly. I realize there are coding conventions that promote such obfuscation, but given the least opportunity I will support non-obfuscated approaches instead. Agreed. If you're spelling it in full as a struct, then the _s suffix is redundant and could as well be removed. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] cut out the unknown EmbeddedICE version message with Feroceon
Feroceon is unusual and we know it. Stop complaining about that. diff --git a/src/target/embeddedice.c b/src/target/embeddedice.c index 31ac0b4..9d2be36 100644 --- a/src/target/embeddedice.c +++ b/src/target/embeddedice.c @@ -179,6 +179,13 @@ reg_cache_t* embeddedice_build_reg_cache(target_t *target, arm7_9_common_t *arm7 arm7_9-has_monitor_mode = 1; break; default: + /* +* The Feroceon implementation has the version number +* in some unusual bits. Let feroceon.c validate it +* and do the appropriate setup itself. +*/ + if (strcmp(target-type-name, feroceon) == 0) + break; LOG_ERROR(unknown EmbeddedICE version (comms ctrl: 0x%8.8x), buf_get_u32(reg_list[EICE_COMMS_CTRL].value, 0, 32)); } ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, 23 May 2009, David Brownell wrote: I see messages about needing to increase some GDB timeout/interval. But that's foolishness, since I'm not even working with GDB when they start spamming me. This is indeed really irritating. What about those messages being displayed only when a gdb connection is actually in use? Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] make SheevaPlug init more reliable
When the CPU is in the WFI state, the JTAG interface simply doesn't
respond at all and initial tap examination simply fails. Let's simply
do it again when we come around to assert nSRST.
diff --git a/src/target/board/sheevaplug.cfg b/src/target/board/sheevaplug.cfg
index 276d6f2..d1a0cce 100644
--- a/src/target/board/sheevaplug.cfg
+++ b/src/target/board/sheevaplug.cfg
@@ -17,7 +17,13 @@ proc sheevaplug_init { } {
# We need to assert DBGRQ while holding nSRST down.
# However DBGACK will be set only when nSRST is released.
+ # Furthermore, the JTAG interface doesn't respond at all when
+ # the CPU is in the WFI (wait for interrupts) state, so it is
+ # possible that initial tap examination failed. So let's
+ # re-examine the target again here when nSRST is asserted which
+ # should then succeed.
jtag_reset 0 1
+ feroceon.cpu arp_examine
halt 0
jtag_reset 0 0
wait_halt
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] more NAND cleanup and doc updates
On Sat, 23 May 2009, Zach Welch wrote:
On Fri, 2009-05-22 at 20:28 -0700, David Brownell wrote:
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The nand check_bad_blocks should report bad blocks. They
are not invalid blocks; they're bad ones.
(c) Tweak the nand info command to handle the no arguments
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
---
doc/openocd.texi| 37 +++-
src/flash/nand.c| 109
++
src/target/board/sheevaplug.cfg |2
3 files changed, 109 insertions(+), 39 deletions(-)
Committed as r1904.
FWIW, I just reviewed and tested those changes, and they are fine.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND documentation? My current notes...
On Fri, 22 May 2009, David Brownell wrote: On Thursday 21 May 2009, Nicolas Pitre wrote: On Thu, 21 May 2009, David Brownell wrote: I also noticed that two commands (erase, check_bad) are unusual in that they require *block* numbers as parameters, rather than the offsets used everywhere else in OpenOCD (and in U-Boot, and the Linux-MTD utilities). Comments on changing that to become more consistent, and holding off on documenting/committing-to the current interface until this issue is resolved? Uniformity is good. If you do this change, please don't forget to update existing scripts using those commands too. The only existing in-tree script using this is for SheevaPlug, which has nand erase 0 0 4. That should become nand erase 0 0 $X (*) where X is [expr $nand_block_size * 4] ... would you know the value of $nand_block_size? I'd guess that having a 4Gbit NAND means it's 2KB/page, 128KB/block. Exact. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] nand support
On Fri, 22 May 2009, David Brownell wrote: On Friday 22 May 2009, Sergey Lapin wrote: How hard it is po port that to at91sam9260? Shouldn't be hard to get basic soft-ecc working. Sort of like Orion ... I think the fast-download code there should be pulled out and made available for all ARMs with a DCC. Note that the actual fast download code is not in the orion NAND driver. It is already provided by the target support code. What you see in the orion driver is some code to transfer a page of data from the target's memory to the NAND controller. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Further simplifications in jtag.c
On Wed, 20 May 2009, Michael Bruck wrote: On Wed, May 20, 2009 at 12:05 AM, David Brownell davi...@pacbell.net wrote: (By the way, suggestion: only one patch per mail. It's painful enough to try reviewing attachments, especially text/plain ones that won't get the syntax highlighting that diffs do.) I don't think flooding the list with 10 mails is a good idea, especially if people start replying to the mails randomly. I must side with David here. Yes, please do flood the list with 10 emails (10 emails is not _that_ bad), and prefix your subject line with [PATCH 1/10] and so on. This way it is easy for people uninterested in such patches to skip/delete the entire series. The burden should be on the submitter side and not on the reviewers side. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND documentation? My current notes...
On Sun, 17 May 2009, David Brownell wrote: The following are some notes I put together about the nand commands based on reading the source code. I plan to turn them into documentation sometime later, maybe by this time next week. I've seen no documentation on the NAND commands; that seems like a significant omission. Meanwhile I thought I'd send them around for comments and corrections. Looks all fine to me. This matches my own understanding of the code. The == comments are things which seem like they deserve some action other than documenting the current status. One example is removing (or at least disabling) the nand copy command until it gets implemented. Implementing it in a generic way would be quite slow if the data has to make the round trip to the host and back to the target over the JTAG link. Ideally each controller driver would need to implement its own copy method which would involve uploading some code on the target in order to perform the copy directly. Still I don't see this as being really useful, otherwise someone would have implemented it by now. So disabling it is probably the best option for the moment. - Dave NAND COMMANDS = At this writing: - Only NAND devices with 512 or 2048 byte pages are handled properly. Older devices with 256 byte pages are rejected. == Erm, aren't chips with 4K pages mis-handled? At least in some paths. - ECC codes can be generated when pages are written, but are not used to correct errors when data is read ... unless maybe the underlying driver has a read_page() method which does so. - Writing a file to NAND, or reading it from NAND, ignores bad block markers. == Worth fixing, yes?? Just skipping bad blocks would match one common usage. If not, then at least report errors instead of writing there... - Every NAND device is associated with a target. == Hmm, so maybe that target should be stored in the NAND device instead of the controller-private data. And the lookup should be done by the NAND core not the individual drivers. Or ... should the syntax be TARGET nand ... since the drivers are generally SoC-specific? - Nothing verifies that pages are erased before writing. == Is that the same as NOR flash does? The way to use these starts with: nand device CONTROLLER TARGET [controller-options] ... to declare each NAND chip. For chips with two halves (e.g. a 2 GByte chip with two 1GB halves), declare each half separately. nand info ... to see what number it was given nand probe NUM ... to see what sort of chip is there Then you can use write to transfer data from a file to the NAND chip, or dump to go the other direction. Configuration - nand device CONTROLLER TARGET [controller-options] There are several built-in controllers, some of which have controller-specific options or controller-specific commands. This *must* go into a config/init script. lpc3180 - extra parameter: clock frequency - special command: lpc3180 select NUM [mlc|slc] There are two NAND controllers, one for SLC chips and the other for MLC. If a parameter is given, it selects that controller. The currently selected controller is displayed unless there is an error. - MLC controller seems to use hardware ECC logic... ? orion - extra parameter: address for the NAND chip - no special commands s3c2410 s3c2412 s3c2440 s3c2443 - no extra parameters - no special commands nand list Prints a one-line summary of each device found, numbered from zero. Note that un-probed devices show no details. nand probe NUM Probes the specified device to determine key characteristics including size, manufacturer, page size, and erase size Basic I/O - nand dump NUM filename offset length [oob_raw|oob_only] Reads binary data from the NAND chip and writes it to the file, starting at the specified offset. The offset and length must be an exact multiple of the chip's page size. No error correction is done on the data that's read, unless the controller has a read_page() which does that transparently. By default, only page data is saved to the specified file. Two options allow the OOB data to be saved: - oob_raw ... output file interleaves data and OOB data. - oob_only ... output file has only raw OOB data. nand erase NUM block_first block_last Erases blocks from first to last (inclusive), excepting bad blocks. Checks for bad blocks first, if needed. nand write NUM filename offset
Re: [Openocd-development] OpenOCD: Speed test on STR710 target
On Fri, 15 May 2009, Michael Fischer wrote: Hello list, I have it double check it here with a LPC2294 board, and the result looks like: - 657: 91KB/sec - 1606: 97KB/sec - 1787: 87KB/sec I do not understand this values. Here the 1606 is faster on a LPC target, but slower on a STR target. And the 1787 is slower than 1606 on a LPC target but had the same speed on a STR target. Try like 5 measurements for each versions. You may discover that speed measurement is not stable across multiple tests on the same version. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, David Brownell wrote: I'd also like to see a brief update about why this list adopts the unusual send as an attachment policy. Because one of the maintainer uses Windows and applying patches with cut and paste doesn't work so well? FWIW, I consider patches in attachment annoying as well. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, Øyvind Harboe wrote: Attachments are annoying, but they avoid lots of odd issues that crop up when email clients get too eager to help. Things like trailing spaces and tab to space conversion tends to happen. Attachments are preserved much better in general. If things are leaning towards a bug tracking system, we could keep patches in that system Personally, I consider bug tracking system even worse. Not that I contributed much to OpenOCD patch review (if at all) so far, but my time is just too limited for me to bother commenting on a patch that I have to save to a file then import back into my mailer in order to put my comments along side the parts of the patch I wish to comment on. Having to deal with a bug tracking system for commenting/reviewing patches constitute even more steps and is simply a turn-off for me. I'm deeply involved in a narrow part of the Linux kernel development, and in that world anything else but plain patches in the email body simply don't scale due to the manipulation overhead mentioned above. I do receive many many patches in my inbox every day. If I have the choice, I'll review patches for which I simply have to hit the reply button in my mailer and start inserting my comments inline right away over those that require any additional manipulations. With regard to mailers messing up tab and spaces... well, all I can say is that thousands of Linux developers do use mailers that can be made to preserve email body content, either by default or with some config settings since this is what the established patch review process requires. Many of those email clients are available on Windows and/or MAC too. And saving the email body to a file is usually just as easy as saving an attachment. Git even has a tool to pick up an email folder where you might have saved a bunch of patch-containing emails and apply them all. Note that I'm not asking for any particular requirements here. Simply stating how my review contribution is likely to be influenced by the patch channel. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On Fri, 15 May 2009, Øyvind Harboe wrote: My main reason for wanting patches in attachments is that I want a *single* format. Forcing attachments help. I'm more often able to apply those patches than the rest. The Linux process requires a _single_ patch format as well. In this mailing list there is also a lot of good contributions from developers who have their first encounter w/svn and patches... Those people can be told how to send their contributions properly with some documentation, regardless of the format. I don't care what that format is really. I just don't want to learn a new method to apply them each time. Indeed. Of course a single format is best. I'm just highlighting the fact that some communities already converged on a format that happens to be the most efficient given the volume of patches involved. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Performance of 1606 vs. svn head
On Wed, 13 May 2009, Øyvind Harboe wrote: Hi Nicolas, I'm starting a new thread, because I worry that I was not clear in regards to my question about the residual performance degradation you are seing in svn head(10% degradation). You were clear. I just didn't spare the time to perform further tests until now. I wonder if 1606 (before I made all these changes) is the *same* speed as svn head. Results with 1520: wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 88.213760s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 83.168205s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 93.108742s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 93.125557s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 88.274002s Results with 1606: wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 88.368996s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 87.641754s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 88.023758s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 85.983398s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 85.729759s Results with 1776: wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 83.168289s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 85.491020s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 86.183746s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 85.299507s wrote file uboot.bin to NAND flash 0 up to offset 0x00073000 in 86.606750s If 1606 and svn head is the same, then the 10% performance degradation you are seing happened between 1520 and 1606 presumably. Well, from results above, I think no conclusion is possible. There is simply too much variations. One could tell from the above that r1776 is faster on average, but I've seen it go in the 93 second range as well before, which led to my initial remark about possible residual regression. If anything, svn head doesn't appear any worse than 1606 or 1520 at this point. Another thing to test is to use verify_jtag disable that I added this morning to svn head... I prefer not disabling any kind of self check features for such an error prone communication link. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] All known regressions (functional and performance) fixed in svn head
On Wed, 13 May 2009, David Brownell wrote: On Wednesday 13 May 2009, Øyvind Harboe wrote: If you have any problems please report them. All known functional and performance regressions since 1606 are now fixed in svn head. Current GIT head no longer starts up correctly on dm355. It should find three TAPs: ICEpick, ARM926ejs, ETB11. But it only finds one. (Using an Olimex ft2232 adapter.) New symptoms compared to previous incarnations of this: (a) slowing JTAG clock doesn't help. (b) it sees the *second* device (ARM926ejs) not first. Bisection is futile since most of the intermediate checkins don't build on x86_64. Use ./configure with --disable-werror. I could achieve bisection that way. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] lower JTAG clock for SheevaPlug
3MHz is unreliable on some units while 2MHz appears to be fine. commit 343375ca7a3e004e02a4912b8ef660ffa991d901 Author: root r...@xanadu.home Date: Tue May 12 12:28:58 2009 -0400 SheevaPlug down to 2MHz JTAG clock diff --git a/src/target/interface/sheevaplug.cfg b/src/target/interface/sheevaplug.cfg index 7914ba0..556f44d 100644 --- a/src/target/interface/sheevaplug.cfg +++ b/src/target/interface/sheevaplug.cfg @@ -8,5 +8,5 @@ interface ft2232 ft2232_layout sheevaplug ft2232_vid_pid 0x9e88 0x9e8f ft2232_device_desc SheevaPlug JTAGKey FT2232D B -jtag_khz 3000 +jtag_khz 2000 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] trunk broken since rev 1730 (segfault)
On Tue, 12 May 2009, Øyvind Harboe wrote: On Tue, May 12, 2009 at 6:39 PM, Nicolas Pitre n...@cam.org wrote: About performance: things are reasonable again. It takes 90 seconds to flash 450 KB to NAND instead of 5 minutes. But in the days of rev 1520 this was like 80 seconds, so there is still a slight regression left there. Any chance you can check if that residual performance regression is somewhere between 1520 and 1606? What I was saying is that, compared to 1520, the current head is like 10% slower. But it is way better than 1729 which was 4 times slower. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] 4-bit ECC support for Marvell Kirkwood SOC
On Tue, 12 May 2009, David Brownell wrote: On Tuesday 12 May 2009, Nicolas Pitre wrote: The Kirkwood bootrom expects 4-bit ECC from NAND. This adds 4-bit ECC computation to the NAND support and uses it with SheevaPlug. Hmm, from the outside this sounds like the 4-bit ECC in some TI DaVinci family chips: 10 bytes ECC per 512 bytes data, delivered as eight 10-bit values. Isn't ECC on the Davinci computed in hardware by the NAND controller? But otherwise it is a Reed-Solomon implementation using a x^10 + x^3 + 1 polinomial. Anyone with the same ECC characteristics may reuse this code quite trivially. Stay tuned for Linux support soon as well. Maybe some of this should share code ... probably not the compute backwards part though! No comment ... Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head build issues
On Mon, 11 May 2009, Øyvind Harboe wrote: 2009/5/11 Nicolas Pitre n...@cam.org: cc1: warnings being treated as errors jtag.c: In function ‘jtag_check_value_mask_callback': jtag.c:703: error: cast from pointer to integer of different size jtag.c: In function ‘jtag_add_scan_check': jtag.c:740: error: cast to pointer from integer of different size Is this a 64 bit host? Yes. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head build issues
On Mon, 11 May 2009, Øyvind Harboe wrote:
On Mon, May 11, 2009 at 5:25 PM, Nicolas Pitre n...@cam.org wrote:
On Mon, 11 May 2009, Øyvind Harboe wrote:
2009/5/11 Nicolas Pitre n...@cam.org:
cc1: warnings being treated as errors
jtag.c: In function ‘jtag_check_value_mask_callback':
jtag.c:703: error: cast from pointer to integer of different size
jtag.c: In function ‘jtag_add_scan_check':
jtag.c:740: error: cast to pointer from integer of different size
Is this a 64 bit host?
Yes.
Hmm so what's the correct way to cast a void * to an int (keeping only
as many bits as will fit in an int) on a 64 bit system?
You cast to a long first, like:
diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c
index 0be66c2..b59d02d 100644
--- a/src/jtag/jtag.c
+++ b/src/jtag/jtag.c
@@ -700,7 +700,7 @@ int jtag_check_value_inner(u8 *captured, u8
*in_check_value, u8 *in_check_mask,
static int jtag_check_value_mask_callback(u8 *in, jtag_callback_data_t data1,
jtag_callback_data_t data2, jtag_callback_data_t data3)
{
- return jtag_check_value_inner(in, (u8 *)data1, (u8 *)data2, (int)data3);
+ return jtag_check_value_inner(in, (u8 *)data1, (u8 *)data2,
(int)(long)data3);
}
static void jtag_add_scan_check(void (*jtag_add_scan)(int num_fields,
scan_field_t *fields, tap_state_t state),
@@ -737,7 +737,7 @@ static void jtag_add_scan_check(void (*jtag_add_scan)(int
num_fields, scan_field
if ((fields[i].check_value!=NULL)(fields[i].in_value!=NULL))
{
/* this is synchronous for a minidriver */
- jtag_add_callback4(jtag_check_value_mask_callback,
fields[i].in_value, fields[i].check_value, fields[i].check_mask,
(jtag_callback_data_t)fields[i].num_bits);
+ jtag_add_callback4(jtag_check_value_mask_callback,
fields[i].in_value, fields[i].check_value, fields[i].check_mask,
(jtag_callback_data_t)(long)fields[i].num_bits);
}
if (fields[i].allocated)
{
This however starts to become really ugly and deserves some comment as
to why such trickery is used. Even the original code might benefit from
some explanation for those casts.
Alternatively I could use a less clever scheme and have a union of int
void *...
I'd say clearer and cleaner rather than less clever. Generated code
would be the same, except on big endian 64-bit machines where you'd end
up keeping the top pointer bits instead. In that case you'd need an
union definition where a dummy int would need to be inserted as padding.
Probably the cleanest solution would be to encapsulate the two casts
within a macro, and put a nice comment above the macro definition to
explain why this is done. Similar to:
/*
* We don't care about the real pointer but only the low 32 bits of it
* for some funky hash lookup. The double cast removes warnings on
* 64-bit machines.
*/
#define PTR_TO_HASH(X) ((int)(long)(x))
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head build issues
On Mon, 11 May 2009, Nicolas Pitre wrote: On Mon, 11 May 2009, Øyvind Harboe wrote: 2009/5/11 Nicolas Pitre n...@cam.org: cc1: warnings being treated as errors jtag.c: In function ‘jtag_check_value_mask_callback': jtag.c:703: error: cast from pointer to integer of different size jtag.c: In function ‘jtag_add_scan_check': jtag.c:740: error: cast to pointer from integer of different size Is this a 64 bit host? Yes. More of those: cc1: warnings being treated as errors arm7tdmi.c: In function ‘arm7endianness': arm7tdmi.c:249: error: cast from pointer to integer of different size arm7tdmi.c:249: error: cast from pointer to integer of different size arm7tdmi.c: In function ‘arm7tdmi_clock_data_in_endianness': arm7tdmi.c:281: error: cast to pointer from integer of different size arm7tdmi.c:281: error: cast to pointer from integer of different size Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head build issues
On Mon, 11 May 2009, Øyvind Harboe wrote: /* * We don't care about the real pointer but only the low 32 bits of it * for some funky hash lookup. The double cast removes warnings on * 64-bit machines. */ #define PTR_TO_HASH(X) ((int)(long)(x)) Any reason not to use an inline fn? That would throw in some typechecking Good point. Would you care to formulate a patch since you have a 64 bit system handy? Sure. I'd need some actual explanation for this game though. The above was only wild guessing without looking deeply at the code. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn head build issues
On Mon, 11 May 2009, Øyvind Harboe wrote: OK. Try patch attached. Builds on Cygwin(x86 32 bits). Works for me on x86-64. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] trunk broken since rev 1730 (segfault)
This is a really nasty breakage since the symptom consists of stack
corruption. In my case, I was able to observe the problem by adding
some printf's in src/flash/nand.c with the execution path below.
src/flash/nand.c, line 1200, in handle_nand_erase_command():
p = get_nand_device_by_num(strtoul(args[0], NULL, 0));
if (p)
{
int first = strtoul(args[1], NULL, 0);
int last = strtoul(args[2], NULL, 0);
if ((retval = nand_erase(p, first, last)) == ERROR_OK)
[...]
Here the variable p is assigned the same value as the global variable
nand_devices because there is only one device. Then p is passed to
nand_erase(). So far so good.
src/flash/nand.c, line 697, in nand_erase():
retval = device-controller-nand_ready ?
device-controller-nand_ready(device, 1000) :
nand_poll_ready(device, 1000);
Here the variable p is called device instead. Just before the code
above, the global variable nand_devices and local variable device have
the same value as before. So far so good. nand_poll_ready() is called
with the value of the local variable device.
src/flash/nand.c, line 410, in nand_poll_ready():
More instrumentation within nand_poll_ready() still shows that global
nand_devices and local device are the same. A call to
device-controller-read_data() is performed, which in my case is
orion_nand_read() wrapping a call to target_read_u8(). So far so good.
src/flash/nand.c, line 700, back in nand_erase():
As soon as nand_poll_ready() returns, then the _local_ variable device
is corrupted!!! The global variable nand_devices is still unchanged,
but local variable device is crap, pointing to a bad address. On line
705 the call to nand_read_status() is passing that bad device pointer,
and a segmentation fault occurs within that function.
Now this is extremely worrisome that a local variable on the stack gets
corrupted by some buggy code down the call chain of target_read_u8().
Backing to rev 1729 apparently fixes the issue, but I can't tell if at
that point the corruption simply moved elsewhere unnoticed.
Also, rev 1729 is dog slow for NAND flashing. It takes more than 5
minutes to flash 400KB, while before the recent shurn it took only 80
secs. USB performance is supposed to be back in latest svn trunk but I
can't test it.
The host machine is a x86-64 running Fedora 10 while the target is a
Feroceon/SheevaPlug.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
