David Brownell wrote:
On Tuesday 19 January 2010, Spencer Oliver wrote:
David Brownell wrote:
On Tuesday 19 January 2010, Spencer Oliver wrote:
Skip over a bkpt instruction if found on resume/step.
Only software breakpoints known to openod are handled.
So this handles the special case of a
Hello everyone,
I have to replay an XSVF file using openocd which uses the XSDRB, XSDRC
and XSDRE commands. I'm definitely not a JTAG expert, but I've hacked
together a patch to support these three commands. It seems to work on my
Spartan3A device, though I haven't done a lot of testing yet.
David Brownell wrote:
Though: I looked at the GDB protocol spec and it says that undefined
areas are presumed to be RAM. So I'm a bit puzzled about just what
that current code is there for...
The gdb docs may be incorrect, unless the bug has been fixed in gdb.
last time i looked gdb =6.8
Attached patch flashes str710 correctly. This is a fixed version of
David's patch.
(gdb) target remote 10.0.0.136:
Remote debugging using 10.0.0.136:
0xe6056fa8 in ?? ()
(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr High Addr Attrs
0 y 0x
On Wed, Jan 20, 2010 at 6:58 AM, David Brownell davi...@pacbell.net wrote:
Here's my current summary of *OPEN* issues with RC1.
If you raised an issue and it's not on this list then either
it's now resolved, or else I missed that and it's still an
open issue. Please verify.
If you know
On Wed, Jan 20, 2010 at 8:40 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 January 2010, Øyvind Harboe wrote:
New thread on new features to gdb memory maps.
Not sure what you mean by caching ... if the CPU is running, we
can't assume it's not going to touch such areas.
We
On Wednesday 20 January 2010, Spencer Oliver wrote:
As a side note this issue will also apply to armv5 cores with the bkpt
instruction.
Curious ... there's already some logic to skip breakpoints
there, you're saying it doesn't handle this case right?
yes openocd will handle
David Brownell wrote:
On Wednesday 20 January 2010, Spencer Oliver wrote:
As a side note this issue will also apply to armv5 cores with the bkpt
instruction.
Curious ... there's already some logic to skip breakpoints
there, you're saying it doesn't handle this case right?
yes openocd will
From f570e0e202e12278025e85fed1a5807dffa7 Mon Sep 17 00:00:00 2001
From: Spencer Oliver ntfr...@users.sourceforge.net
Date: Wed, 20 Jan 2010 10:45:15 +
Subject: [PATCH] BUILD: remove cygwin build warnings
Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net
---
Hi Alexei
On 1/20/10, Øyvind Harboe oyvind.har...@zylin.com wrote:
When I try to invoke target_read_u32(), I get a message in the log: Error:
131 6 target.c: 1477 target_read_u32(): Target not examined yet
Can anyone suggest how to try to get rid of the error?
Normally a reset init would fix
On Wednesday 20 January 2010, Øyvind Harboe wrote:
Attached patch flashes str710 correctly. This is a fixed version of
David's patch.
With various bits of debugging stuff I removed from the version I posted,
and without some comment updates...
Could you resend as a delta patch against what I
On Wednesday 20 January 2010, Spencer Oliver wrote:
Subject: [PATCH] BUILD: remove cygwin build warnings
Which version of cygwin? I've been doing semi-regular
build tests on the current version, and haven't seen
any warnings at all from those files.
- Dave
p.s. Not that I'm promising to
On Wed, Jan 20, 2010 at 11:58 AM, David Brownell davi...@pacbell.net wrote:
On Wednesday 20 January 2010, Řyvind Harboe wrote:
Attached patch flashes str710 correctly. This is a fixed version of
David's patch.
With various bits of debugging stuff I removed from the version I posted,
and
arm7_9 fast_memory_access and working area nags added.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/target/arm7_9_common.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/target/arm7_9_common.c b/src/target/arm7_9_common.c
index
On Wednesday 20 January 2010, Øyvind Harboe wrote:
On Wed, Jan 20, 2010 at 11:58 AM, David Brownell davi...@pacbell.net wrote:
On Wednesday 20 January 2010, Řyvind Harboe wrote:
Attached patch flashes str710 correctly. This is a fixed version of
David's patch.
With various bits of
OK, I'll look at this and double-check -- thanks.
To be clear: you're OK with merging my original + your updates?
Yes.
If so, and presuming I don't see any issues, I'll do that.
Super!
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
David Brownell wrote:
On Wednesday 20 January 2010, Spencer Oliver wrote:
Subject: [PATCH] BUILD: remove cygwin build warnings
Which version of cygwin? I've been doing semi-regular
build tests on the current version, and haven't seen
any warnings at all from those files.
- Dave
p.s.
I suspect there is a problem with ARM11 debugging for version
v0.4.0-rc1-128-g0c3a4b4. It seems I cannot insert breakpoints:
Here I single step, to prove that I can reach the address I want to
set the breakpoint at:
(gdb) moni reset init
JTAG tap: imx31.etb tap/device found: 0x2b900f0f (mfg:
On Wed, Jan 20, 2010 at 2:57 PM, Edgar Grimberg
edgar.grimb...@zylin.com wrote:
I suspect there is a problem with ARM11 debugging for version
v0.4.0-rc1-128-g0c3a4b4. It seems I cannot insert breakpoints:
I've done a git bisect:
$ git bisect log
git bisect start
# good:
openocd does not start with the target configfile due to the case in the
dependent config file.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
tcl/target/at91sam3u4e.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcl/target/at91sam3u4e.cfg
On Wednesday 20 January 2010, Michael Grzeschik wrote:
-source [find target/at91sam3uxx.cfg]
+source [find target/at91sam3uXX.cfg]
Merged; thanks.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Wednesday 20 January 2010, Spencer Oliver wrote:
David Brownell wrote:
Which version of cygwin? I've been doing semi-regular
build tests on the current version, and haven't seen
any warnings at all from those files.
I have a v3.4.4 and a v4.3.4 based gcc, the issues are from v3.
Feel free to submit patches for these! :)
Priority on regression fixes, but any fixes that don't de-stabilize
are still good to go.
- Dave
On Wednesday 20 January 2010, Edgar Grimberg wrote:
* I see some error messages for STR710 config:
Error: command 'str7x' is already registered in
On Wednesday 20 January 2010, Øyvind Harboe wrote:
OK, I'll look at this and double-check -- thanks.
To be clear: you're OK with merging my original + your updates?
Yes.
If so, and presuming I don't see any issues, I'll do that.
Super!
Merged, with minor tweaks.
On Wednesday 20 January 2010, Øyvind Harboe wrote:
arm7_9 fast_memory_access and working area nags added.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
OK, but it'd be *much* cleaner if it did
if (!get_target_reset_nag())
return ERROR_OK;
if (problem)
On Wednesday 20 January 2010, Edgar Grimberg wrote:
$ git bisect bad
5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
commit 5eb893ec41c8c6cf6499558b6fed826b65e18a16
Author: David Brownell dbrown...@users.sourceforge.net
Date: Tue Nov 24 01:27:16 2009 -0800
ARM11: partial
Do you happen to have a theory for how a patch that doesn't touch
breakpoint logic would cause breakpoint failures?
Nope, it was a brain dead bisect done after hours. Close to the end of
the bisect there were some other error messages and I marked those
bisects as bad. How should I do this to
Rather than issuing a halt and then stepi/resume, just
wait for target to halt.
Issue a sterner warning via gdb console that any gdb
register changes will be ignored in this case.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/server/gdb_server.c | 12
1 files
On Wed, Jan 20, 2010 at 8:39 PM, David Brownell davi...@pacbell.net wrote:
On Wednesday 20 January 2010, Řyvind Harboe wrote:
OK, I'll look at this and double-check -- thanks.
To be clear: you're OK with merging my original + your updates?
Yes.
If so, and presuming I don't see any
On Wed, Jan 20, 2010 at 8:42 PM, David Brownell davi...@pacbell.net wrote:
On Wednesday 20 January 2010, Řyvind Harboe wrote:
arm7_9 fast_memory_access and working area nags added.
Signed-off-by: Řyvind Harboe oyvind.har...@zylin.com
OK, but it'd be *much* cleaner if it did
if
Hello, all.
I'm sorry for stupid questions.
I look at imx35.cfg and see these lines:
---
# No IDCODE for this TAP
jtag newtap $_CHIPNAME whatchacallit -irlen 4 -ircapture 0 -irmask 0x0
-expected-id 0x0
jtag newtap $_CHIPNAME sdma -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id
$_SDMATAPID
---
2010/1/21 Alexei Babich a.bab...@rez.ru:
Hello, all.
I'm sorry for stupid questions.
I look at imx35.cfg and see these lines:
---
# No IDCODE for this TAP
jtag newtap $_CHIPNAME whatchacallit -irlen 4 -ircapture 0 -irmask 0x0
-expected-id 0x0
jtag newtap $_CHIPNAME sdma -irlen 5
I believe SDMA and SJC are always in bypass so it could work as long
as the sum of SDMA and SJC lengths are equal?
Unfortunately, all aspects of the JTAG incomprehensible to me. That's why I
asked in this conference.
Did you try fixing the config file?
Immediately, as soon as understanding.
33 matches
Mail list logo
