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); by
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
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 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
---
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 @@
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
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
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
---
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 ;)
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 marc.pig...@hevs.ch
Date: Tue, 16 Feb 2010 10
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
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 any
On Tuesday 16 February 2010 12:11:42 Øyvind Harboe wrote:
On Tue, Feb 16, 2010 at 12:06 PM, Marc Pignat marc.pig...@hevs.ch 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 approval
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
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 me,
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
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 haven't read
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
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 (mine says ARM DDI 0151B
On Friday 12 February 2010 11:58:02 Øyvind Harboe wrote:
On Fri, Feb 12, 2010 at 9:29 AM, Marc Pignat marc.pig...@hevs.ch 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 address
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
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 to
On Thursday 11 February 2010 15:47:24 Øyvind Harboe wrote:
On Thu, Feb 11, 2010 at 3:37 PM, Marc Pignat marc.pig...@hevs.ch wrote:
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
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 virtphys
On Friday 12 February 2010 08:24:01 you wrote:
On Fri, Feb 12, 2010 at 8:23 AM, Marc Pignat marc.pig...@hevs.ch 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_virt2phys: not implemented
I tried
30 matches
Mail list logo
