> Let's save that for 0.5 instead ... Spen has a bunch of other
> performance tweaks too. These things are interface updates,
> and don't fit the RC-phase merge criteria I posted
>
> https://lists.berlios.de/pipermail/openocd-development/2009-December/013779.html
Agreed.
> I'm thinking we shou
On Tuesday 09 February 2010, Øyvind Harboe wrote:
> Though with the patch below I'm at the same speed as
> arm7/9. This patch should be clean and it's just refactoring
> the existing code into a fn basically so I'm kinda hoping that
> we have time yet to push it for 0.4:
>
> https://lists.berlios.
On Wed, Feb 10, 2010 at 7:00 AM, David Brownell wrote:
> On Monday 08 February 2010, Øyvind Harboe wrote:
>> On Mon, Feb 8, 2010 at 11:31 PM, David Brownell wrote:
>> > On Monday 08 February 2010, Ųyvind Harboe wrote:
>> >> The reason why jtag_add_runtest() is so much faster than
>> >> pathmove i
On Monday 08 February 2010, Øyvind Harboe wrote:
> On Mon, Feb 8, 2010 at 11:31 PM, David Brownell wrote:
> > On Monday 08 February 2010, Ųyvind Harboe wrote:
> >> The reason why jtag_add_runtest() is so much faster than
> >> pathmove is that jtag_add_runtest() can be queued in
> >> a hardware fif
On Mon, Feb 8, 2010 at 11:31 PM, David Brownell wrote:
> On Monday 08 February 2010, Ųyvind Harboe wrote:
>> The reason why jtag_add_runtest() is so much faster than
>> pathmove is that jtag_add_runtest() can be queued in
>> a hardware fifo.
>
> But does this guarantee the same path transition?
A
On Monday 08 February 2010, Øyvind Harboe wrote:
> The reason why jtag_add_runtest() is so much faster than
> pathmove is that jtag_add_runtest() can be queued in
> a hardware fifo.
But does this guarantee the same path transition?
The ARM11 debug TAP cares about specific paths when
the host is u
by using jtag_add_runtest() instead of pathmove, the
performance goes from 100kBytes/s for GDB load to
200kBytes/s @ 8MHz testing with imx31pdk.
The reason why jtag_add_runtest() is so much faster than
pathmove is that jtag_add_runtest() can be queued in
a hardware fifo.
gprof output:
62.59
