On Thu, Feb 10, 2011 at 8:57 AM, luca ellero lro...@gmail.com wrote:
Sorry for the double posting. I made some mess :-(
Please discard 1st posting, 2nd is the right one.
Apologies for any inconvenience
This is the right one?
2011/2/10 Øyvind Harboe oyvind.har...@zylin.com
On Thu, Feb 10, 2011 at 8:57 AM, luca ellero lro...@gmail.com wrote:
Sorry for the double posting. I made some mess :-(
Please discard 1st posting, 2nd is the right one.
Apologies for any inconvenience
This is the right one?
On 09/02/2011 10.57, Øyvind Harboe wrote:
Hi Aaron,
On Wed, Feb 9, 2011 at 10:54 AM, Aaron Carrollaar...@cse.unsw.edu.au wrote:
Hi all,
I think the consensus on this issue is that AP handling could be
improved. Until someone has the motivation to fix it properly, can
this patch be applied?
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
I think perhaps there is a problem with commit messages these days
on sourceforge.
Anyone?
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.37 KiB, done.
Total 5 (delta 4), reused 0 (delta 0)
Hi Luca,
On 10 February 2011 06:19, Luca Ellero lro...@gmail.com wrote:
This patch adds read/write capability to memory addresses not
accessible through AHB-AP (for example boot ROM code).
To select between AHB and APB, a dap apsel command must be issued:
dap apsel 0 - following memory
On 10/02/2011 09:09, Øyvind Harboe wrote:
I think perhaps there is a problem with commit messages these days
on sourceforge.
Anyone?
I just did a small commit and received no email, so looks like something
has broken.
I was sent an email yesterday about changes:
Hello,
is there any way to determine the current and maximum queue size before a
jtag_execute_queue() has
to be executed ?
Regards,
Mathias
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Thu, Feb 10, 2011 at 8:05 PM, Mathias K. kes...@freenet.de wrote:
Hello,
is there any way to determine the current and maximum queue
size before a jtag_execute_queue() has to be executed ?
no and no. There is no maximum queue size and the api doesn't
and should expose the queue size.
Also
no and no. There is no maximum queue size and the api doesn't
and should expose the queue size.
'should not'
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale
Hello,
in app. note AN1839 (dsp563xx) its 3 ;-). In DSP56300FM and AN2074 they use the
correct number 5.
Regards,
Mathias
Am 10.02.2011 20:25, schrieb Phil Fong:
Hi,
I've been working on Rodrigo on adding support to flash Freescale dsp56800e
devices and have been looking at the
Changes:
- delay jtag queue excecution to decrease memory read/write times
- fix an early queue excecution in once interface
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 4371d0a..9bfb9a1 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -29,8 +29,6 @@
#include
Hi Luca,
On 11 February 2011 02:00, du...@dummy.com du...@dummy.com wrote:
On 10/02/2011 11.10, Aaron Carroll wrote:
On 10 February 2011 06:19, Luca Ellerolro...@gmail.com wrote:
This patch adds read/write capability to memory addresses not
accessible through AHB-AP (for example boot ROM
After some experimenting with building the right cable and generating an
appropriate SVF file, I was able to program a Lattice XP2 using OpenOCD and a
Signalyzer-H2. Since I also have a jlink, I figured why not give that a shot.
It seems that the jlink does not have the JTAG_STABLECLOCKS jtag
Changes:
- declare tap_set_state_impl, tap_get_state, tap_set_end_state,
tap_get_end_state as static inline,
this will decrease the calling overhead for this status getter and setter
functions
diff --git a/src/jtag/interface.c b/src/jtag/interface.c
index 1ed4512..8d5d514 100644
---
I don't have any objections to this particular patch, but if we
have to start doing tweaks at this level, then where does it
end?
Is there any profiling data that backs up this particular
optimization as particularly effective?
It is very surprising that this would make an impact,
but that's
17 matches
Mail list logo
