> 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.
2010/1/21 Alexei Babich :
> 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 -i
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
---
On Wed, Jan 20, 2010 at 8:42 PM, David Brownell wrote:
> On Wednesday 20 January 2010, Řyvind Harboe wrote:
>> arm7_9 fast_memory_access and working area nags added.
>>
>> Signed-off-by: Řyvind Harboe
>
> OK, but it'd be *much* cleaner if it did
>
> if (!get_target_reset_nag())
>
On Wed, Jan 20, 2010 at 8:39 PM, David Brownell 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 issu
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
---
src/server/gdb_server.c | 12
1 files changed, 8 insertions(+), 4 d
> 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
On Wednesday 20 January 2010, Edgar Grimberg wrote:
> $ git bisect bad
> 5eb893ec41c8c6cf6499558b6fed826b65e18a16 is first bad commit
> commit 5eb893ec41c8c6cf6499558b6fed826b65e18a16
> Author: David Brownell
> Date: Tue Nov 24 01:27:16 2009 -0800
>
> ARM11: partial support for standard ARM
On Wednesday 20 January 2010, Øyvind Harboe wrote:
> arm7_9 fast_memory_access and working area nags added.
>
> Signed-off-by: Øyvind Harboe
OK, but it'd be *much* cleaner if it did
if (!get_target_reset_nag())
return ERROR_OK;
if (problem)
nag(p
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.
_
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, 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
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
https://lists.berlios.de/mai
openocd does not start with the target configfile due to the case in the
dependent config file.
Signed-off-by: Michael Grzeschik
---
tcl/target/at91sam3u4e.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcl/target/at91sam3u4e.cfg b/tcl/target/at91sam3u4e.cfg
index
On Wed, Jan 20, 2010 at 2:57 PM, Edgar Grimberg
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: [70f735007d7b0f7ec9d269c4529d9f62c0eb779d] Th
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: 0x7
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
> 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
http://www.zylin.com/z
On Wednesday 20 January 2010, Øyvind Harboe wrote:
> On Wed, Jan 20, 2010 at 11:58 AM, David Brownell 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 st
arm7_9 fast_memory_access and working area nags added.
Signed-off-by: Øyvind Harboe
---
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 ca1d84f..509e91e 100644
--- a/src/ta
On Wed, Jan 20, 2010 at 11:58 AM, David Brownell 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 without some com
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 conti
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
Hi Alexei
On 1/20/10, Øyvind Harboe 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 that...
>
Also
>From f570e0e202e12278025e85fed1a5807dffa7 Mon Sep 17 00:00:00 2001
From: Spencer Oliver
Date: Wed, 20 Jan 2010 10:45:15 +
Subject: [PATCH] BUILD: remove cygwin build warnings
Signed-off-by: Spencer Oliver
---
src/target/cortex_m3.c|4 ++--
src/target/mips32_pracc.c |2 +-
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?
>>>
>
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 wi
On Wed, Jan 20, 2010 at 8:40 AM, David Brownell 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 can tel
On Wed, Jan 20, 2010 at 6:58 AM, David Brownell 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 about other issu
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 0x400
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
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.
I've
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 sp
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> >
> > I can't see anything to do with that beyond documenting it.
> >
> > If you write *without* enabling that checksum-updating feature,
> > it won't boot (as I recall folk complaining).
> >
> > If you write with it *enabled*, then verify_image fa
34 matches
Mail list logo
