Hi all!
When I set a breakpoint in my application, the breakpoint works, but when
I continue, the program crashes (data abort) after resuming.
I'm using a custom board with an at91rm9200 (arm920t based) cpu, the software
is RTEMS based and uses icache and dcache.
Using openocd 0.3.1 and openocd
(forgotten to cc the list)
On Thursday 11 February 2010 09:56:17 you wrote:
> Please provide steps to reproduce. We may have an at91rm9200 around
> the office.
>
>
>
>
* I have compiled rtems4.9.0 + testsuite for csb337 (should run on
at91rm9200-dk too).
* /opt/rtems-4.9/bin/arm-rtems4.9-gdb
(once more, forgotten to cc the list)
Hi!
Ok I used git bisect for my first time and it seems that I have found something!
I haven't looked at the code yet, but the log seems very promising!
Here is what I've found:
f37c9b8d1560d0081e53c71c55113a3c9858011a is the first bad commit
commit f37c9b
On Thursday 11 February 2010 15:10:12 Øyvind Harboe wrote:
> Backing out that change, will break non-MMU execution. Baaad
>
> I tried to copy & paste the solution from 926ejs which also supports
> writing breakpoints to memory marked as read only by the MMU.
> Bonus!
>
> I don't have hardware
On Thursday 11 February 2010 15:47:24 Øyvind Harboe wrote:
> On Thu, Feb 11, 2010 at 3:37 PM, Marc Pignat wrote:
> > On Thursday 11 February 2010 15:10:12 Øyvind Harboe wrote:
> >> Backing out that change, will break non-MMU execution. Baaad
> >>
> >> I tri
On Thursday 11 February 2010 17:30:42 you wrote:
> >> If it works it fixes a bug as well as adds a new feature.
> >
> > Error: arm920_virt2phys: not implemented
> >
> >
> > I tried to copy virtphys from 926ejs, the debugged software still crashes.
>
> Could you provide a patch for a tested virtphy
On Friday 12 February 2010 08:24:01 you wrote:
> On Fri, Feb 12, 2010 at 8:23 AM, Marc Pignat wrote:
> > On Thursday 11 February 2010 17:30:42 you wrote:
> >> >> If it works it fixes a bug as well as adds a new feature.
> >> >
> >> > Error: arm920_v
On Friday 12 February 2010 08:59:08 David Brownell wrote:
> On Thursday 11 February 2010, Marc Pignat wrote:
> > What happens when we flush an address that is not in the data cache?
>
> We obviously *want* it to be a NOP... which is what section 2.3.11 of
> the ARM920T spec
On Friday 12 February 2010 11:58:02 Øyvind Harboe wrote:
> On Fri, Feb 12, 2010 at 9:29 AM, Marc Pignat wrote:
> > On Friday 12 February 2010 08:59:08 David Brownell wrote:
> >> On Thursday 11 February 2010, Marc Pignat wrote:
> >> > What happens when we flush an a
On Friday 12 February 2010 16:56:06 Øyvind Harboe wrote:
> > I can't make it work, but if I read well int
> > arm920t_write_cp15_interpreted, we should put
> > the address in value...
> >
> > I mean we use MCR p15,0,r0,... and we put the VMA in r1, so it will be
> > unused?
>
> I don't know and
Hi all!
Here is a fix for my problem, at least.
Problem : Clean and Invalidate DCache is not available in cp15 interpreted mode.
workaround : Use the Invalidate only.
The problem still remains for write back data cache, but at least it will work
for write through.
Marc
diff --git a/src/target/
Hi all!
Here is the complete story, just for the record, (or the git log).
The commit f37c9b8d1560d0081e53c71c55113a3c9858011a introduced a bug
in arm920t data cache handling. The command used (Clean and invalidate DCache)
can't be used in interpreted cp15 mode.
This patch fix the problem by Inv
On Tuesday 16 February 2010 11:45:36 Øyvind Harboe wrote:
> If we can solve that last little bit about also flushing the cache,
> then I think we
> should push the change for 0.4.
The write back mode is probably broken even without patch, so
I think this change should be pushed.
>
> Did you have
On Tuesday 16 February 2010 12:11:42 Øyvind Harboe wrote:
> On Tue, Feb 16, 2010 at 12:06 PM, Marc Pignat wrote:
> > On Tuesday 16 February 2010 11:45:36 Øyvind Harboe wrote:
...
> We're late in the 0.4 release cycle, so we'll have to have the release
> managers approva
> Here is a patch using 'MCR p15,0,Rd,c7,c10,2' (Invalidate data cache using
s/MCR p15,0,Rd,c7,c10,2/MCR p15,0,Rd,c7,c6,1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-developme
On Tuesday 16 February 2010 13:47:37 Øyvind Harboe wrote:
> I prefer the patch you posted earlier for 0.4.
>
> really I'd like some long term fix that handles the flushing problem, but
> 0.4 is right around the corner...
Sure, I am late with my patches for 0.4.0
This is not really a problem for
Hi all!
The arm920t support for data cache support where broken just before 0.3.1.
With a lot of help from Øyvind Harboe and David Brownell we finally have some
workaround patch for this (see threads about 'arm920t regression cache
support').
This workaround has still a bug with data cache in
same patch rebased as requested!
0001-step1.patch is Øyvind Harboe's patch rebased
0002-atm920t-cleanup-data-cache-handling.patch my patch for data cache support
From 06c2935ba15ae54d33612315ce3cbef3a2481c92 Mon Sep 17 00:00:00 2001
From: Marc Pignat
Date: Tue, 16 Feb 2010 10:08:18
Hi all!
On Wednesday 17 February 2010 00:10:43 David Brownell wrote:
> On Tuesday 16 February 2010, Øyvind Harboe wrote:
...
> But rather complicated, compared with using real flush
> ops (not via scanchain 15).
>
Sure, I will the "execute one instruction" method today!
Regards
Marc
__
Hi all!
I think there is a small typo in the doc.
Best regards
Marc
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 7d54247..49df159 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -332,7 +332,7 @@ and one can be used for a UART adapter at the same time the
other one is used to
Hi all!
There is a small mistake in the doc, arm920t is an arm9tdmi + mmu, so it is
armv4.
Best regards
Marc
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 49df159..21c63a8 100644
--- a/doc/openocd.texi
On Wednesday 05 May 2010 15:40:10 Øyvind Harboe wrote:
> It seems like you are intent on finding more such minor mistakes :-)
>
> Could you submit an accumulative patch of such changes once you feel
> that you are pretty much done for now?
>
>
>
No problem ;)
__
Always use the complete name of the GDB command, not an abbreviation.
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 21c63a8..f38c38f 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -537,7 +537,7 @@
There is a small typo in the cpu list, arm920t is armv4.
---
doc/openocd.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 49df159..21c63a8 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -3432,7 +3432,7 @@ At this wri
Let other boards do other things with srst and trst.
---
tcl/board/at91rm9200-dk.cfg |3 +++
tcl/target/at91rm9200.cfg |2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/tcl/board/at91rm9200-dk.cfg b/tcl/board/at91rm9200-dk.cfg
index 402ed05..f484fde 100644
--- a/tcl/
Hi all!
Here is some cleanup for the ft2232 code, please let me know what you think
about it.
Best Regards
Marc
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
* Include the size check into ft2232_write, so calling it is simpler.
* Use sizeof(buffer) when possible
---
src/jtag/drivers/ft2232.c | 85 +++--
1 files changed, 43 insertions(+), 42 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers
---
src/jtag/drivers/ft2232.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index bc8463e..9d40b1c 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -714,23 +714,24 @@ stati
On Friday 02 July 2010 12:15:06 Øyvind Harboe wrote:
> I'm going to leave it to you to follow up and make the decision on whether
> to revert here.
Hi all!
It seems that 2/2 has introduced problems.
It seemed trivial to me, but finally it isn't!
I think we should revert it.
Best regards
Marc
_
Hi!
> - Has anyone done this before/ or something similar?
About running openocd on a ARM host and driving jtag unsing its gpio pins,
this has been done using the at91rm9200, see src/jtag/drivers/at91rm9200.c
I have no idea about the pic32 support...
Best regards
Marc
Hi all!
This seems a good idea, and you can even improve the copy doing someting like
this (pseudo-code only):
void* buf_set_buf(const void *_src, unsigned src_start,
void *_dst, unsigned dst_start, unsigned len)
{
/* Are src and dst bit aligned? */
if ((dst_start
On Monday 07 February 2011 09:09:36 Øyvind Harboe wrote:
> What impact would it have to make this an
> inline fn?
>
...
>
Inlined or not, this function could be faster.
Even with inlining and constant propagation, I don't think gcc is smart enough
to replace "buf_set_buf(_src, 0, dst, 0, 64);" b
32 matches
Mail list logo
