On Wed, Nov 4, 2009 at 4:24 AM, Dennis.Cheng wrote:
> In arm920t_write_memory, how about imitate arm926ejs_write_memory?
Could you submit a patch?
I tried to make minimal changes before 0.3, but as soon as 0.3 is out
of the door I'd like arm920t to support breakpoints in memory
marked as read on
>> proc fwd {n} {
>> for {set i 0} {$i < n} {set i [expr $i+1]} {
>> step
>> }
>> }
> If I guess correctly the above is bash script, could we execute bash
> script under openocd console?
> appreciate your help,
> miloody
The above is a tcl script that you paste into your config file.
Then
In arm920t_write_memory, how about imitate arm926ejs_write_memory?
if (arm920t->armv4_5_mmu.mmu_enabled && (count == 1) && ((size==2) ||
(size==4)))
{
/* special case the handling of single word writes to bypass MMU
* to allow implementation of breakpoints in memory marked
On Tue, Nov 03, 2009 at 10:13:24PM +0100, Øyvind Harboe wrote:
> >> Should this fix be included for 0.3 or not?
> >
> > Doesn't matter to me...
>
> What I meant to ask is: do you think other OpenOCD
> users would appreciate it if we included this fix at this
> advanced stage?
I have no idea what
arm7_9_write_core_regs did not update the core_cache and changes would
get clobbered by arm7_9_full_context.
This change updates the core_cache before writing the register list.
---
src/target/arm7_9_common.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git
On Tuesday 03 November 2009, Mariano Alvira wrote:
>
> > What I meant to ask is: do you think other OpenOCD
> > users would appreciate it if we included this fix at this
> > advanced stage?
>
> I have no idea what other openocd users would appreciate. Do other
> users poke core registers a lot?
How's this?
(Confirmation that *this* patch fixes the problem is still missing...)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 553e7bdd606ee0b7015e95f037b07e2dcddb375e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvi
On Tuesday 03 November 2009, Øyvind Harboe wrote:
> Should we include this fix for 0.3?
Only if it's updated to comment that it *still* makes
an unwise assumption about target clock rate. If it's
running with a 32 KHz clock, will that timeout be long
enough? How about 8 KHz? Or lower? :)
Test
On Tuesday 03 November 2009, loody wrote:
> 4. why we cannot set break point in the branch slot?
That would be a core-specific issue. I use OpenOCD
mostly for ARMs ... which doesn't have such a notion.
> if I remember correctly, branch slot is the place that cpu may/may
>not execute.But w
On Tuesday 03 November 2009, loody wrote:
> 3. can we do some constant steps?
> we can use "step" to execute 1 instruction, but is there any "step
> 10", which can let up execute 10 instructions?
Not today. The parameter to "step" is an address to resume
from, not a count.
I've wanted such a
>> Should this fix be included for 0.3 or not?
>
> Doesn't matter to me...
What I meant to ask is: do you think other OpenOCD
users would appreciate it if we included this fix at this
advanced stage?
It's a risk/reward judgment on whether to include
bugfixes at an advanced stage in the testing cy
On Tuesday 03 November 2009, Dean Glazeski wrote:
> I thought I might throw this in here, but the last time I tried to use the
> CRC check, it didn't work. This was a long time ago, but I believe the
> problem was due in part to interrupts being enabled on the chip. Is this
> resolved, too?
No i
On Tue, Nov 3, 2009 at 8:55 PM, David Brownell wrote:
> On Tuesday 03 November 2009, zzzh.2007 wrote:
>> Hi,
>>
>> For FA526 core, following bugs exist:
>> 1. after making a step(in openocd-0.3.0-rc0) at reset vector
>> (at addr of 0, which is LDR pc 0x5c), the pc did not skip to
>> 0x5c, but to 0
On Tuesday 03 November 2009, Peter Denison wrote:
> Unfortunately this is down to how the firmware in the adapter is written.
> Comms is limited to 64 byte USB packets, and the WRITE_READ command can
> therefore take a maximum of 488 bits (61 bytes after 3 header bytes). The
> 640 bit IDCODE sc
Hi:
thanks all your kind help :)
2009/11/4 Øyvind Harboe :
> On Tue, Nov 3, 2009 at 8:58 PM, David Brownell wrote:
>> On Tuesday 03 November 2009, loody wrote:
>>> 3. can we do some constant steps?
>>> we can use "step" to execute 1 instruction, but is there any "step
>>> 10", which can let up
I thought I might throw this in here, but the last time I tried to use the
CRC check, it didn't work. This was a long time ago, but I believe the
problem was due in part to interrupts being enabled on the chip. Is this
resolved, too?
// Dean Glazeski
On Tue, Nov 3, 2009 at 4:12 PM, David Brown
The current code for the USBprog adapter fails right after init when
trying to do the DRSCAN for IDCODEs with:
Info : 284 201 core.c:948 jtag_examine_chain_display(): JTAG tap: sam7x256.cpu
tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Warn : 285 201 core.c:986 jtag_examine_c
On Tuesday 03 November 2009, Øyvind Harboe wrote:
> How's this?
>
> (Confirmation that *this* patch fixes the problem is still missing...)
Seems fair to me.
If Pieter can confirm before 0.3 finalizes, merge it on
the grounds that it can't be _worse_ and may well fix that.
__
On Tue, Nov 3, 2009 at 8:58 PM, David Brownell wrote:
> On Tuesday 03 November 2009, loody wrote:
>> 3. can we do some constant steps?
>> we can use "step" to execute 1 instruction, but is there any "step
>> 10", which can let up execute 10 instructions?
>
> Not today. The parameter to "step"
On Tue, Nov 03, 2009 at 09:24:31PM +0100, Øyvind Harboe wrote:
> How did this problem manifest itself?
As a quick way to get code running on a mc13224v, I perform a
soft_reset_halt, load an image into RAM, and then I need to bypass the
internal bootloader by changing the PC with:
arm7_9_write_
On Tuesday 03 November 2009, Mariano Alvira wrote:
> arm7_9_write_core_regs did not update the core_cache and changes would
> get clobbered by arm7_9_full_context.
Hmm, that's what it's supposed to do. The docs read:
arm7_9 write_core_reg num mode word[Debug
On Tue, Nov 03, 2009 at 03:03:47PM -0700, David Brownell wrote:
> Making me wonder why the command still exists. If no current
> developers are using it, I'd be inclined to just remove it
> in the 0.4.x cycle...
Well I certainly didn't like that command as-is!
>
> So that when you were typing
On Tuesday 03 November 2009, Matt Hsu wrote:
> Hi all,
>
> I would like to support another cortex A8 machine, s5pc100.
> In theory, add proper target configs should be enough.
> Since the support of cortex A8 is almost finished.
>
> The first issue comes up is how do I know the CPUTAPID for the n
On Tuesday 03 November 2009, zzzh.2007 wrote:
> Hi,
>
> For FA526 core, following bugs exist:
> 1. after making a step(in openocd-0.3.0-rc0) at reset vector
> (at addr of 0, which is LDR pc 0x5c), the pc did not skip to
> 0x5c, but to 0xfc(the instruction at addr of 4 is LDR pc 0x100)
Is that is
Hi, David,
Yes, the bugs still exists, i am looking into the codes by myself now, though
i'm not familiar with the JTAG protocol.
Hopefully, i can get support from you, or one of the developers, i can provide
hardware support if needed.
Thanks & Regards.
--
Hi, David,
Yes, the bugs still exists, i am looking into the codes by myself now, though
i'm not familiar with the JTAG protocol.
Hopefully, i can get support from you, or one of the developers, i can provide
hardware support if needed.
Thanks & Regards.
--
How did this problem manifest itself?
Should this fix be included for 0.3 or not?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-developm
Should we include this fix for 0.3?
Confirmation that it works and looks OK would be a point
in favor. Hint! Hint! ;-)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From e37076a747bc1f1a709ec9feb57c9492dc18b062 Mon Sep 17 00:
How's this?
20 second timeout/megabyte
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 1b60ce8d5badb730739744323cb7cd4ac6c252af Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Tue, 3 Nov 2009 15:3
No need to run a git bisect :)
I have confirmed that my hunch was correct.
In
File: src/target/arm7_9_common.c
Function: arm7_9_checksum_memory
Line: 2825
crc_algorithm->address, crc_algorithm->address + (sizeof(arm7_9_crc_code) - 8),
2, &armv4_5_info)) != ERROR_OK)
I changed the timeout
> The first issue comes up is how do I know the CPUTAPID for the new board?
> I went through the document of openocd, but could not find out
> comprehensive description
> talked about how to obtain CPUTAPID. What do I miss?
> Or what should I be familiar with first?
> Any suggestions would be great
On Tue, Nov 3, 2009 at 2:15 PM, Dennis.Cheng wrote:
> Thanks. It works well :-).
I've pushed the fix.
I'm a little bit worried about being able to test the case where
a write to a cache line for a breakpoint.
Here the code has to flush that cache line + invalidate the cache line.
--
Øyvind H
Hi,
For FA526 core, following bugs exist:
1. after making a step(in openocd-0.3.0-rc0) at reset vector(at addr of 0,
which is LDR pc 0x5c), the pc did not skip to 0x5c, but to 0xfc(the instruction
at addr of 4 is LDR pc 0x100)
2. can't step or set break point via gdb commands(next, break).
Hi all,
I would like to support another cortex A8 machine, s5pc100.
In theory, add proper target configs should be enough.
Since the support of cortex A8 is almost finished.
The first issue comes up is how do I know the CPUTAPID for the new board?
I went through the document of openocd, but could
Try the attached patch.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From f37c9b8d1560d0081e53c71c55113a3c9858011a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Tue, 3 Nov 2009 12:28:00 +0100
Subject:
Pushed to master patch that inexplicably fixes the problem(improve
error handling and output for working area).
Hopefully once we track down the verify problem, we'll find the
real culprit
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flas
On Tuesday 03 November 2009, loody wrote:
> 1. what are the differences between bp hw and bp sw?
>I know some cpu, like mips, have break assembly instruction.
>Does that mean if we use bp hw, the openocd will insert the "break"
> assembly at the location we assign?
That would be "bp sw".
On Tue, Nov 3, 2009 at 10:35 AM, Pieter Conradie
wrote:
> Hi Øyvind,
>
> Genius! The patch works :)
That makes no sense to me. Please post the debug_level 3 log...
> 0.3.0-rc0 with patch was able to successfully program and verify a 512k image.
>
> It is also able to succesfully program a 16 Mby
Dear all:
I have some questions about Openocd:
1. what are the differences between bp hw and bp sw?
I know some cpu, like mips, have break assembly instruction.
Does that mean if we use bp hw, the openocd will insert the "break"
assembly at the location we assign?
2. why we need to set lengt
If enabling of global software reset is handled in reset-assert-pre
stage, target would get into Thumb state occasionally.
That's, the target is not indeed reset.
Fix this by moving PRM_RSTCTRL in the reset-start stage
like previous config.
Signed-off-by: Matt Hsu
---
tcl/target/omap3530.cfg |
40 matches
Mail list logo
