Here is a set of commands that reproduces my problem.
While I agree with David about -c and -f bug, this is a different one.
# Ubuntu 9.04
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd ./openocd
./bootstrap
./configure --enable-maintainer-mode --enable-dummy
make
cd src
Don't add extra TCK in current state; exit from RESET had four extras.
Only IDLE -- IDLE needs such an extra clock. (At least one TCK must
be issued.)
Allow entry to RESET; SVF allows it, so must we (despite those entries
being commented out of the statemove table).
When entering RESET, always
As decided a while back, this isn't a transition we want to chance.
Whenever someone wants to got to RESET, force it.
---
Still depends on the JTAG adapter to get it right though, which
many don't. (FT2232 does now.)
src/jtag/core.c | 12 +++-
1 file changed, 7 insertions(+), 5
On Monday 19 October 2009, michal smulski wrote:
# This line does fail
./openocd -s ../tcl/target/ -f ../tcl/target/telo.cfg -c 'interface
dummy' --debug 3 -c proc jtag_init {} {jtag arp_init-reset if { [info
exists RESET_ME] } {jtag arp_init-reset}}
Perhaps I'm unclear. How does it fail?
Hi,
I'm trying to download u-boot image into sdram to run, i think openocd can do
it, so i wrote a script and run openocd, my dongle is j-link V7.0, cpu is
FA526, and openocd version is 0.2.0, openocd-0.2.0.tar.bz2 download from
On Mon, Oct 19, 2009 at 11:40 PM, David Brownell davi...@pacbell.net wrote:
On Monday 19 October 2009, Nicolas Pitre wrote:
Without this fix, the following code cannot be single stepped:
add ip, pc, #1
bx ip
[thumb code here]
The same thing will be needed with
On Tue, Oct 20, 2009 at 1:10 AM, David Brownell davi...@pacbell.net wrote:
On Monday 19 October 2009, Øyvind Harboe wrote:
There is an autoerase option to flash write_image.
Would you object strongly to autoerase automatically
unlocking the flash if necessary?
That sounds more like
On Tue, Oct 20, 2009 at 2:30 AM, David Brownell davi...@pacbell.net wrote:
On Monday 19 October 2009, Øyvind Harboe wrote:
I'd like to see openocd forbidding build == src dir:
Not I. That's the *standard* build environment in almost
all software projects! The first one taught to apprentice
On Tue, Oct 20, 2009 at 5:11 AM, Zach Welch z...@superlucidity.net wrote:
On Mon, 2009-10-19 at 19:24 +0200, Øyvind Harboe wrote:
I'd like to see openocd forbidding build == src dir:
Not a good idea.
Why?
I see that I have to give up on this one by being outvoted. That's
OK.
--
Øyvind
Øyvind Harboe wrote:
I'd like to see openocd forbidding build == src dir:
Strong NAK from me. Building inside the source directory is the standard
procedure for most software packages, and it makes development easier
because I don't have to switch directories to examine generated files.
David Brownell wrote:
On Monday 19 October 2009, Øyvind Harboe wrote:
Does anyone feel very strongly about flash protection?
Dunno about strongly, but given my druthers it'd stay
the way it is now. I've not observed it to be a problem.
It is if you use Intel flashs that come up
Dean Glazeski wrote:
Another thing of interest is a feature list. I've started a feature
list in this email and additions are welcome.
I don't see how a GUI will improve my work in any of these areas:
1. OpenOCD server configuration
a. Telnet Port
b. GDB Port
c. TCL Port
OpenOCD has started some work on a GUI using a web
interface, look at the httpd server in the development section,
the builtin web server works today. It should include
some memory browsing, flash programming page,
simple small scale production page for non-engineers, etc.
A web interface is
On Monday 19 October 2009, Michael Schwingen wrote:
And to allow things like erase the whole flash to
preserve the boot loader (etc) unless something
explicitly enables erasing it...
No. If I call for a complete chip erase, I want a complete chip erase,
not something that preserves
-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen
Sent: dinsdag 20 oktober 2009 8:48
To: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] OpenOCD GUI
On Monday 19 October 2009, Øyvind Harboe wrote:
Thanks; I'll merge this soon.
I committed this, but forgot to post back to the list
that I've done so.
No prob; I saw that as I was about to merge. ;)
Seems like you're much more up to speed on this than I and
have spotted other cases...
On Tue, Oct 20, 2009 at 8:24 AM, michal smulski michal.smul...@ooma.com wrote:
Here is a set of commands that reproduces my problem.
While I agree with David about -c and -f bug, this is a different one.
# Ubuntu 9.04
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd
IMHO a GUI is a good idea but it has to be cross-platform. I have been
using WxWidgets for cross platform development for several years and I
must say the transfer between Windows and Linux is seemless.
Cross platforms w/dependencies during compilation or running
is not great either.
For now
2009/10/20 David Brownell davi...@pacbell.net
Can you verify that all your MinGW-W64
patches have now merged, and the result builds?
Compiled with MinGW-W64 on Vista 64 and MinGW-W32 as well as cygwin (with
-mno-cygwin) on XP 32 and everything looks good.
Many thanks.
I've added an unlock option to flash write_image.
Testing much appreciated!
The code assumes that invoking unprotect on a sector
that is already unprotected is a fast and harmless
no-op which returns success.
I also added a faux flash driver, the goal is to have a fake
target that basic testing
-Original Message-
From: Øyvind Harboe [mailto:oyvind.har...@zylin.com]
Sent: dinsdag 20 oktober 2009 9:33
To: Nico Coesel
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] OpenOCD GUI
IMHO a GUI is a good idea but it has to be cross-platform. I have
Cross platforms w/dependencies during compilation or running
is not great either.
The GUI doesn't need to be part of OpenOCD.
The alternative is to create a complete API and stick to it.
We're not keen, nor do we see the need for the sort
of simple functionality that has been outlined.
For
Would anybody object strongly to making target_write_memory()
temporarily disable MMU read-only bits?
This would be e.g. to enable setting breakpoints in memory
the MMU has mapped as read-only.
If someone has tips or ideas on how to implement this, I would
greatly appreciate input.
--
Øyvind
Øyvind Harboe wrote:
Would anybody object strongly to making target_write_memory()
temporarily disable MMU read-only bits?
This would be e.g. to enable setting breakpoints in memory
the MMU has mapped as read-only.
If someone has tips or ideas on how to implement this, I would
greatly
On Tue, Oct 20, 2009 at 6:10 PM, Magnus Lundin lun...@mlu.mine.nu wrote:
Øyvind Harboe wrote:
Would anybody object strongly to making target_write_memory()
temporarily disable MMU read-only bits?
This would be e.g. to enable setting breakpoints in memory
the MMU has mapped as read-only.
On Tuesday 20 October 2009, Øyvind Harboe wrote:
The alternative is to create a complete API and stick to it.
We're not keen, nor do we see the need for the sort
of simple functionality that has been outlined.
Web access *IS* an API ... at least, as soon as
any client starts to use it that
I would like to see openocd always start, even if the config
file is invalid. Then, it can be configured via telnet and,
hopefully, Have a command to dump a config file. If the telnet
interface supported completion a la Cisco routers (press ? to
list available completions), it would not be
This layers parts of XSVF directly over SVF, to handle XSTATE better,
instead of expecting jtag_add_pathmove() to conform (it doesn't).
It also removes related bogus comments about jtag_add_pathmove().
There is one set of XSTATE cases that's not handled right yet: when
it's used to build some
You can do that if you want. Otherwise, since every git command uses
git rev-parse implicitly, the result of git describe is a valid
revision descriptor.
You can git checkout -b my_temp_branch output_of_git_describe
-Original Message-
From: openocd-development-boun...@lists.berlios.de
“What do you think is the worst that could happen by issuing a 0 + on an
integer value that is meant to be used as a valid pointer in the first place?”
Remember: (((int32_t *)0) + 5) == 20.
From: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de]
As noted recently by Alex, we're carrying around significant
quantities of unwanted cruft in the git repository. If you
have a current clone, you can see it by:
git whatchanged -- zy1000
That's around 100 MBytes of useless stuff that gets pulled,
and then carried around in repositories.
On Thu, Oct 15, 2009 at 12:39 AM, David Brownell davi...@pacbell.netwrote:
On Monday 28 September 2009, Brian Hutchinson wrote:
I have a BeagleBoard now :)
It was a good but busy week!
Thanks for the report. ESC can be fun.
TI didn't happen to have XDS100 v2 prototypes did they?
Thanks for spotting this and doing the work!
It's great to have this out of the way and your timing is good.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development
On Tuesday 20 October 2009, Brian Hutchinson wrote:
Looks like they had something similar there:
http://www.embedded.com/esc/22864?printable=true
Not quite the same thing ... that's a DSP-on-a-stick,
with an on-board XDS100-compatible JTAG. That is,
it uses a full speed FT2232, not high
A very valid point indeed.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Tue, 2009-10-20 at 11:03 -0700, David Brownell wrote:
As noted recently by Alex, we're carrying around significant
quantities of unwanted cruft in the git repository. If you
have a current clone, you can see it by:
git whatchanged -- zy1000
That's around 100 MBytes of useless
On Tuesday 20 October 2009, David Brownell wrote:
This layers parts of XSVF directly over SVF, to handle XSTATE better,
instead of expecting jtag_add_pathmove() to conform (it doesn't).
It also removes related bogus comments about jtag_add_pathmove().
... and in fact I'm thinking that XSVF
On Tuesday 20 October 2009, Zach Welch wrote:
- From time T+2 and later, everyone will want to get new clones
of that repository. I'll send out an email announcing this,
presumably as a followup on this thread.
Actually, it turns out that I may be able to avoid that
step ... leave
On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote:
On Tuesday 20 October 2009, Zach Welch wrote:
- From time T+2 and later, everyone will want to get new clones
of that repository. I'll send out an email announcing this,
presumably as a followup on this thread.
On Tue, Oct 20, 2009 at 9:47 PM, wxzzzh wxz...@163.com wrote:
From web search, I know you are a specialist on openocd and j-link,
i have problem in my debug with them, it always Error: Cannot find jlink
Interface!.
I guess it's because of the lack of proper driver installation, but i can't
On Tuesday 20 October 2009, Zach Welch wrote:
On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote:
On Tuesday 20 October 2009, Zach Welch wrote:
- From time T+2 and later, everyone will want to get new clones
of that repository. I'll send out an email announcing this,
On Tue, 2009-10-20 at 16:24 -0700, David Brownell wrote:
On Tuesday 20 October 2009, Zach Welch wrote:
On Tue, 2009-10-20 at 14:49 -0700, David Brownell wrote:
On Tuesday 20 October 2009, Zach Welch wrote:
- From time T+2 and later, everyone will want to get new clones
of
Le 20/10/2009 02:59, Øyvind Harboe a écrit :
On Tue, Oct 20, 2009 at 5:11 AM, Zach Welchz...@superlucidity.net wrote:
On Mon, 2009-10-19 at 19:24 +0200, Øyvind Harboe wrote:
I'd like to see openocd forbidding build == src dir:
Not a good idea.
Why?
Because
On Wed, Oct 21, 2009 at 8:12 AM, wxzzzh wxz...@163.com wrote:
for the device driver, it's said you can never uninstall it once you install
it, does this mean i'll lost the chance to use Segger softwares forever?
You can switch between the Segger driver and libusb-win32 device
driver. When you
On Tuesday 20 October 2009, David Brownell wrote:
This layers parts of XSVF directly over SVF, to handle XSTATE better,
instead of expecting jtag_add_pathmove() to conform (it doesn't).
I'm going to commit this even though I can't test it.
Since we *know* jtag_add_statemove() [TYPO ABOVE!] is
On Tuesday 20 October 2009, Zach Welch wrote:
If we go this route, would we even need to expose an '-old' GIT tree?
In one word: backup!
I was careful in the use of the word expose. :) Yes, we definitely
want to create a copy on the server for backup purposes, but does it
need to
This is the hack I used to dump TMS path tables at startup.
---
src/jtag/interface.c | 41 +
1 file changed, 41 insertions(+)
--- a/src/jtag/interface.c
+++ b/src/jtag/interface.c
@@ -375,6 +375,47 @@ tap_state_t tap_state_by_name(const char
Since I was trying to make sense of them, I wrote a quickie
utility to dump the old and short path tables on startup.
The results follow (and the patch will be in the next email).
Format: { start, [next, ...,] end }. Yes, they all involve
at least one TCK cycle, even if start == end.
I'm
On Wed, Oct 21, 2009 at 11:08 AM, wxzzzh wxz...@163.com wrote:
with vmware, you can run gdb in linux, openocd in windows, and let them
together, you need not to boot to change os you want to use, it's really
convenient, recommend you to take a try.
As I mentioned, you can run openocd under
On Tue, 2009-10-20 at 20:31 -0700, David Brownell wrote:
On Tuesday 20 October 2009, Zach Welch wrote:
If we go this route, would we even need to expose an '-old' GIT tree?
In one word: backup!
I was careful in the use of the word expose. :) Yes, we definitely
want to
On Tue, 2009-10-20 at 08:58 +0200, Øyvind Harboe wrote:
On Tue, Oct 20, 2009 at 2:30 AM, David Brownell davi...@pacbell.net wrote:
On Monday 19 October 2009, Øyvind Harboe wrote:
[snip]
- there can be hard to track errors such as bin2char being
left in src/helper and subsequently trying to
51 matches
Mail list logo
