On Tuesday 09 February 2010, Todd Krein wrote:
>What I don't understand is the relationship
> between the two. Are the internal scan chains all sitting off of one of
> the ARM's unused chains? Where in the code could I start looking to
> understand it?
Files target/{arm7_9_common,embeddedi
> 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
I have finished the code.
The biggest problem is the Flash Program Speed.
RM08001_JLinkUSBProtocol.pdf:
The USB latency is more of a problem. Since the host schedules USB transactions
in frames of 1ms for full speed and 125us for high speed connections, the
average latency is 2ms for full speed a
Gentle friends,
I'm trying to understand the relationship between the
scan chain in the ARM968E core and the rest of the system scan chains in
the NXP LPC29xx family.
I've found documentation, from ARM, on the scan
chain/TAP controller for the ARM9E core family
This allows minidrivers to e.g. hardware accelerate memory
writes.
Same trick as is used for arm7/9 dcc writes.
Added error propagation for memory transfer failures in
code rearrangement.
Also the JTAG end state is not updated until after
the memory write run is complete.
Signed-off-by: Øyvind
zy1000 performance for GDB load went from 100kBytes/s
to 300kBytes/s @ 8 MHz by implementing the inner loop
of unack arm11 memory writes directly on top of the hw
fifo.
Profiling info:
78.57 0.77 0.77
arm11_run_instr_data_to_core_noack_inner
5.10 0.82
On 09/02/2010 15:35, Edgar Grimberg wrote:
> There's the test run. At address 0x0800, according to flash info
> 0, there should be the flash. The RAM is at 0x2000. You can see
> that it fails to read the flash, but it manages to read the RAM just
> fine:
>
> $ sudo src/openocd -f
> /home/ed
Ouch it's actually target_write_buffer() that breaks these rules
target_write_buffer() aligns only the target address and does not
consider the host address...
As the jtag_add_xxscan() API is byte based, then we manage to
escape problems, but post 0.4 I think target_write_buffer() should
On Tuesday 09 February 2010, Øyvind Harboe wrote:
> The prototype below is problematic I would like to have
> seen buffer defined as "const void *" and added the requirement
> that "buffer" should be aligned to match "size"
>
> int target_write_memory(struct target *target,
>
There's the test run. At address 0x0800, according to flash info
0, there should be the flash. The RAM is at 0x2000. You can see
that it fails to read the flash, but it manages to read the RAM just
fine:
$ sudo src/openocd -f
/home/edgar/workspace/openocd/tcl/interface/parport.cfg -f
/home
This must have got messed up with cfg changes a while back.
Cheers
Spen
>From f899c2aa9767ba7bf731e6c6c1af2c437af97dac Mon Sep 17 00:00:00 2001
From: Spencer Oliver
Date: Tue, 9 Feb 2010 14:49:47 +
Subject: [PATCH] str730.cfg: fix incorrect mem regions
- update str73x mem regions to correc
The prototype below is problematic I would like to have
seen buffer defined as "const void *" and added the requirement
that "buffer" should be aligned to match "size"
int target_write_memory(struct target *target,
uint32_t address, uint32_t size, uint32_t count, uint8_t
*
Take #2
I've increased the performance for GDB load from 100 to 400kBytes/s @ 8MHz
by allowing the minidriver to implement the inner loop of memory writes
directly.
This is a straightforward, proven and very effective approach.
See latest two commits to:
http://repo.or.cz/w/openocd/oharboe.git/
16 matches
Mail list logo
