Re: [Openocd-development] Switch to non-Berlios mailing list
Øyvind Harboe oyvind.har...@zylin.com writes: Other? Please keep gmane.org mirroring the list where ever it will be :-) -- http://www.iki.fi/~ananaza/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
On Tue, Oct 6, 2009 at 8:05 AM, Antti P Miettinen anan...@iki.fi wrote: Øyvind Harboe oyvind.har...@zylin.com writes: Other? Please keep gmane.org mirroring the list where ever it will be :-) Is there such a thing as distributed mailing lists so it won't matter if server go down? (I never looked into good old news... :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/rfc] update version handling for better GIT support
The guess-rev.sh script is now a tweaked version of setlocalversion as
seen in Linux, U-Boot, and various other projects. When it finds source
control support (git, hg, svn) it uses IDs from there. Else it reports
itself as -snapshot, e.g. from gitweb.
Also update the generic version strings to be like 0.3.0-dev (during
development) instead of the very long 0.3.0-in-development. These
also show up in the PDF docs; we might eventually change these strings
to include the version IDs.
Change how the startup banner strings include the guess-rev output.
Development and release versions will be like
Open On-Chip Debugger 0.3.0-dev-svn2801 (2009-10-05-20:57)
Open On-Chip Debugger 0.3.0-dev-00282-g7191a4f-dirty (2009-10-05-20:57)
Open On-Chip Debugger 0.3.0 (2009-10-05-20:57)
instead of the previous SVN-specific (even over git-svn!)
Open On-Chip Debugger 0.3.0-in-development (2009-10-05-01:39) svn2801:2802
Open On-Chip Debugger 0.3.0-in-development (2009-10-05-01:39) svn:exported
Open On-Chip Debugger 0.3.0 (2009-10-05-01:39) Release
I verified this new guess-rev.sh script runs under Cygwin.
---
Obviously svn... IDs are unusable with GIT; something must change.
configure.in |2 -
doc/manual/release.txt |6 +--
guess-rev.sh | 83 ---
src/Makefile.am|6 ++-
src/openocd.c |2 -
tools/release.sh |8 ++--
6 files changed, 92 insertions(+), 15 deletions(-)
--- a/configure.in
+++ b/configure.in
@@ -1,5 +1,5 @@
AC_PREREQ(2.60)
-AC_INIT([openocd], [0.3.0-in-development],
+AC_INIT([openocd], [0.3.0-dev],
[OpenOCD Mailing List openocd-development@lists.berlios.de])
AC_CONFIG_SRCDIR([src/openocd.c])
--- a/doc/manual/release.txt
+++ b/doc/manual/release.txt
@@ -62,9 +62,9 @@ the minor version will @a also be zero (
@subsection releaseversiontags Version Tags
After these required numeric components, the version string may contain
-one or more iversion tags/i, such as '-rc1' or '-in-development'.
+one or more iversion tags/i, such as '-rc1' or '-dev'.
-The trunk and all branches should have the tag '-in-development' in
+The trunk and all branches should have the tag '-dev' in
their version number. This tag helps developers identify reports
created from the Subversion repository, and it can be detected and
manipulated by the release script. Specifically, this tag will be
@@ -218,7 +218,7 @@ The following steps should be followed t
- 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:
+ -# Remove -dev tag from package version in configure.in:
- For major/minor releases, remove version tag from trunk, @a or
- For bug-fix releases, remove version tag from release branch.
-# Branch or tag the required tree in the Subversion repository:
--- a/guess-rev.sh
+++ b/guess-rev.sh
@@ -1,8 +1,83 @@
-#!/bin/bash
+#!/bin/sh
+#
+# This scripts adds local version information from the version
+# control systems git, mercurial (hg) and subversion (svn).
+#
+# Copied from Linux 2.6.32 scripts/setlocalversion and modified
+# slightly to work better for OpenOCD.
#
-REV=unknown
+usage() {
+ echo Usage: $0 [srctree] 2
+ exit 1
+}
-which svnversion /dev/null 21 REV=`svnversion -n $1`
+cd ${1:-.} || usage
-echo -n $REV
+# Check for git and a git repo.
+if head=`git rev-parse --verify --short HEAD 2/dev/null`; then
+
+ # If we are at a tagged commit (like v2.6.30-rc6), we ignore it,
+ # because this version is defined in the top level Makefile.
+ if [ -z `git describe --exact-match 2/dev/null` ]; then
+
+ # If we are past a tagged commit (like
v2.6.30-rc5-302-g72357d5),
+ # we pretty print it.
+ if atag=`git describe 2/dev/null`; then
+ echo $atag | awk -F- '{printf(-%05d-%s,
$(NF-1),$(NF))}'
+
+ # If we don't have a tag at all we print -g{commitish}.
+ else
+ printf '%s%s' -g $head
+ fi
+ fi
+
+ # Is this git on svn?
+ if git config --get svn-remote.svn.url /dev/null; then
+ printf -- '-svn%s' `git svn find-rev $head`
+ fi
+
+ # Update index only on r/w media
+ [ -w . ] git update-index --refresh --unmerged /dev/null
+
+ # Check for uncommitted changes
+ if git diff-index --name-only HEAD | grep -v ^scripts/package \
+ | read dummy; then
+ printf '%s' -dirty
+ fi
+
+ # All done with git
+ exit
+fi
+
+# Check for mercurial and a mercurial repo.
+if hgid=`hg id 2/dev/null`; then
+ tag=`printf '%s' $hgid | cut -d' ' -f2`
+
+ # Do we have an untagged version?
+ if [ -z $tag -o $tag = tip ]; then
+
Re: [Openocd-development] Moving to git
!!! And if anyone objects to GIT, please speak up ASAP !!! Why are we moving to GIT anyway? What was wrong with SVN? gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
I did not but I have now and tbh I'm not impressed. Sure git has some advantages, but do we really care about the distributed nature, better branch support, higher performance and other things? What I read was: Also not mentioned are Subversion's support for http(s) and WebDAV, and its excellent support for Windows (in stark contrast to git's) Please keep in mind some people are using Windows here. I hope it's not going to be a mess to get the latest OpenOCD sources or sync with the repository. gr. Ronald Original Message Subject: [Openocd-development] Moving to git From: Øyvind Harboe oyvind.har...@zylin.com To: Ronald Vanschoren yahoogro...@lieron.be Cc: openocd-development@lists.berlios.de Date: Tue Oct 06 2009 08:24:34 GMT+0200 (Romance Standard Time) On Tue, Oct 6, 2009 at 8:23 AM, Ronald Vanschoren yahoogro...@lieron.be wrote: !!! And if anyone objects to GIT, please speak up ASAP !!! Why are we moving to GIT anyway? What was wrong with SVN? Did you read up on git? http://git.or.cz/gitwiki/GitSvnComparsion ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
1. Berlios svn will be made read only and the svn head will be deleted, leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. Question from a dumb-ass: Is the entire repository (including all branches and tags) moved to SF or just head? Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
Hi Dirk, --- Dirk Behme dirk.be...@googlemail.com schrieb am Mo, 5.10.2009: Rolf, could you try if git clone http://git.gitorious.org/u-boot-omap3/mainline.git works for you? Yes, that works for me! I can successfully clone this very small project on github, too: http://github.com/tekkub/addontemplate.git Most probably you have to set export http_proxy=http://username:password@proxy_ip:proxy_port for this. This seems to be the only required setting to make it work. I run Squid on my local machine, and I have http_proxy=http://localhost:8080 set here. GIT honors that setting, and I don't have to configure it explicitly with 'git config http.proxy'. My vote is for a server that supports http for read-only access :-) Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] need help with config file
On Saturday 03 October 2009, John Rigby wrote: You were right about the ir lengths, but I also had to put back in the code that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap with no id and no b01 in the capture. Hmm. I changed the diagnostics a bit in a recent patch, and that leaves it in a good position to just switch over to using the value and mask provided with TAP declaration. Doing it that way ... and the i.mx31 and i.mx25 could both just declare a capture value (or mask!) of zero and have it all work OK -- right? If so, could you work up a patch which does it that way? I suspect that could merge in time for the 0.3.x release, then. Thing is, we do have wierd hardware to cope with and so we evidently need to relax that test. But the original code was a hack since it relaxed it for *everything* instead of just for the minority of cases which really needed it. And on top of that, there was no comment explaining what class of wierdness was involved... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Ronald Vanschoren wrote: Please keep in mind some people are using Windows here. There are quite a few folk using git from Windows... Not three hours ago I pulled a repository onto an XP machine (via cygwin). The build breakage was completely unrelated to GIT. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Nico Coesel wrote: Is the entire repository (including all branches and tags) moved to SF or just head? Right now there are git-svn repositories that have whatever could be imported, but I think just the trunk is at SF. Is there anything in those branches/etc that's of more than historical interest? AFAICT only the Zylin branch has been active for the last year or more. And that can be a branch in their local repository; doesn't need to be in mainline. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Tue, Oct 6, 2009 at 8:45 AM, Nico Coesel ncoe...@dealogic.nl wrote: 1. Berlios svn will be made read only and the svn head will be deleted, leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. Question from a dumb-ass: Is the entire repository (including all branches and tags) moved to SF or just head? Just svn trunk. All work in branches have been merged back in and the svn repository will remain available @ Berlios indefinitely for reference. The release branches are in fact just tags and we may add them back in later on, but we will probably funnel all resources into moving forward rather than rummage in the past. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
My vote is for a server that supports http for read-only access :-) We need and want a git mirror. That git mirror will support http. We haven't decided which mirror yet though. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag_init changes
Committed. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] GNU savannah
Does anyone have experience with http://savannah.nongnu.org? Worth considering for web pages, mailing lists and git mirror? I'm a little bit concerned that they don't have critical mass... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
As per: https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly we do not accept projects with the word open in their name; we suggest you replace it with free instead, or use another project name of your choice. I don't know if this applies to projects under savannah.nongnu.org but I linked to it from there. Øyvind Harboe wrote: Does anyone have experience with http://savannah.nongnu.org? Worth considering for web pages, mailing lists and git mirror? I'm a little bit concerned that they don't have critical mass... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Strontium Sent: dinsdag 6 oktober 2009 14:25 Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] GNU savannah As per: https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly The page looks like it has been written by people that have a very limited view on the real world. I'd like OpenOCD to stay open for any OS. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
The page looks like it has been written by people that have a very limited view on the real world. I'd like OpenOCD to stay open for any OS. Free, dedicated resources w/no advertisement followed up by diligent people powered by enthusiasm. *AND* you don't want them to be nut-jobs? :-) Good luck finding that! I mean nut-jobs in a good sense here and I would proudly count myself amongst them. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
Øyvind Harboe wrote: My vote is for a server that supports http for read-only access :-) We need and want a git mirror. That git mirror will support http. We haven't decided which mirror yet though. Thanks for testing to Rolf! At least we now know that for http://gitorious.org and http://github.com/ http git access works :) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] need help with config file
I agree that using the expected capture value makes a lot more sense than using the zero id. I'll send a patch later today. On Tue, Oct 6, 2009 at 12:49 AM, David Brownell davi...@pacbell.net wrote: On Saturday 03 October 2009, John Rigby wrote: You were right about the ir lengths, but I also had to put back in the code that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap with no id and no b01 in the capture. Hmm. I changed the diagnostics a bit in a recent patch, and that leaves it in a good position to just switch over to using the value and mask provided with TAP declaration. Doing it that way ... and the i.mx31 and i.mx25 could both just declare a capture value (or mask!) of zero and have it all work OK -- right? If so, could you work up a patch which does it that way? I suspect that could merge in time for the 0.3.x release, then. Thing is, we do have wierd hardware to cope with and so we evidently need to relax that test. But the original code was a hack since it relaxed it for *everything* instead of just for the minority of cases which really needed it. And on top of that, there was no comment explaining what class of wierdness was involved... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GNU savannah
Most people I know think I'm a Nut job as well, which is why I'd prefer hosting at Savannah to Sourceforge on purely philosophical grounds myself. I just didn't think you all would want to change the project name. Maybe they would accept it a is, rules were meant to be broken after all. I think the goals of OpenOCD and the FSF align rather highly. Øyvind Harboe wrote: I mean nut-jobs in a good sense here and I would proudly count myself amongst them. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
El Lunes, 5 de Octubre de 2009 22:07:35 David Brownell escribió: On Monday 05 October 2009, Øyvind Harboe wrote: In short, the following will happen: 1. The source will be held in git. https://sourceforge.net/projects/openocd/ !!! And if anyone objects to GIT, please speak up ASAP !!! Could have been sooner certainly. I had my doubts about even suggesting this proposal, but then I thought spending few minutes reading it wouldn't hurt much. I think mercurial [0] could be a good option. It's a well known distributed VCS, maybe not as spread or known as git, but it's fulfilling most if not all general users aspirations. I find it generally speaking easier to use than git and the move from those used to SVN should be less painful. There's at least a specific host site for mercurial projects [1] but there may be others. Mercurial provides an extension called convert able to translate from another VCS, among them SVN. But there's also a mercurial client for SVN repos [2], this should be the equivalent to git-svn. Pushes can be done, either by ssh or by https, which should address proxy issues. It also provides a graphical interface based on the spreaded TortoiseSVN, which is actually called TortoiseHg [3]. Since Mercurial is almost totally written in python, it's multiplatform, as well as TortoiseHg. Also google code is supposed to also accept Mercurial repositories [4] but I'm not sure about the state of this and the urgency suggests that this is not a clear path to follow. I could find out something about this if there is interest. I just wanted to drop this information, forgetting about typical flames, for the sake of completeness. Feel free to thrash it if you think it's too late of useless. Regarding the mailing list point, in case Google groups are found useful, something I'm not totally sure about, they may complete the total move to Google code once it provides general Mercurial hosting. Regards, [0] http://mercurial.selenic.com/wiki/ [1] http://bitbucket.org/ [2] http://bitbucket.org/durin42/hgsubversion/overview/ [3] http://bitbucket.org/tortoisehg/stable/wiki/Home [4] http://googlecode.blogspot.com/2009/04/mercurial-support-for-project- hosting.html -- 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] Switch to non-Berlios mailing list
There may be an obvious reason my suggestion is NOT good but here goes... Why not leave the mailing list here? I just want to make sure an obvious answer is not missed... tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
Notice the number of messages with a subject line of Berlios outage... -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Tom Moulton Sent: Tuesday, October 06, 2009 12:17 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Switch to non-Berlios mailing list There may be an obvious reason my suggestion is NOT good but here goes... Why not leave the mailing list here? I just want to make sure an obvious answer is not missed... tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
LOL ok no problem... I thought most of the outage was the source, not the list... Of course I'd miss any messages when the lists were down :) tom -Original Message- From: Austin, Alex [mailto:alex.aus...@spectrumdsi.com] Sent: Tuesday, October 06, 2009 1:34 PM To: 'Tom Moulton'; openocd-development@lists.berlios.de Subject: RE: [Openocd-development] Switch to non-Berlios mailing list Notice the number of messages with a subject line of Berlios outage... -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Tom Moulton Sent: Tuesday, October 06, 2009 12:17 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Switch to non-Berlios mailing list There may be an obvious reason my suggestion is NOT good but here goes... Why not leave the mailing list here? I just want to make sure an obvious answer is not missed... tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On 2009-10-06, Ra?l S?nchez Siles rsanch...@infoglobal.es wrote: !!! And if anyone objects to GIT, please speak up ASAP !!! I think mercurial [0] could be a good option. It's a well known distributed VCS, maybe not as spread or known as git, but it's fulfilling most if not all general users aspirations. I find it generally speaking easier to use than git and the move from those used to SVN should be less painful. This exact same discuss is taking place in a different open-source project in which I participate, and several people there have also said that they thought mercurial would be an easier transition than git. I would give a few points to mercurial for being written in Python. I would expect it to be a lot more stable than something written in C. However, my opinion shouldn't be weighted very heavily since I'm just a user when it comes to openocd. -- Grant Edwards grante Yow! Are we on STRIKE yet? at visi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
On 2009-10-05, ??yvind Harboe oyvind.har...@zylin.com wrote: Migrate away from Berlios committe wants an alternative to Berlios mailing lists. Some alternatives so far: [...] Anything so long as it works with gmane.org. -- Grant Edwards grante Yow! Not SENSUOUS ... only at FROLICSOME ... and in visi.comneed of DENTAL WORK ... in PAIN!!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag_init changes
On Monday 05 October 2009, Øyvind Harboe wrote:
if (jtag_init_inner(cmd_ctx) == ERROR_OK)
What would you think about changing init_inner() so it
actually *fails* when significant errors are detected?
I still think that fix would have been sufficient to resolve
the problem Michal reported. His issue was that init_inner()
didn't report failure ... so the fallback hard reset logic
never got a chance to trigger. And it would have worked if
it had triggered... his proposed patch added the ability to
force that reset before calling init_inner().
Alternatively, using jtag_add_reset(0,0) to establish a
uniformly sane initial state should address the issue too.
(Since the root cause was the JTAG adapter *starting* in a
state with some resets asserted...) I think I'll try that
one out; I though I had observed the same error Michal was
reporting, when switching configs.
Right now in init_inner() we have:
/* examine chain first, as this could discover the real chain layout */
if (jtag_examine_chain() != ERROR_OK)
{
LOG_ERROR(Trying to use configured scan chain anyway...);
issue_setup = false;
}
... continuing after known brokenness. We might want to let
the wrong version cases succeed, and maybe some others, but
I don't see any valid reason to continue when the number of
TAPs observed doesn't even match the number configured, or
when TDO is stuck high (no device?).
When I run into this error it's because for example there's
only one TAP present but three are configured. Or the IDCODE
is wrong since I used the wrong config file. Or the board is
still in reset (Michal's original problem)...
if (jtag_validate_ircapture() != ERROR_OK)
{
LOG_WARNING(Errors during IR capture, continuing anyway...);
issue_setup = false;
}
... continuing after other known brokenness. Here, continuable
errors would be a lot harder to find; any error likely means we
don't even know the IR register sizes.
if (issue_setup)
jtag_notify_event(JTAG_TAP_EVENT_SETUP);
else
LOG_WARNING(Bypassing JTAG setup events due to errors);
return ERROR_OK;
... returning success regardless of any brokenness observed. So
the logic in the jtag_init() code that tried to recover from such
errors is a NOP, and never triggers.
And note, even after your patch these significant errors are STILL
completely ignored...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag_init changes
On Tue, Oct 6, 2009 at 8:13 PM, David Brownell davi...@pacbell.net wrote: On Monday 05 October 2009, Øyvind Harboe wrote: if (jtag_init_inner(cmd_ctx) == ERROR_OK) What would you think about changing init_inner() so it actually *fails* when significant errors are detected? Now that there is a tcl proc that can be changed for a particular target if need be, I think that makes sense as a default. A custom tcl proc could then handle whatever is appropriate handling for a failure case. You mentioned several other good reasons to propagate failure... Generally ignoring error conditions and continuing is a bad thing. Catching exceptions and handling them (in a target specific tcl proc) is a much better approach. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
On Sunday 27 September 2009, Freddie Chopin wrote:
If it doesn't ... seems buggish, but maybe you
could declare it as a global.
I works when I use a wrapper script, but doesn't work when I use
-c set CRYSTAL_FREQ 1200 -f target/lpc2103.cfg
In fact the same thing happens if you set it in one *.cfg
file and try to reference it from another, with both of
them given as -f ... on the command line.
I had the equivalent of one -f file1.cfg with
global J4
set J4 NAND
proc show_j4 {} { echo SHOW...; echo $J4 }
with another -f file2.cfg calling show_j4 ... result was
a Tcl error claiming there's no such variable as J4.
At first glance, the bug seems caused by command_run_line()
going through some effort to make sure that it doesn't
reuse key parts of the execution environment. That seems
misguided to me, perhaps associated with the notion that
there be only *one* Tcl interpreter. From what I recall
back in the early days of Tcl, interpreters are supposed
to be extremely lightweight ... the way to avoid reuse is
to have your own interpreter/context instance handle.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Grant Edwards Sent: Tuesday, October 06, 2009 12:52 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Moving to git On 2009-10-06, Ra?l S?nchez Siles rsanch...@infoglobal.es wrote: !!! And if anyone objects to GIT, please speak up ASAP !!! I think mercurial [0] could be a good option. It's a well known distributed VCS, maybe not as spread or known as git, but it's fulfilling most if not all general users aspirations. I find it generally speaking easier to use than git and the move from those used to SVN should be less painful. This exact same discuss is taking place in a different open-source project in which I participate, and several people there have also said that they thought mercurial would be an easier transition than git. I would give a few points to mercurial for being written in Python. I would expect it to be a lot more stable than something written in C. However, my opinion shouldn't be weighted very heavily since I'm just a user when it comes to openocd. I also generally prefer python. However, Python apps are really only more stable than C apps insofar as segfaults go. I would dare say git gets much more solid testing, as it's used by the Linux kernel, where just about every new feature will be tried and beaten on. Only one unstable release, ever (so far) in the history of git, has had data consistency problems, and the warning went out on the mailing list within a few minutes. That was years ago, and hasn't happened again since. If you watch Linus' Google Tech Talk on Git, he makes several points about workflows that are only possible with the performance you get from the C-based core of git. He discusses Mercurial as interesting, but it's Python base will cause it to perform worse for many operations. See http://www.whygitisbetterthanx.com for some performance/feature comparisons including with Mercurial. -- Grant Edwards grante Yow! Are we on STRIKE yet? at visi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
My impression, after using git just a little, is that it is a good tool, it takes some learning for effective use. For development work it seems that it gives me much better support for testing several different versions of experimental code than SVN so here it is a big step forward. I do not know anything about mercurial, but beeing written in Python is not enough to convince me, even though I do use and like Python. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Dragonite target script
Dragonite target script
Dragonite target script
diff --git a/tcl/target/dragonite.cfg b/tcl/target/dragonite.cfg
new file mode 100644
index 000..d2e7e32
--- /dev/null
+++ b/tcl/target/dragonite.cfg
@@ -0,0 +1,31 @@
+##
+# Target:Marvell Dragonite CPU core
+##
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME dragonite
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x121003d3
+}
+
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME dragonite -endian $_ENDIAN -chain-position
$_TARGETNAME
+
+reset_config trst_and_srst
+jtag_nsrst_delay 200
+jtag_ntrst_delay 200
+
--
1.6.2.5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] silence bad EICE version number complaint for Dragonite
Dragonite has the same affliction as feroceon. Dragonite has the same affliction as feroceon. diff --git a/src/target/embeddedice.c b/src/target/embeddedice.c index 0d23c12..39f87c7 100644 --- a/src/target/embeddedice.c +++ b/src/target/embeddedice.c @@ -264,7 +264,8 @@ reg_cache_t* embeddedice_build_reg_cache(target_t *target, arm7_9_common_t *arm7 * in some unusual bits. Let feroceon.c validate it * and do the appropriate setup itself. */ - if (strcmp(target_get_name(target), feroceon) == 0) + if (strcmp(target_get_name(target), feroceon) == 0 || + strcmp(target_get_name(target), dragonite) == 0) break; LOG_ERROR(unknown EmbeddedICE version (comms ctrl: 0x%8.8 PRIx32 ), buf_get_u32(reg_list[EICE_COMMS_CTRL].value, 0, 32)); } -- 1.6.2.5 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SourceForge terms changes
Hello All, FYI, a new version of SF.net terms of use has been posted and is to take effect on the 29th. http://sourceforge.net/apps/trac/sitelegal/wiki/Terms%20of%20Use Not sure if changes affect OpenOCD, but worth checking IMO. -- WBR, Igor mailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] silence bad EICE version number complaint for Dragonite
I committed both of yoru Dragonite patches. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] silence bad EICE version number complaint for Dragonite
On Tue, 6 Oct 2009, David Brownell wrote: I committed both of yoru Dragonite patches. Thx. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About AGDI interface of RealView MDK and SWJ support
simon qian wrote: Does is possible to get protocol of AGDI interface of RealView MDK? Then OpenOCD will be supported by it. As for AGDI - I have little interest in supporting Keil uVision - the closed IDE from Keil. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11379.html I believe others share my view I don't know about the SWJ status. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About AGDI interface of RealView MDK and SWJ support
On Tuesday 06 October 2009, Duane Ellis wrote:
I don't know about the SWJ status.
As I understand it, SWJ is the one-wire trace output scheme used
by certain trimmed-down Cortex-M3 parts. It contrasts with the
more typical clock-plus-N-Wire alternative (N in {1, 2, 4}).
And it's built using a variant of the SWD two-wire messaging
scheme (contrasting with JTAG's 4-wire one).
So, SWJ gets nowhere in OpenOCD until SWD is working.
And we've seen no SWD patches at all.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About AGDI interface of RealView MDK and SWJ support
So, SWJ gets nowhere in OpenOCD until SWD is working. And we've seen no SWD patches at all. Actually we did, but it is a long time ago and they were very disruptive. We get SWD/SWJ questions every so often, but I'm not very excited... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
