[Openocd-development] OpenOCD error handling
Here are the rules as of writing(quick writeup): The return value/error handling in OpenOCD is very loosely modeled on exceptions in C++/Java/etc. Jim Tcl has exceptions too and the model below fits that reasonably well. - unless a fn *explicitly* documents it's return values, then the calling code should treat the return value as a boolean success/failure. - the primary return value is *only* used in cases where the calling code may need to take alternate action based on precisely what failed. - the primary return value should be propagated unmodified to the caller. This is *not* done robustly today so anyone relying on checking the return value should not rely on numerous levels of API's to propagate the return value unmodified. - if there are multiple errors, then the *first* error is returned (this applies to queues commands in the JTAG API). - user legible error messages are reported at the site of failure by LOG_ERROR(). These rules should be documented in the developer manual, but this thread will be useful to collect anything I've missed. Patch to fix syntax error handling to follow shortly. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix error messages for invalid arguments
Committed.
Invalid arguments now print out a human legible error messages.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/command.c
===
--- src/helper/command.c(revision 2460)
+++ src/helper/command.c(working copy)
@@ -867,15 +867,27 @@
int parse##name(const char *str, type *ul) \
{ \
if (!*str) \
+ { \
+ LOG_ERROR(Invalid command argument); \
return ERROR_COMMAND_ARGUMENT_INVALID; \
+ } \
char *end; \
*ul = func(str, end, 0); \
if (*end) \
+ { \
+ LOG_ERROR(Invalid command argument); \
return ERROR_COMMAND_ARGUMENT_INVALID; \
+ } \
if ((max == *ul) (ERANGE == errno)) \
+ { \
+ LOG_ERROR(Argument overflow); \
return ERROR_COMMAND_ARGUMENT_OVERFLOW; \
+ } \
if (min (min == *ul) (ERANGE == errno)) \
+ { \
+ LOG_ERROR(Argument underflow); \
return ERROR_COMMAND_ARGUMENT_UNDERFLOW; \
+ } \
return ERROR_OK; \
}
DEFINE_PARSE_NUM_TYPE(_ulong, unsigned long , strtoul, 0, ULONG_MAX)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix error messages for invalid arguments
Committed.
Try to use tabs instead of spaces.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/command.c
===
--- src/helper/command.c(revision 2464)
+++ src/helper/command.c(working copy)
@@ -875,17 +875,17 @@
*ul = func(str, end, 0); \
if (*end) \
{ \
- LOG_ERROR(Invalid command argument); \
+ LOG_ERROR(Invalid command argument); \
return ERROR_COMMAND_ARGUMENT_INVALID; \
} \
if ((max == *ul) (ERANGE == errno)) \
{ \
- LOG_ERROR(Argument overflow); \
+ LOG_ERROR(Argument overflow); \
return ERROR_COMMAND_ARGUMENT_OVERFLOW; \
} \
if (min (min == *ul) (ERANGE == errno)) \
{ \
- LOG_ERROR(Argument underflow); \
+ LOG_ERROR(Argument underflow); \
return ERROR_COMMAND_ARGUMENT_UNDERFLOW; \
} \
return ERROR_OK; \
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD error handling
- unless a fn *explicitly* documents it's return values, then the calling code should treat the return value as a boolean success/failure. - as a result of this rule using ERROR_FAIL is generally recommended where the calling code should not be expected to take special action but treat it as a boolean success/failure i.e. in just about all cases. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Cygwin build issues and proposals
On Sat, Jul 4, 2009 at 2:46 AM, Martin Thomasmtho...@rhrk.uni-kl.de wrote: the build process continued a little bit further but stopped with an error in replacements (don't remember the exact message). This error has been caused by usage of stdint.h typdefs but stdint.h has not been included. After adding #include stdint.h at the top of replacements.h the build went trough and generated openocd.exe (not yet tested with hardware). Maybe src/Makefile.am and replacments.h can be modified a little bit to increase compatibility with (maybe just my) cygwin-environment. I have similar issues with replacement.h with a cross-build of OpenOCD with MinGW under Linux. I added types.h to solve the problem. I do not know if it is a proper fix or not. It has been a while since i built for win32 on linux - looks like it is now a bit broken. Try this patch it fixes a few other things with regards to x-compiling. Tested on ubuntu64 9.04 Cheers Spen mingw-x-patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Simplify debug_reason check
Committed.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm7_9_common.c
===
--- src/target/arm7_9_common.c (revision 2460)
+++ src/target/arm7_9_common.c (working copy)
@@ -1431,18 +1431,10 @@
context[15] -= 3 * 4;
}
- if ((target-debug_reason == DBG_REASON_BREAKPOINT)
- || (target-debug_reason == DBG_REASON_SINGLESTEP)
- || (target-debug_reason == DBG_REASON_WATCHPOINT)
- || (target-debug_reason == DBG_REASON_WPTANDBKPT)
- || ((target-debug_reason == DBG_REASON_DBGRQ)
(arm7_9-use_dbgrq == 0)))
+ if ((target-debug_reason != DBG_REASON_DBGRQ) || (!arm7_9-use_dbgrq))
context[15] -= 3 * ((armv4_5-core_state == ARMV4_5_STATE_ARM)
? 4 : 2);
- else if (target-debug_reason == DBG_REASON_DBGRQ)
- context[15] -= arm7_9-dbgreq_adjust_pc * ((armv4_5-core_state
== ARMV4_5_STATE_ARM) ? 4 : 2);
else
- {
- LOG_ERROR(unknown debug reason: %i, target-debug_reason);
- }
+ context[15] -= arm7_9-dbgreq_adjust_pc * ((armv4_5-core_state
== ARMV4_5_STATE_ARM) ? 4 : 2);
if (armv4_5_mode_to_number(armv4_5-core_mode)==-1)
return ERROR_FAIL;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Mingw build
Somehow cross build with ftd2xx and libftdi do not work for me yet. I just tried the process under Ubuntu 9.04. 1) With libftdi, it chocked at the test program building. With normal build under Linux, it works. ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode --disable-shared --enable-ft2232_libftdi ... checking Build Link with libftdi.. configure: error: Cannot build run test program using libftdi 2) With ftd2xx ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode --disable-shared --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mcuee/Desktop/build/openocd/l ibftd2xx-win32 ... checking for ftd2xx.lib exists (win32)... checking whether ftd2xx library works... configure: error: Cannot build run test program using ftd2xx.lib try the following patch: https://lists.berlios.de/pipermail/openocd-development/2009-July/009145.html Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD error handling
On Monday 06 July 2009, Øyvind Harboe wrote: - unless a fn *explicitly* documents it's return values, then the calling code should treat the return value as a boolean success/failure. You're talking about C codes, right? There's more that should be said about returning values from Tcl commands ... so that scripts can use them. Right now it's somewhat unusual for values to be returned in a form that they're usable from Tcl; awkward. And in the same way, it's unusual for commands to do anything other than succeed -- even when given bad inputs. I'd like to see those stories improve, so that it becomes more practical to write robust scripts. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Cygwin build issues and proposals
On Mon, 2009-07-06 at 10:26 +0100, Spencer Oliver wrote: On Sat, Jul 4, 2009 at 2:46 AM, Martin Thomasmtho...@rhrk.uni-kl.de wrote: the build process continued a little bit further but stopped with an error in replacements (don't remember the exact message). This error has been caused by usage of stdint.h typdefs but stdint.h has not been included. After adding #include stdint.h at the top of replacements.h the build went trough and generated openocd.exe (not yet tested with hardware). Maybe src/Makefile.am and replacments.h can be modified a little bit to increase compatibility with (maybe just my) cygwin-environment. I have similar issues with replacement.h with a cross-build of OpenOCD with MinGW under Linux. I added types.h to solve the problem. I do not know if it is a proper fix or not. It has been a while since i built for win32 on linux - looks like it is now a bit broken. Try this patch it fixes a few other things with regards to x-compiling. Tested on ubuntu64 9.04 I would like to see the #include types.h moved into the #ifndef HAVE_ELF_H block, as that code is creating the problems. Otherwise, looks good for 0.2.0. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD error handling
On Mon, Jul 6, 2009 at 11:54 AM, David Brownelldavi...@pacbell.net wrote: On Monday 06 July 2009, Ųyvind Harboe wrote: - unless a fn *explicitly* documents it's return values, then the calling code should treat the return value as a boolean success/failure. You're talking about C codes, right? Yes. There's more that should be said about returning values from Tcl commands ... so that scripts can use them. Can you give some examples of where tcl scripts would do anything but catch exceptions as a boolean fail/succeed? Should we rely on tcl scripts for anything more complicated? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
On Monday 06 July 2009 12:11:42 Øyvind Harboe wrote: I'm trying to do a bisection. It broke somewhere between 1600 svn head. Any arm926ejs testers out there? How is it broken? I think I'm using it correctly (r2240 and others) Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
2009/7/6 Raúl Sánchez Siles rsanch...@infoglobal.es: On Monday 06 July 2009 12:11:42 Øyvind Harboe wrote: I'm trying to do a bisection. It broke somewhere between 1600 svn head. Any arm926ejs testers out there? How is it broken? I think I'm using it correctly (r2240 and others) on wi-9c.cfg which I'm testing against reset run + halt does not work. step sits in an infinite loop(or times out now). Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
What arm926ejs target are you using? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm926ejs is broken in 0.2
I'm trying to do a bisection. It broke somewhere between 1600 svn head. Any arm926ejs testers out there? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/3] NEWS and Release Updates
This series adds content to the NEWS file, then updates the release process documentation to describe its usage and treatment. During this, several other updates were made to the release process, fixing some design bugs and improving its readability. The release.sh script has been committed to the repository, allowing others to compare the documentation with the implementation. I will commit these patches shortly, so any contributions (by way of feedback) can be based off of the trunk. 1/3 Add NEWS file for the 0.2.0 release. 2/3 The late birth of the NEWS file also caused me to revisit the release 3/3 Update Release Script documentation to reflect current implementation. --- Summary of Patches 1-3: NEWS | 81 - doc/manual/release.txt | 62 - 2 files changed, 120 insertions(+), 23 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] Add NEWS file for the 0.2.0 release.
Add NEWS file for the 0.2.0 release. --- NEWS | 81 ++- 1 file changed, 80 insertions(+), 1 deletion(-) Add NEWS file for the 0.2.0 release. --- NEWS | 81 ++- 1 file changed, 80 insertions(+), 1 deletion(-) == only in patch2: unchanged: --- NEWS (revision 2473) +++ NEWS (working copy) @@ -1 +1,80 @@ -This document is not in use. See mailing list - https://lists.berlios.de/pipermail/openocd-development +The OpenOCD 0.2.0 source archive release includes numerous improvements +that were made since the initial 0.1.0 source archive release. Many +contributors helped make this release a great success, and the community +of developers and maintainers look forward to any response. + +In addition to the list of changes below, countless bug fixing and +cleaning was performed across the tree. Various TCL command parameters +must past stricter value checks, and many more error conditions have +been handled correctly. These efforts helped to make the 0.2.0 release +more stable and robust, though some changes may expose latent bugs in +your existing configuration scripts. + +This release does not maintain backward compatibility in all respects, +so some target or configuration scripts may need to be updated. In some +cases, you may also see warnings; resolve those, because they indicate +commands that will be removed in the future. + +The following areas of OpenOCD functionality changed in this release: + +JTAG Layer: +- Improves modularity: core, TCL, driver commands, and interface have + been separated, encapsulated, and documented for developers. Mostly. +- Improves JTAG TAP transition tables: + * Makes TAP paths variable length, rather than being fixed at 7 steps. + * Fixes problems with some targets that did not like longer paths. +- Improves JTAG driver/minidriver modularity and encapsulation. +- New drivers: + * Adds stub minidriver for developing new embedded JTAG interfaces. +- Improves drivers: + * ft2232+ftd2xx: + + Adds initial high-speed device support: --enable-ftd2xx-highspeed + + Supports more types of FTDI-based devices. + * jlink: + + Works with more versions of the firmware (v3 and newer) + + Supports dynamically detects device capabilities and limits + * vsllink: + + Supports very long scan chains + * amtjtagaccel: + + Fixes broken ID code detection problems. + +Target Layer: +- New devices: AVR, FA526 +- Improved support: ARM ADI, ARM11, MIPS +- Numerous other bug fixes and improvements + +Flash Layer: +- Improved drivers: mflash +- New drivers: AT91SAM3, AVR, Davinci NAND + +Board, Interface, and Target Configuration Scripts: +- Many new and improved targets and boards are now available. +- Better separation of board and target configuration +- Moved all TCL files to top-level tcl directory in the source tree +- Installation moved from '$pkglibdir/' to '$pkgdatadir/scripts/'. +- Site-specific files should be installed under '$pkgdatadir/site/'; + files that exist this tree will be used in preference to default + distribution configurations in '$pkgdatadir/scripts/'. + +Documentation: +- Updated User Guide: http://openocd.berlios.de/doc/html/index.html + * Partially re-written and re-organized. + * Standardized presentation for all commands. + * Covers many drivers and commands that were previously omitted. + * New index for commands and drivers. +- Added Developer Manual: http://openocd.berlios.de/doc/doxygen/index.html + * Now includes architecture, technical primers, style guides, and more. + * Available in-tree and on-line. + +Build and Release: +- Increased configuration and compilation warning coverage. + * Use --disable-werror to work around build errors caused by warnings. +- Use libtool to produce helper libraries as a step toward libopenocd. +- New processes and scripting to facilitate future source releases. + +For more details about what has changed since 0.1.0, see the ChangeLog +associated with this release. + +For more information about contributing test reports, bug fixes, or new +features and device support, please read the new Developer Manual (or +the BUGS and PATCHES files in the source archive). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] Update Release Script documentation to reflect current implementation.
Update Release Script documentation to reflect current implementation. --- release.txt | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) Update Release Script documentation to reflect current implementation. --- release.txt | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) == diff -u doc/manual/release.txt doc/manual/release.txt --- doc/manual/release.txt (working copy) +++ doc/manual/release.txt (working copy) @@ -267,7 +267,7 @@ The following output was taken from the release script: @verbatim -usage: tools/release.sh command +usage: tools/release.sh [options] command Main Commands: info Show a summary of the next pending release. @@ -303,6 +303,20 @@ Run codetools/release.sh help/code for current command support. +...@subsection releasescriptenv Release Script Options + +The @c release.sh script recognizes some command-line options that +affect its behavior: + +- @c --live : Use this option to perform a live release. + When this option has been given, the release commands will affect + the repository; otherwise, the script reports the actions to take, + and it produces archives that are unsuitable for public release. + +...@note Only the Release Manager should use the @c --live option, as +it will make permanent changes to the Subversion repository that +cannot be undone. + @subsection releasescriptenv Release Script Environment The @c release.sh script recognizes some environment variables which @@ -310,18 +324,13 @@ - @c CONFIG_OPTS : Passed as options to the configure script. - @c MAKE_OPTS : Passed as options to the 'make' processes. -- @c RELEASE_DRY_RUN : Set this to null to perform the live release. - Unless this variable has been (un)set, the release commands will not - affect the repository. - -Proper option handling should be added to set these variables in script. @section releasetutorial Release Tutorials This section provides tutorials for using the Release Script to perform common release tasks. -...@subsection releasetutorialminor Minor Release Tutorial +...@subsection releasetutorialsetup Release Tutorial Setup The tutorials in this section assume the following environment variables have been set properly: ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/3] The late birth of the NEWS file also caused me to revisit the release
The late birth of the NEWS file also caused me to revisit the release
process once again and reconsider it in some detail. In doing so,
some further revisions to the process were required:
1) The URL of the repository is embedded in the released code.
- The packages need to be created from the tagged branch.
- The URL then points to where to get the tagged code.
2) Improve the instructions for NEWS handling.
- NEWS file must be updated for each release; describe that process.
- The NEWS file should be archived an recreated for each release.
3) Add detail steps for the berliOS release process.
4) Minor cleanups to release process doxygen markup.
---
release.txt | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
The late birth of the NEWS file also caused me to revisit the release
process once again and reconsider it in some detail. In doing so,
some further revisions to the process were required:
1) The URL of the repository is embedded in the released code.
- The packages need to be created from the tagged branch.
- The URL then points to where to get the tagged code.
2) Improve the instructions for NEWS handling.
- NEWS file must be updated for each release; describe that process.
- The NEWS file should be archived an recreated for each release.
3) Add detail steps for the berliOS release process.
4) Minor cleanups to release process doxygen markup.
---
release.txt | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
==
only in patch2:
unchanged:
--- doc/manual/release.txt (revision 2473)
+++ doc/manual/release.txt (working copy)
@@ -190,19 +190,14 @@
The following steps should be followed to produce each release:
-# Produce final patches to the trunk (or release branch):
- -# add NEWS item to describe the release changes? (not ready for 0.2.0)
-- the community should try to help produce this material
-- can be used to automatically post blurbs about the project.
+ -# Finalize @c NEWS file to describe the changes in the release
+- This file is Used to automatically post blurbs about the project.
+- This material should be produced during the development cycle.
+- Add a new item for each @c NEWS-worthy contribution, when committed.
-# bump library version if our API changed (not yet required)
-# Remove -in-development tag from package version:
-- For major/minor releases, remove version tag from trunk.
+- For major/minor releases, remove version tag from trunk, @a or
- For bug-fix releases, remove version tag from release branch.
--# Produce and verify the binary packages:
- -# Start with a clean working copy, used for producing releases only.
- -# produce a ChangeLog for the release (using svn2cl).
- -# bootstrap, configure, and build the package.
- -# run 'make distcheck' to produce the distribution archives.
- -# run 'make maintainer-clean'; verify the repository is empty again.
-# Branch or tag the required tree in the Subversion repository:
- Tags and branches for releases must be named consistently: @par
${PACKAGE_TARNAME}-${PACKAGE_VERSION}
@@ -218,23 +213,37 @@
svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
@endverbatim
-# Prepare to resume normal development activities:
+ - Archive @c NEWS file as codedoc/news/NEWS-${PACKAGE_VERSION}/code.
+ - Create a new @c NEWS file for the next release
- For major/minor release from the trunk:
-# Bump major or minor package version in trunk.
-# Restore version tag to trunk and release branch.
- For bug-fix releases from a release branch:
-# Bump bug-fix version in release branch.
-# Restore version tag to release branch.
+-# Produce the package source archives:
+ -# Start with a clean working copy, used for producing releases only.
+ -# Switch to release tag branch: svn switch .../${RELEASE_TAG}
+ -# produce a ChangeLog for the release (using svn2cl).
+ -# @c bootstrap, @c configure, and @c make the package.
+ -# Run codemake distcheck/code to produce the distribution archives.
+ -# Run codemake maintainer-clean/code verify the repository is empty.
-# Publish documentation for the release:
- Allow users to access the documentation for each of our releases.
- Place static copies of the following files on the project website:
-- NEWS: to provide a blurb for each release (not yet used)
-- ChangeLog: to show exactly what has been changed
+- @c NEWS: to provide a blurb for each release
+- @c ChangeLog: to show exactly what has been changed
- User Guide, Developer Manual: to allow easy on-line viewing
-# Upload packages and post announcements of their availability:
- -# Release packages into files section of berliOS project site.
+ -# Release packages into files section of berliOS project site:
+ -# Create the new release for the new version.
+ -# Provide @c NEWS and ChangeLog files, as
[Openocd-development] 0.2.0 release... on hold?
Hi all, With my latest series of commits, I believe that the release process is finally ready to see action. That said, we have seen a bit of bug-fixing activity during the time that I have been preparing, and several new patches have hit the repository. The countdown is on hold. The new changes for arm7_9_common.c and arm926ejc.c need to be given time to ensure they work on all targets being tested for the release. Honestly, I am tempted to ask for them to reverted for the time being, as I cannot trivially determine their correctness after casual review. Of course, these were not given time for review in the first place; given the pending release, this was a major faux pas and cannot escape mention as such. :/ Since it appears that they do not help the ARM926EJS problems that were reported after the commits, perhaps reverting them may be the best path If not, I want to understand why we should keep them for 0.2.0. Again, such explanations should have been provided with the e-mail descriptions or commit message. I hate to make an example out of these changes, but I want the community to handle these issues better in the future. What do others think about these changes? Are they safe to keep, or should we revert them to make the release? If we keep them without confirmation, I want to wait until the community provides feedback confirming that nothing has broken. In this respect, I think the release process deserves to be put on hold, until the changes are reverted or have been explained fully and confirmed to be correct. Personally, I would prefer to hear confirmation that they are good. Other than those changes, fixes for MinGW32 cross-compiling are pending to be committed, but I cannot think of any other issues that have a solution waiting to be tested. Maintainers: please commit ONLY patches that have been reviewed by the mailing list for at least 12 hours. These should be confirmed by others that the changes fix problems (or have benefit) for the community. If feedback to this thread indicates that we are ready, I will produce the 0.2.0 release about 12 hours after the last patches are committed. Each new patch that is committed will reset the release clock. Does this sound reasonable to everyone? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
I've determined that single stepping is busted for svn head arm926ejs using parport against wi-9c.cfg (bisecting this now). One concern that I have with 0.2 is that it contains a lot of *great* refactoring work, but this is unobservable to the casual user. It will take a *long* time get testing done for all types of targets. Testing really has to be done on svn head anyway... From this point of view 0.1 is much better because there was a lot less development going on prior to 0.1 release... What about cutting a 0.2 branch now(going back a few svn versions if necessary) and leaving arm926ejs for 0.3? Perhaps we can backport a few things from svn head? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix step regression in 2190
Committed.
(GDB single stepping not affected)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/target.c
===
--- src/target/target.c (revision 2477)
+++ src/target/target.c (working copy)
@@ -2039,15 +2039,18 @@
* with one argument addr = args[0],
* handle breakpoints, debugging */
uint32_t addr = 0;
+ int current_pc = 1;
if (argc == 1)
{
int retval = parse_u32(args[0], addr);
if (ERROR_OK != retval)
return retval;
+ current_pc = 0;
}
target_t *target = get_current_target(cmd_ctx);
- return target-type-step(target, 0, addr, 1);
+
+ return target-type-step(target, current_pc, addr, 1);
}
static void handle_md_output(struct command_context_s *cmd_ctx,
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm926ejs i.MX27 testers out there
Are there any arm926ejs and/or i.MX27 testers out there? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. Regards, Dominic Original-Nachricht Datum: Mon, 6 Jul 2009 16:19:46 +0200 Von: Øyvind Harboe oyvind.har...@zylin.com An: openocd-development@lists.berlios.de Betreff: [Openocd-development] arm926ejs i.MX27 testers out there Are there any arm926ejs and/or i.MX27 testers out there? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- -- Dominic Rath dominic.r...@gmx.de ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
When I try to burn flash on a ADuC7021 using the ADuC702x.cfg I get a a crash. (traceback attached) in aduc7021.cfg if I comment out the following line it works $_TARGETNAME configure -work-area-phys 0x1 -work-area-size 0x2000 it just takes a LONG time - of course) The lines below the HALT can be commented out with no effect. I included them here because they were active during this traceback --- Main command file telnet_port tcl_port gdb_port source [find interface/olimex-jtag-tiny.cfg] source [find target/aduc702x.cfg] init halt # Write to MEMMAP to enable access to flash below first 64 bytes mwh 0xf804 0x8 #setup POWCON register to obtain the default 5.22MHz (RC osc) clock. # POWKEY1 = 0x01; mwh 0x0404 0x01 # POWCON = 0x0; mwh 0x0408 0x0 # POWKEY2 = 0xF4; mwh 0x040c 0xf4 --- I then erase flash and issue: flash write_image file.elf 0x8 elf tom (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. target_buffer_get_u32 (target=0x9465a20, buffer=0x948b000 Address 0x948b000 out of bounds) at ../../src/helper/types.h:80 80 return (uint32_t)(buf[0] | buf[1] 8 | buf[2] 16 | buf[3] 24); (gdb) where #0 target_buffer_get_u32 (target=0x9465a20, buffer=0x948b000 Address 0x948b000 out of bounds) at ../../src/helper/types.h:80 #1 0x0806f642 in arm7_9_write_memory (target=0x9465a20, address=65600, size=4, count=1750, buffer=0x948b004 Address 0x948b004 out of bounds) at arm7_9_common.c:2458 #2 0x0806e935 in arm7_9_bulk_write_memory (target=0x9465a20, address=65600, count=1750, buffer=0x948ad30 ) at arm7_9_common.c:2664 #3 0x08061c8d in target_write_buffer (target=0x9465a20, address=65600, size=7000, buffer=0x948ad30 ) at target.c:1167 #4 0x080b7261 in aduc702x_write (bank=0x946ad40, buffer=0x948ad30 , offset=0, count=7176) at aduc702x.c:284 #5 0x0805e80b in flash_driver_write (bank=0x946ad40, buffer=0x0, offset=0, count=38676) at flash.c:94 #6 0x0805f2c0 in flash_write (target=0x9465a20, image=0xbfa4da24, written=0xbfa4da58, erase=0) at flash.c:1138 #7 0x0805fead in handle_flash_write_image_command (cmd_ctx=0x94657e8, cmd=0x9477ee8 write_image, args=0x94595bc, argc=3) at flash.c:699 #8 0x0809c3cc in run_command (context=0x94657e8, c=0x9477ef8, words=0x94595b8, num_words=4) at command.c:415 #9 0x0809c672 in script_command (interp=0x9449020, argc=4, argv=0xbfa4db40) at command.c:142 #10 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x947aa48) at jim.c:8708 #11 0x080ed5c7 in Jim_EvalCoreCommand (interp=0x9449020, argc=3, argv=0xbfa4dc00) at jim.c:10846 #12 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9459160) at jim.c:8708 #13 0x080ebf6f in Jim_CatchCoreCommand (interp=0x9449020, argc=2, argv=0xbfa4dcc0) at jim.c:11413 #14 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x94599f8) at jim.c:8708 #15 0x080e9123 in Jim_EvalExpression (interp=0x9449020, exprObjPtr=0x9459a70, exprResultPtrPtr=0xbfa4de1c) at jim.c:6927 #16 0x080e9ea1 in Jim_GetBoolFromExpr (interp=0x9449020, exprObjPtr=0x9459a70, boolPtr=0xbfa4de58) at jim.c:7210 #17 0x080eed14 in Jim_IfCoreCommand (interp=0x9449020, argc=5, argv=0xbfa4dec0) at jim.c:10297 #18 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9479630) at jim.c:8708 #19 0x080e812b in JimCallProcedure (interp=0x9449020, cmd=0x94797e0, argc=3, argv=0xbfa4dfb0) at jim.c:8857 #20 0x080e7e06 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9459990) at jim.c:8714 #21 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x94695f8) at jim.c:8708 #22 0x080e7b22 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9468ba0) at jim.c:8654 #23 0x080eee1d in Jim_IfCoreCommand (interp=0x9449020, argc=3, argv=0xbfa4e1a0) at jim.c:10319 #24 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9468150) at jim.c:8708 #25 0x080eee1d in Jim_IfCoreCommand (interp=0x9449020, argc=3, argv=0xbfa4e270) at jim.c:10319 #26 0x080e7a62 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x944fbc0) at jim.c:8708 #27 0x080e812b in JimCallProcedure (interp=0x9449020, cmd=0x9455160, argc=5, argv=0xbfa4e35c) at jim.c:8857 #28 0x080e83e0 in Jim_EvalObjVector (interp=0x9449020, objc=6, objv=0xbfa4e35c) at jim.c:8424 #29 0x080e84d8 in JimUnknown (interp=0x9449020, argc=5, argv=0xbfa4e3e0) at jim.c:8383 #30 0x080e7e67 in Jim_EvalObj (interp=0x9449020, scriptObjPtr=0x9457cd0) at jim.c:8723 #31 0x080e8c02 in Jim_Eval_Named (interp=0x9449020, script=0x9459218 flash write_image file.elf 0x8 elf, filename=0x810648e command.c, lineno=469) at jim.c:8901 #32 0x0809c2e2 in command_run_line (context=0x94657e8, line=0x9459218 flash write_image file.elf 0x8 elf) at command.c:469 #33 0x080987cd in telnet_input (connection=0x9463be8) at telnet_server.c:330 #34 0x08099d20 in server_loop (command_context=0x9449008) at server.c:433 #35 0x0804a57c in
Re: [Openocd-development] arm926ejs i.MX27 testers out there
Hi Øyvind, On 7/6/09, Øyvind Harboe oyvind.har...@zylin.com wrote: Are there any arm926ejs and/or i.MX27 testers out there? I can do some tests as well! Cheers, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rathdominic.r...@gmx.de wrote: I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. That would be great! It would be especially helpful if you could also read over arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation of unknown/undocumented MOE values. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD + beagle
Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. Thanks a lot, S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Cygwin build issues and proposals
Tested on ubuntu64 9.04 I would like to see the #include types.h moved into the #ifndef HAVE_ELF_H block, as that code is creating the problems. Otherwise, looks good for 0.2.0. Cheers, I have committed this patch (with your suggestion) as this is a bug. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm926ejs unknown cpsr mode for i.MX27
Does anyone have an idea what mode 19 from cpsr would mean when passed into armv4_5_number_to_mode()? Any good links anyone? Is this Jazelle/Java Byte Code interpretation mode? OpenOCD does not have an unknown mode in the enum to handle the cases of unknown modes. Should we add one to the mode enum? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Wookey skrev: +++ Sergey Lapin [2009-07-06 19:02 +0400]: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. There is a config file for it in SVN, so I assume there is some... Wookey Hi list, I have done some work and it works as far as - CortexA8 can be halted, stepped and resumed if MMU is inactive. - Data can be up and downloaded to RAM - We can read and modify memory mapped registers - Breakpoints work, but not yet watchpoints, not problems here, it is simply not done yet. So uBoot and standalone programs can be debugged, and it should be possible to write some flash writing code. Debugging Linux on BeagleBoard does not work. I have not had time to keep up with the latest changes in trunk, so there will be some to clean up the code, and I will not have time for more work for the near future. So I will write up some status comments and publish what I have done, as is, before the end of the week. I think all Cortex-A8 materials should be removed from the published 0.2.0 since it does not work, and then add it after 0.2.0 has been cut, with time create some good working code. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
On Mon, Jul 6, 2009 at 7:43 PM, Magnus Lundinlun...@mlu.mine.nu wrote: Wookey skrev: +++ Sergey Lapin [2009-07-06 19:02 +0400]: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. There is a config file for it in SVN, so I assume there is some... Wookey Hi list, I have done some work and it works as far as - CortexA8 can be halted, stepped and resumed if MMU is inactive. - Data can be up and downloaded to RAM - We can read and modify memory mapped registers - Breakpoints work, but not yet watchpoints, not problems here, it is simply not done yet. So uBoot and standalone programs can be debugged, and it should be possible to write some flash writing code. Debugging Linux on BeagleBoard does not work. Which dongle were you using to debug on Beagle? I have not had time to keep up with the latest changes in trunk, so there will be some to clean up the code, and I will not have time for more work for the near future. So I will write up some status comments and publish what I have done, as is, before the end of the week. Thanks a lot, I really can't wait to see your code! Thanks a lot for doing this! S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
Hmm. here is a stab in the dark. Try the attached
patch...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Index: C:/workspace/openocd/src/flash/flash.c
===
--- C:/workspace/openocd/src/flash/flash.c (revision 2483)
+++ C:/workspace/openocd/src/flash/flash.c (working copy)
@@ -1091,6 +1091,12 @@
/* allocate buffer */
buffer = malloc(run_size);
+ if (buffer == NULL)
+ {
+ LOG_ERROR(Out of memory allocating %d bytes,
run_size);
+ return ERROR_FAIL;
+ }
+
buffer_size = 0;
/* read sections to the buffer */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Sergey Lapin skrev: On Mon, Jul 6, 2009 at 7:43 PM, Magnus Lundinlun...@mlu.mine.nu wrote: Wookey skrev: +++ Sergey Lapin [2009-07-06 19:02 +0400]: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. There is a config file for it in SVN, so I assume there is some... Wookey Hi list, I have done some work and it works as far as - CortexA8 can be halted, stepped and resumed if MMU is inactive. - Data can be up and downloaded to RAM - We can read and modify memory mapped registers - Breakpoints work, but not yet watchpoints, not problems here, it is simply not done yet. So uBoot and standalone programs can be debugged, and it should be possible to write some flash writing code. Debugging Linux on BeagleBoard does not work. Which dongle were you using to debug on Beagle? TinCanTools Flyswatter with the BeagleBoard adapter gives both JTAG and serial port monitor. I have not had time to keep up with the latest changes in trunk, so there will be some to clean up the code, and I will not have time for more work for the near future. So I will write up some status comments and publish what I have done, as is, before the end of the week. Thanks a lot, I really can't wait to see your code! Thanks a lot for doing this! S. M. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Sergey Lapin wrote: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. Recent status of trunk (at least the last time I checked): https://lists.berlios.de/pipermail/openocd-development/2009-June/008256.html That is, we can access (see) Cortex A8 and can manipulate debug registers using OpenOCD scripts. What is missing now is Cortex A8 support, similar to existing M3 support. Magnus' examples https://lists.berlios.de/pipermail/openocd-development/2009-July/009176.html would be really helpful for adding Cortex A8 support to OpenOCD. So main status is missing Cortex A8 support. Regarding dongle (was a question in an other mail of this thread), some people use Flyswatter (with adapter kit): http://elinux.org/BeagleBoardJTAG#TinCanTools_Flyswatter http://www.tincantools.com/images/D/Fly%2BBeagle-800x391.JPG?1229714946602 Best regards Diurk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, 2009-07-06 at 18:14 +0200, Øyvind Harboe wrote: Hmm. here is a stab in the dark. Try the attached patch... it is still dark... Program received signal SIGSEGV, Segmentation fault. target_buffer_get_u32 (target=0x82a2a20, buffer=0x82c8000 Address 0x82c8000 out of bounds) at ../../src/helper/types.h:80 80 return (uint32_t)(buf[0] | buf[1] 8 | buf[2] 16 | buf[3] 24); (gdb) (gdb) where #0 target_buffer_get_u32 (target=0x82a2a20, buffer=0x82c8000 Address 0x82c8000 out of bounds) at ../../src/helper/types.h:80 #1 0x0806f772 in arm7_9_write_memory (target=0x82a2a20, address=65600, size=4, count=1750, buffer=0x82c8004 Address 0x82c8004 out of bounds) at arm7_9_common.c:2450 #2 0x0806ea45 in arm7_9_bulk_write_memory (target=0x82a2a20, address=65600, count=1750, buffer=0x82c7d30 ) at arm7_9_common.c:2656 #3 0x08061d3d in target_write_buffer (target=0x82a2a20, address=65600, size=7000, buffer=0x82c7d30 ) at target.c:1167 #4 0x080b7651 in aduc702x_write (bank=0x82a7d40, buffer=0x82c7d30 , offset=0, count=7176) at aduc702x.c:284 #5 0x0805e86b in flash_driver_write (bank=0x82a7d40, buffer=0x0, offset=0, count=38676) at flash.c:94 #6 0x0805f328 in flash_write (target=0x82a2a20, image=0xbf890064, written=0xbf890098, erase=0) at flash.c:1144 #7 0x0805ff5d in handle_flash_write_image_command (cmd_ctx=0x82a27e8, cmd=0x82b4ee8 write_image, args=0x82965bc, argc=3) at flash.c:699 #8 0x0809c7bc in run_command (context=0x82a27e8, c=0x82b4ef8, words=0x82965b8, num_words=4) at command.c:415 #9 0x0809ca62 in script_command (interp=0x8286020, argc=4, argv=0xbf890180) at command.c:142 #10 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82b7a48) at jim.c:8708 #11 0x080ed9b7 in Jim_EvalCoreCommand (interp=0x8286020, argc=3, argv=0xbf890240) at jim.c:10846 #12 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8296160) at jim.c:8708 #13 0x080ec35f in Jim_CatchCoreCommand (interp=0x8286020, argc=2, argv=0xbf890300) at jim.c:11413 #14 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82969f8) at jim.c:8708 #15 0x080e9513 in Jim_EvalExpression (interp=0x8286020, exprObjPtr=0x8296a70, exprResultPtrPtr=0xbf89045c) at jim.c:6927 #16 0x080ea291 in Jim_GetBoolFromExpr (interp=0x8286020, exprObjPtr=0x8296a70, boolPtr=0xbf890498) at jim.c:7210 #17 0x080ef104 in Jim_IfCoreCommand (interp=0x8286020, argc=5, argv=0xbf890500) at jim.c:10297 #18 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82b6630) at jim.c:8708 #19 0x080e851b in JimCallProcedure (interp=0x8286020, cmd=0x82b67e0, argc=3, argv=0xbf8905f0) at jim.c:8857 #20 0x080e81f6 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8296990) at jim.c:8714 #21 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a65f8) at jim.c:8708 #22 0x080e7f12 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a5ba0) at jim.c:8654 #23 0x080ef20d in Jim_IfCoreCommand (interp=0x8286020, argc=3, argv=0xbf8907e0) at jim.c:10319 #24 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x82a5150) at jim.c:8708 #25 0x080ef20d in Jim_IfCoreCommand (interp=0x8286020, argc=3, argv=0xbf8908b0) at jim.c:10319 #26 0x080e7e52 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x828cbc0) at jim.c:8708 #27 0x080e851b in JimCallProcedure (interp=0x8286020, cmd=0x8292160, argc=5, argv=0xbf89099c) at jim.c:8857 #28 0x080e87d0 in Jim_EvalObjVector (interp=0x8286020, objc=6, objv=0xbf89099c) at jim.c:8424 #29 0x080e88c8 in JimUnknown (interp=0x8286020, argc=5, argv=0xbf890a20) at jim.c:8383 #30 0x080e8257 in Jim_EvalObj (interp=0x8286020, scriptObjPtr=0x8294cd0) at jim.c:8723 #31 0x080e8ff2 in Jim_Eval_Named (interp=0x8286020, script=0x8296218 flash write_image C0-4AD2DA-1.elf 0x8 elf, filename=0x8106909 command.c, lineno=469) at jim.c:8901 #32 0x0809c6d2 in command_run_line (context=0x82a27e8, line=0x8296218 flash write_image C0-4AD2DA-1.elf 0x8 elf) at command.c:469 #33 0x08098a3d in telnet_input (connection=0x82a0be8) at telnet_server.c:330 #34 0x08099f90 in server_loop (command_context=0x8286008) at server.c:433 #35 0x0804a5dc in openocd_main (argc=3, argv=0xbf8911d4) at openocd.c:283 #36 0x0804a332 in main (argc=Cannot access memory at address 0x82c8000 ) at main.c:39 (gdb) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
I'm guessing that this is an elf file parsing problem. Can you provide the elf file? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rathdominic.r...@gmx.de wrote: I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. That would be great! It would be especially helpful if you could also read over arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation of unknown/undocumented MOE values. Any examples of sequences that should fail? SVN 2483 with AT91SAM9260 and JTAGKEY is working here, including the reset run + halt you mentioned in your other post. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 17:41:40 Øyvind Harboe wrote: Does anyone have an idea what mode 19 from cpsr would mean when passed into armv4_5_number_to_mode()? Mode 19 decimal or hex? I've never seen 0x19, but 19d is 0x13 which is supervisor mode. Any good links anyone? Is this Jazelle/Java Byte Code interpretation mode? Jazelle has a dedciated J bit in the xPSR. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, 2009-07-06 at 19:01 +0200, Øyvind Harboe wrote: I'm guessing that this is an elf file parsing problem. Can you provide the elf file? Here is the same crash with a BIN file flash write file.bin 0x8 bin Program received signal SIGSEGV, Segmentation fault. target_buffer_get_u32 (target=0x8567a20, buffer=0x858d000 Address 0x858d000 out of bounds) at ../../src/helper/types.h:80 80 return (uint32_t)(buf[0] | buf[1] 8 | buf[2] 16 | buf[3] 24); (gdb) (gdb) where #0 target_buffer_get_u32 (target=0x8567a20, buffer=0x858d000 Address 0x858d000 out of bounds) at ../../src/helper/types.h:80 #1 0x0806f772 in arm7_9_write_memory (target=0x8567a20, address=65600, size=4, count=1750, buffer=0x858d004 Address 0x858d004 out of bounds) at arm7_9_common.c:2450 #2 0x0806ea45 in arm7_9_bulk_write_memory (target=0x8567a20, address=65600, count=1750, buffer=0x858c6c8 ) at arm7_9_common.c:2656 #3 0x08061d3d in target_write_buffer (target=0x8567a20, address=65600, size=7000, buffer=0x858c6c8 ) at target.c:1167 #4 0x080b7651 in aduc702x_write (bank=0x856cd40, buffer=0x858c6c8 , offset=0, count=7176) at aduc702x.c:284 #5 0x0805e86b in flash_driver_write (bank=0x856cd40, buffer=0x0, offset=0, count=38676) at flash.c:94 #6 0x0805f328 in flash_write (target=0x8567a20, image=0xbfedeeb4, written=0xbfedeee8, erase=0) at flash.c:1144 #7 0x0805ff5d in handle_flash_write_image_command (cmd_ctx=0x85677e8, cmd=0x8579ee8 write_image, args=0x855b5bc, argc=3) at flash.c:699 #8 0x0809c7bc in run_command (context=0x85677e8, c=0x8579ef8, words=0x855b5b8, num_words=4) at command.c:415 #9 0x0809ca62 in script_command (interp=0x854b020, argc=4, argv=0xbfedefd0) at command.c:142 #10 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x857ca48) at jim.c:8708 #11 0x080ed9b7 in Jim_EvalCoreCommand (interp=0x854b020, argc=3, argv=0xbfedf090) at jim.c:10846 #12 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b160) at jim.c:8708 #13 0x080ec35f in Jim_CatchCoreCommand (interp=0x854b020, argc=2, argv=0xbfedf150) at jim.c:11413 #14 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b9f8) at jim.c:8708 #15 0x080e9513 in Jim_EvalExpression (interp=0x854b020, exprObjPtr=0x855ba70, exprResultPtrPtr=0xbfedf2ac) at jim.c:6927 #16 0x080ea291 in Jim_GetBoolFromExpr (interp=0x854b020, exprObjPtr=0x855ba70, boolPtr=0xbfedf2e8) at jim.c:7210 #17 0x080ef104 in Jim_IfCoreCommand (interp=0x854b020, argc=5, argv=0xbfedf350) at jim.c:10297 #18 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x857b630) at jim.c:8708 #19 0x080e851b in JimCallProcedure (interp=0x854b020, cmd=0x857b7e0, argc=3, argv=0xbfedf440) at jim.c:8857 #20 0x080e81f6 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x855b990) at jim.c:8714 #21 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856b5f8) at jim.c:8708 #22 0x080e7f12 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856aba0) at jim.c:8654 #23 0x080ef20d in Jim_IfCoreCommand (interp=0x854b020, argc=3, argv=0xbfedf630) at jim.c:10319 #24 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x856a150) at jim.c:8708 #25 0x080ef20d in Jim_IfCoreCommand (interp=0x854b020, argc=3, argv=0xbfedf700) at jim.c:10319 #26 0x080e7e52 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x8551bc0) at jim.c:8708 #27 0x080e851b in JimCallProcedure (interp=0x854b020, cmd=0x8557160, argc=5, argv=0xbfedf7ec) at jim.c:8857 #28 0x080e87d0 in Jim_EvalObjVector (interp=0x854b020, objc=6, objv=0xbfedf7ec) at jim.c:8424 #29 0x080e88c8 in JimUnknown (interp=0x854b020, argc=5, argv=0xbfedf870) at jim.c:8383 #30 0x080e8257 in Jim_EvalObj (interp=0x854b020, scriptObjPtr=0x8559cd0) at jim.c:8723 #31 0x080e8ff2 in Jim_Eval_Named (interp=0x854b020, script=0x855b218 flash write_image file.bin 0x8 bin, filename=0x8106909 command.c, lineno=469) at jim.c:8901 #32 0x0809c6d2 in command_run_line (context=0x85677e8, line=0x855b218 flash write_image file.bin 0x8 bin) at command.c:469 #33 0x08098a3d in telnet_input (connection=0x8565be8) at telnet_server.c:330 #34 0x08099f90 in server_loop (command_context=0x854b008) at server.c:433 #35 0x0804a5dc in openocd_main (argc=3, argv=0xbfee0024) at openocd.c:283 #36 0x0804a332 in main (argc=Cannot access memory at address 0x858d000 ) at main.c:39 (gdb) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Mon, Jul 6, 2009 at 7:06 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rathdominic.r...@gmx.de wrote: I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. That would be great! It would be especially helpful if you could also read over arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation of unknown/undocumented MOE values. Any examples of sequences that should fail? I get MOE=0xe upon reset run of i.MX27. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Mon, Jul 6, 2009 at 7:10 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 17:41:40 Øyvind Harboe wrote: Does anyone have an idea what mode 19 from cpsr would mean when passed into armv4_5_number_to_mode()? Mode 19 decimal or hex? I've never seen 0x19, but 19d is 0x13 which is supervisor mode. 19 decimal. Why does armv4_5_number_to_mode() not translate *all* 31 possible modes? Any good links anyone? Is this Jazelle/Java Byte Code interpretation mode? Jazelle has a dedciated J bit in the xPSR. Where can I find documentation of CPSR? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
Can you reproduce with: - dummy driver? (--enable-dummy + -f interface/dummy.cfg) - help fill = flash fill -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 20:21:03 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 7:10 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 17:41:40 Øyvind Harboe wrote: Does anyone have an idea what mode 19 from cpsr would mean when passed into armv4_5_number_to_mode()? Mode 19 decimal or hex? I've never seen 0x19, but 19d is 0x13 which is supervisor mode. 19 decimal. Why does armv4_5_number_to_mode() not translate *all* 31 possible modes? Because only those numbers that are translated were valid at the time I wrote the original code. The other modes are translated to -1 because they indicate a bug or a communication error. We could add 0x16 (22) as ARMV4_5_MODE_SEC (or ..._SEC_MO(N)), for the secure monitor mode as documented for example in the ARM1176JZF-S TRM. Not sure what we would do if we ever encountered that mode... Any good links anyone? Is this Jazelle/Java Byte Code interpretation mode? Jazelle has a dedciated J bit in the xPSR. Where can I find documentation of CPSR? In most (all?) of the TRMs, and the architecture reference manuals. DDI-0100I (the latest version of the ARM ARM architecture reference manual that I could fine) lists the J bit, but lacks secure monitor mode. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
How about if we changed the way this mode is handled to
get out of the dire straits we're in...
We need a couple of operations at least:
- set known mode (handled today)
- save restore mode (can be handled w/unknown mode I think)
- try to interpret mode to user text (here unknown modes are trivially
handlled)
Others?
I was thinking about replacing the mode enum with a structure:
struct translated_mode
{
int saved_mode;
enum translated_mode mode;
};
that way we would get type checking too and can more easily
catch the type bugs I spotted today...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote: Can you reproduce with: - dummy driver? (--enable-dummy + -f interface/dummy.cfg) - help fill = flash fill I built with ./configure --enable-maintainer-mode --enable-parport --enable-ft2232_libftdi --enable-jlink --enable-dummy ran as sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS Error: There are no enabled taps? Error: There are no enabled taps? Warn : no gdb ports allocated as no target has been specified Info : accepting 'telnet' connection from 0 Unknown command: flash fill help fill No known command... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009 20:43:41 Øyvind Harboe wrote:
How about if we changed the way this mode is handled to
get out of the dire straits we're in...
We need a couple of operations at least:
- set known mode (handled today)
- save restore mode (can be handled w/unknown mode I think)
I really think there shouldn't be any unknown modes. If there is one, we've
lost already, and should print an error.
The mode affects the processors view of its register file, e.g. system aliases
to user registers, both lack a SPSR. Only r13 and r14 are distinct for most
modes, but FIQ has its own r8 to r12.
- try to interpret mode to user text (here unknown modes are trivially
handlled)
Others?
I was thinking about replacing the mode enum with a structure:
struct translated_mode
{
int saved_mode;
enum translated_mode mode;
};
that way we would get type checking too and can more easily
catch the type bugs I spotted today...
I don't understand what bug you've spotted - mode 19 is supervisor, and is
documented and handled in the code.
Regards,
Dominic
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Monday 06 July 2009 20:19:54 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 7:06 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rathdominic.r...@gmx.de wrote: I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. That would be great! It would be especially helpful if you could also read over arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation of unknown/undocumented MOE values. Any examples of sequences that should fail? I get MOE=0xe upon reset run of i.MX27. reset run works just fine here, but reset halt fails, and only a power cycle gets the target in a cooperative state after this. The target halt times out, and JTAG communication is obviously broken afterwards. Halting isn't possible, and I get a bogus debug reason (MOE) 0xf. -- reset halt JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) JTAG Tap/device matched timed out while waiting for target halted Runtime error, file embedded:startup.tcl, line 226: expected return code but got 'TARGET: at91sam9260.cpu - Not halted' in procedure 'ocd_process_reset' called at file embedded:startup.tcl, line 208 called at file embedded:startup.tcl, line 209 called at file embedded:startup.tcl, line 225 Runtime error, file command.c, line 469: -- Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
I don't understand what bug you've spotted - mode 19 is supervisor, and is
documented and handled in the code.
I'm starting to grasp a bit more of what's going on(so I deleted
the misunderstandings above).
Let me reiterate a bit.
I saw armv4_5_mode_to_number() failing because it was passed
19 decimal. This is clearly impossible and I have to go back check my
observations.
From arm7_9_common.c:
armv4_5-core_mode = cpsr 0x1f;
if (armv4_5_mode_to_number(armv4_5-core_mode) == -1)
{
target-state = TARGET_UNKNOWN;
LOG_ERROR(cpsr contains invalid mode value - communication
failure);
return ERROR_TARGET_FAILURE;
}
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Mon, Jul 6, 2009 at 9:06 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 20:19:54 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 7:06 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 16:57:24 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 4:25 PM, Dominic Rathdominic.r...@gmx.de wrote: I can run some tests later today when I get home (~2 hours from now). I have a arm926ejs board. That would be great! It would be especially helpful if you could also read over arm926ejs.c/arm926ejs_examine_debug_reason() w.r.t. interpretation of unknown/undocumented MOE values. Any examples of sequences that should fail? I get MOE=0xe upon reset run of i.MX27. reset run works just fine here, but reset halt fails, and only a power cycle gets the target in a cooperative state after this. The target halt times out, and JTAG communication is obviously broken afterwards. Halting isn't possible, and I get a bogus debug reason (MOE) 0xf. MOE=0xf would be a result of receiving all '1's Any chance of a bisection on when this broke? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, Jul 6, 2009 at 8:52 PM, Thomas A. Moultont...@moulton.us wrote: On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote: Can you reproduce with: - dummy driver? (--enable-dummy + -f interface/dummy.cfg) - help fill = flash fill I built with ./configure --enable-maintainer-mode --enable-parport --enable-ft2232_libftdi --enable-jlink --enable-dummy ran as sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg you need to add your target configuration file as well sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg -f /usr/local/share/openocd/scripts/target/adu.cfg -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
On Monday 06 July 2009, Øyvind Harboe wrote: on wi-9c.cfg which I'm testing against reset run + halt does not work. step sits in an infinite loop(or times out now). Hmm, on a dm365 I saw some odd behavior but I attributed that to it being beta hardware, since last time I tried anything with a dm355 those things behaved. reset halt doesn't work as expected (i.e. stop with PC at zero); and for that matter, reset didn't always seem to work ... after resetting it a few times, the CPU said it was still running with MMU active. I did see misbehavior with an arm920t where step and vector catch didn't seem to work, a month or so back. This is without GDB. The vector catch didn't seem to be effective at writing the value ... readback didn't show it was written, it didn't act as if it had been, but a breakpoint at address zero showed kicked in. And the step mostly seemed like a resume. Personally, I'm still having a bit of a hard time telling the difference between operator error, buggy chips, and buggy software. Those dm365 things seem more on the side of hardware bugs... though maybe not entirely. The arm920t issues seemed more like software. It's just *some* things which seem broken. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
Personally, I'm still having a bit of a hard time telling the difference between operator error, buggy chips, and buggy software. I wonder if we need an period of stability on svn head before we can really start digging into these problems. To get these right makes the difference between a usable and *great* tool. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix for arm926ejs strange MOE values handling
On Monday 06 July 2009, Øyvind Harboe wrote: I have never used the dbgrq option. It's currently only used by ti parts in the scripts that ship w/OpenOCD. The dm6446 is an arm926ejs part. Isn't dbgrq actually turned on by default on all arm926 parts? Via arm926ejs_init_arch_info() ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs unknown cpsr mode for i.MX27
On Monday 06 July 2009, Dominic wrote: Where can I find documentation of CPSR? In most (all?) of the TRMs, and the architecture reference manuals. DDI-0100I (the latest version of the ARM ARM architecture reference manual that I could fine) lists the J bit, but lacks secure monitor mode. Ignoring secure stuff, also Thumb2 mode != Thumb mode if I recall correctly. There might be some ARM11 parts that support Thumb2, but it's mostly seen in Cortex (ARMv7). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix for arm926ejs strange MOE values handling
On Mon, Jul 6, 2009 at 9:42 PM, David Brownelldavi...@pacbell.net wrote: On Monday 06 July 2009, Ųyvind Harboe wrote: I have never used the dbgrq option. It's currently only used by ti parts in the scripts that ship w/OpenOCD. The dm6446 is an arm926ejs part. Isn't dbgrq actually turned on by default on all arm926 parts? Via arm926ejs_init_arch_info() ... It is... Which makes MOE interpretation more important than ever... The known missing interpretation from arm926ejs is MOE=0xe... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix for arm926ejs strange MOE values handling
On Monday 06 July 2009 21:55:18 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 9:42 PM, David Brownelldavi...@pacbell.net wrote: On Monday 06 July 2009, Ųyvind Harboe wrote: I have never used the dbgrq option. It's currently only used by ti parts in the scripts that ship w/OpenOCD. The dm6446 is an arm926ejs part. Isn't dbgrq actually turned on by default on all arm926 parts? Via arm926ejs_init_arch_info() ... It is... Which makes MOE interpretation more important than ever... The known missing interpretation from arm926ejs is MOE=0xe... Is this confirmed to be the real content of the debug status register? Or could this be a subsequent error that results from some other bug, or maybe a communication problem like the one I'm seeing with reset halt. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD error handling
On Monday 06 July 2009, Øyvind Harboe wrote: There's more that should be said about returning values from Tcl commands ... so that scripts can use them. Can you give some examples of where tcl scripts would do anything but catch exceptions as a boolean fail/succeed? Any time they need to do something conditional, or use a value from a register... and remember, errors are often hidden by returning success codes. (After spamming the server output with a useless-to-the-script message, sigh.) Should we rely on tcl scripts for anything more complicated? If we can't, why do we even have an extension language??? One point of comparison is that TI's Code Composer Studio supports *.gel files with script that's used for all kinds of initialization. The board support for the dm365 (beta) came with one GEL file that's about 135 KBytes big ... the first eight scripts provide menus in their GUI, each setting up a different PLL/clock configurations for the ARM and DDR. It should *not* be necessary to write C code for such stuff, and rebuild the server... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
On Monday 06 July 2009 21:22:14 Øyvind Harboe wrote: MOE=0xf would be a result of receiving all '1's Any chance of a bisection on when this broke? 2483: fails, debug reason 0xf etc. 1606: fails, debug reason 0xf etc. 1167: fails, debug reason 0xf etc. 948: fails, debug reason 0xf etc. 838: fails, debug reason 0xf etc. 783: won't start: vmas...@milliways:~/Development/OpenOCD/OpenOCD-783$ sudo ./src/openocd -f src/target/interface/jtagkey.cfg -f src/target/target/at91sam9260.cfg Open On-Chip Debugger 1.0 (2009-07-06-22:11) svn:783 $URL: https://dr...@svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ Info:options.c:50 configuration_output_handler(): Runtime error, file ?, line 1: Info:options.c:50 configuration_output_handler(): invalid command name script Info:options.c:50 configuration_output_handler(): Runtime error, file ?, line 1: Info:options.c:50 configuration_output_handler(): invalid command name script 729: works Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] build problem
Hi - I've been building from SVN, but hadn't updated in a while. When I updated today, the build error is [503] lsb_release -rci Distributor ID: Ubuntu Release:8.10 Codename: intrepid [504] svn update At revision 2483. [505] autconf [506] ./configure --enable-ft2232_libftdi ... [507] make ... libtool: link: gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o ./.libs/libopenocd.a -ldl -lftdi /usr/lib/libusb.so ./.libs/libopenocd.a(tcl.o): In function `handle_interface_list_command': /home/ctuffli/dev/flyswatter/openocd/src/jtag/tcl.c:688: undefined reference to `jtag_interfaces' /home/ctuffli/dev/flyswatter/openocd/src/jtag/tcl.c:688: undefined reference to `jtag_interfaces' ./.libs/libopenocd.a(tcl.o): In function `handle_interface_command': /home/ctuffli/dev/flyswatter/openocd/src/jtag/tcl.c:650: undefined reference to `jtag_interfaces' /home/ctuffli/dev/flyswatter/openocd/src/jtag/tcl.c:650: undefined reference to `jtag_interfaces' /home/ctuffli/dev/flyswatter/openocd/src/jtag/tcl.c:659: undefined reference to `jtag_interfaces' collect2: ld returned 1 exit status I can build up to version 2412, but not 2413 and onwards. Any ideas? ---chuck ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, 2009-07-06 at 21:23 +0200, Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 8:52 PM, Thomas A. Moultont...@moulton.us wrote: On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote: Can you reproduce with: - dummy driver? (--enable-dummy + -f interface/dummy.cfg) - help fill = flash fill I built with ./configure --enable-maintainer-mode --enable-parport --enable-ft2232_libftdi --enable-jlink --enable-dummy ran as sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg you need to add your target configuration file as well sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg -f /usr/local/share/openocd/scripts/target/adu.cfg t...@w2vy:~$ sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg -f /usr/local/share/openocd/scripts/target/aduc702x.cfg [sudo] password for tom: Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 Warn : Tap/Device does not have IDCODE Error: JTAG tap: aduc702x.cpu got: 0x (mfg: 0x000, part: 0x, ver: 0x0) Error: JTAG tap: aduc702x.cpu expected 1 of 1: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Error: trying to validate configured JTAG chain anyway... Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x3F. tap=aduc702x.cpu pos=0 expected 0x1 got 3 Warn : Could not validate JTAG chain, continuing anyway... Error: unknown EmbeddedICE version (comms ctrl: 0x) target state: halted target halted in Thumb state due to watchpoint, current mode: System cpsr: 0x pc: 0xffef are these errors/warnings ok? tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] arm7_9 dbgrq disable not usually needed
Update docs to say that arm7_9 dbgrq enable is the default
on ARM9 cores, and update the DaVinci config files so they
no longer explicitly specify it.
---
doc/openocd.texi |2 ++
tcl/target/ti_dm355.cfg |1 -
tcl/target/ti_dm365.cfg |1 -
tcl/target/ti_dm6446.cfg |1 -
4 files changed, 2 insertions(+), 3 deletions(-)
Update docs to say that arm7_9 dbgrq enable is the default
on ARM9 cores, and update the DaVinci config files so they
no longer explicitly specify it.
---
doc/openocd.texi |2 ++
tcl/target/ti_dm355.cfg |1 -
tcl/target/ti_dm365.cfg |1 -
tcl/target/ti_dm6446.cfg |1 -
4 files changed, 2 insertions(+), 3 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -4631,6 +4631,8 @@ and any other core-specific commands tha
Control use of the EmbeddedIce DBGRQ signal to force entry into debug mode,
instead of breakpoints. This should be
safe for all but ARM7TDMI--S cores (like Philips LPC).
+This feature is enabled by default on most ARM9 cores,
+including ARM9TDMI, ARM920T, and ARM926EJ-S.
@end deffn
@deffn Command {arm7_9 dcc_downloads} (@option{enable}|@option{disable})
--- a/tcl/target/ti_dm355.cfg
+++ b/tcl/target/ti_dm355.cfg
@@ -83,7 +83,6 @@ $_TARGETNAME configure \
-work-area-size 0x4000 \
-work-area-backup 0
-arm7_9 dbgrq enable
arm7_9 fast_memory_access enable
arm7_9 dcc_downloads enable
--- a/tcl/target/ti_dm365.cfg
+++ b/tcl/target/ti_dm365.cfg
@@ -88,7 +88,6 @@ $_TARGETNAME configure \
-work-area-size 0x4000 \
-work-area-backup 0
-arm7_9 dbgrq enable
arm7_9 fast_memory_access enable
arm7_9 dcc_downloads enable
--- a/tcl/target/ti_dm6446.cfg
+++ b/tcl/target/ti_dm6446.cfg
@@ -68,7 +68,6 @@ set _TARGETNAME $_CHIPNAME.arm
target create $_TARGETNAME arm926ejs -chain-position $_TARGETNAME
$_TARGETNAME configure -work-area-phys 0xa000 -work-area-size 0x2000
-arm7_9 dbgrq enable
arm7_9 fast_memory_access enable
arm7_9 dcc_downloads enable
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Analog Device AduC70xx support
On Mon, 2009-07-06 at 21:23 +0200, Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 8:52 PM, Thomas A. Moultont...@moulton.us wrote: On Mon, 2009-07-06 at 20:27 +0200, Øyvind Harboe wrote: Can you reproduce with: - dummy driver? (--enable-dummy + -f interface/dummy.cfg) - help fill = flash fill I built with ./configure --enable-maintainer-mode --enable-parport --enable-ft2232_libftdi --enable-jlink --enable-dummy ran as sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg you need to add your target configuration file as well sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg -f /usr/local/share/openocd/scripts/target/adu.cfg t...@w2vy:~$ sudo openocd -f /usr/local/share/openocd/scripts/interface/dummy.cfg -f /usr/local/share/openocd/scripts/target/aduc702x.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-06-14:45) svn:2482M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 Warn : Tap/Device does not have IDCODE Error: JTAG tap: aduc702x.cpu got: 0x (mfg: 0x000, part: 0x, ver: 0x0) Error: JTAG tap: aduc702x.cpu expected 1 of 1: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Error: trying to validate configured JTAG chain anyway... Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x3F. tap=aduc702x.cpu pos=0 expected 0x1 got 3 Warn : Could not validate JTAG chain, continuing anyway... Error: unknown EmbeddedICE version (comms ctrl: 0x) target state: halted target halted in Thumb state due to watchpoint, current mode: System cpsr: 0x pc: 0xffef Info : accepting 'telnet' connection from 0 Warn : target reentered debug state, but not at the desired exit point: 0xffef Error: error executing aduc702x flash write algorithm Error: flash block writing failed t...@w2vy:~$ telnet 127.0.0.1 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Open On-Chip Debugger flash fillw 0x8 0x1234 4 target reentered debug state, but not at the desired exit point: 0xffef error executing aduc702x flash write algorithm flash block writing failed error writing to flash at address 0x0008 at offset 0x (-902) called at file command.c, line 469 called at file embedded:startup.tcl, line 89 called at file embedded:startup.tcl, line 91 called at file embedded:startup.tcl, line 93 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink compilation (./configure) was missingusb.h , svn#2459
done using: svn# 2459 ./configure --enable-maintainer-mode --disable-werror --disable-shared --enable-jlink CC=gcc -mnocygwin It worked until I got configure: error: usb.h is required to build some OpenOCD drivers(s) http://forum.sparkfun.com/viewtopic.php?t=11221 If you follow the steps in Michael tutorial it shows you where you need to get/copy the usb.h [QUOTE] here comes more information in case you want to build openocd for a interface which need libusb or libftdi. (Tested with SVN version 2348 of OpenOCD) First of all you must download libusb-win32 which can be found here: http://sourceforge.net/project/showfiles.php?group_id=78138package_id=79216 release_id=495011 You need the libusb-win32-device-bin-0.1.12.1.tar.gz packages. Please extract this file into a temp file. A new folder will be created called: libusb-win32-device-bin-0.1.12.1 Now copy the file libusb-win32-device-bin-0.1.12.1\include\usb.h to the following directories: c:\cygwin\usr\include c:\cygwin\usr\include\mingw Even you must copy the library libusb-win32-device-bin-0.1.12.1\lib\gcc\libusb.a to the following directories: c:\cygwin\lib c:\cygwin\lib\mingw [/QUOTE] Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] arm7_9 dbgrq disable not usually needed
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix for arm926ejs strange MOE values handling
On Mon, Jul 6, 2009 at 10:01 PM, Dominicdominic.r...@gmx.de wrote: On Monday 06 July 2009 21:55:18 Øyvind Harboe wrote: On Mon, Jul 6, 2009 at 9:42 PM, David Brownelldavi...@pacbell.net wrote: On Monday 06 July 2009, Ųyvind Harboe wrote: I have never used the dbgrq option. It's currently only used by ti parts in the scripts that ship w/OpenOCD. The dm6446 is an arm926ejs part. Isn't dbgrq actually turned on by default on all arm926 parts? Via arm926ejs_init_arch_info() ... It is... Which makes MOE interpretation more important than ever... The known missing interpretation from arm926ejs is MOE=0xe... Is this confirmed to be the real content of the debug status register? Or could this be a subsequent error that results from some other bug, or maybe a communication problem like the one I'm seeing with reset halt. I'm not sure how I could know As I recall MOE=0xe has been reported by Broadcom arm926ejs and the Freescale parts... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build problem
On Mon, 2009-07-06 at 13:24 -0700, Chuck Tuffli wrote: Hi - I've been building from SVN, but hadn't updated in a while. When I updated today, the build error is [503] lsb_release -rci Distributor ID: Ubuntu Release:8.10 Codename: intrepid [504] svn update At revision 2483. [505] autconf This was insufficient. You also needed to run automake. It is safer to re-run bootstrap. [506] ./configure --enable-ft2232_libftdi You should include --enable-maintainer-mode as well. See README. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink compilation (./configure) was missing usb.h , svn#2459
On Mon, 2009-07-06 at 13:56 -0700, Joseph Kuss wrote: This may be easy to fix (if you know the system) but for me ... done using: svn# 2459 ./configure --enable-maintainer-mode --disable-werror --disable-shared --enable-jlink CC=gcc -mnocygwin It worked until I got configure: error: usb.h is required to build some OpenOCD drivers(s) Please post bug reports in plain text. Do not post PDF files. Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs i.MX27 testers out there
Hmmm 838 - 729 covers a *lot* of changes but nothing that stands out as a suspect. If you have time to narrow this down further then that would be *great*. 788 has the startup tcl script embedded. That could be the problem you are seing in 783. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] build problem
On Mon, Jul 6, 2009 at 2:30 PM, Zach Welchz...@superlucidity.net wrote: ... This was insufficient. You also needed to run automake. It is safer to re-run bootstrap. D'oh! Forgot about that step. All is fine now. Thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Patch to Fix J-link Debugger Communication Failures
On Mon, Jul 6, 2009 at 12:46 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Mon, Jul 6, 2009 at 11:29 AM, Gary Carlsongcarl...@carlson-minot.com wrote: Based on your most recent information, I am pretty sure this a different problem that my patch won't fix. Yes I agree. There are more fundamental problems there. I am sorry. It is a stupid udev rule error. I have set up proper udev rules in Ubuntu and Fedora. But I have not set up the correct udev rules for the Arch Linux and the newly installed OpenSuse 11.1. Now it is working. You patch is good. Now I do not have startup error any more. Under Arch Linux: [mc...@myhost jlinkv3]$ sudo openocd -f openocd_lpc2148.cfg Open On-Chip Debugger 0.2.0-in-development (2009-07-06-06:37) svn:2462M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 jtag_speed: 15 force hard breakpoints Info : J-Link initialization started / target CPU reset initiated Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Info : JLink hw version 3 Info : Vref = 3.288 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 0 TRST = 255 Info : J-Link JTAG Interface ready Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : JTAG Tap/device matched Strangely from the previous log, it is not immediately clear that the error is due to permission. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] J-Link Reset Halt Bug
I am getting a bug message when I issue a ³reset halt² instruction from a telnet client using a j-link dongle. Has this instruction worked for anyone else before on other targets? Before I go off an hunt this down, I was hoping to see whether it is a problem isolated to my particular processor or a larger issue with the j-link code. Thanks, Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Mingw build
On Tue, Jul 7, 2009 at 8:03 AM, Alain Mouetteala...@pobox.com wrote: Xiaofan Chen escreveu: With ftd2xx, the configuration step still failed. ../trunk/configure --host=i586-mingw32msvc --enable-maintainer-mode --disable-shared --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mcuee/Desktop/build/openocd/libftd2xx-win32 checking for ftd2xx.lib exists (win32)... checking whether ftd2xx library works... configure: error: Cannot build run test program using ftd2xx.lib You will have to *guess* by trial and error, where to put and what name to givi it... It took me 3 hours. I made an enhancement request to write that name, but was not heard. Unfortunately I cannot help you, that was on Linux. Could you elaborate a bit more? I have problems with both Linux native build of ftd2xx (linking step error) and cross build of ftd2xx for Windows under Linux. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Patch to Fix J-link Debugger Communication Failures
On Tue, Jul 7, 2009 at 7:04 AM, Xiaofan Chenxiaof...@gmail.com wrote: I am sorry. It is a stupid udev rule error. I have set up proper udev rules in Ubuntu and Fedora. But I have not set up the correct udev rules for the Arch Linux and the newly installed OpenSuse 11.1. I use mainly Ubuntu 9.04 and Vista 32bit. The other 3 Linux distros are all for testing purposes and often subject to change. Now it is working. You patch is good. Now I do not have startup error any more. Strangely from the previous log, it is not immediately clear that the error is due to permission. The patch has been integrated into the latest svn and it works great for my J-Links. Thanks a lot. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink compilation (./configure) was missingusb.h , svn#2459
Thanks Spen, This advice was helpful. Now I have windows executables for a ftd2232 version of openOCD svn2459 as well as a Jlink version of the same. Both compiled using cygwin tools on my Vista laptop. Best regards, Joe On Mon, Jul 6, 2009 at 2:02 PM, Spencer Olivers...@spen-soft.co.uk wrote: done using: svn# 2459 ./configure --enable-maintainer-mode --disable-werror --disable-shared --enable-jlink CC=gcc -mnocygwin It worked until I got configure: error: usb.h is required to build some OpenOCD drivers(s) http://forum.sparkfun.com/viewtopic.php?t=11221 If you follow the steps in Michael tutorial it shows you where you need to get/copy the usb.h [QUOTE] here comes more information in case you want to build openocd for a interface which need libusb or libftdi. (Tested with SVN version 2348 of OpenOCD) First of all you must download libusb-win32 which can be found here: http://sourceforge.net/project/showfiles.php?group_id=78138package_id=79216 release_id=495011 You need the libusb-win32-device-bin-0.1.12.1.tar.gz packages. Please extract this file into a temp file. A new folder will be created called: libusb-win32-device-bin-0.1.12.1 Now copy the file libusb-win32-device-bin-0.1.12.1\include\usb.h to the following directories: c:\cygwin\usr\include c:\cygwin\usr\include\mingw Even you must copy the library libusb-win32-device-bin-0.1.12.1\lib\gcc\libusb.a to the following directories: c:\cygwin\lib c:\cygwin\lib\mingw [/QUOTE] Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
