Here is what happens when I enable burst writes:
> load_image ./images/test.bin 0x8000 bin
Data transfer failed. (84)
use 'arm11 memwrite burst disable' to disable fast burst mode
Runtime error, file "command.c", line 473:
> memwrite burst disable
Disabled memory write burst mode.
> mdw
Cleanup some of the downloaded ARM target algorithm code:
- Provide more complete disassembly of the DCC bulk write code
- Make code blocks "static const", in case GCC doesn't
- Fix some tabbing/layout issues
- Make some arm7_9_common.h flags be "bool" not "int"; and compact
the layout a
On Friday 11 September 2009, Øyvind Harboe wrote:
> There are *lots* of snippets around the code.
And they're mostly core-specific. Stuff like the
DCC support on ARMs, where ARMv4 and ARMv5 share
the same model (cp14 based), XScale morphed it by
taking away one bit, and newer ARM cores changed
th
Duane Ellis wrote:
> The idea is this:
> Let us assume there is a 4K block (working space) of ram some where.
> The code could be 2K, set aside 1K for stack (yes 1K)
> And 1K for a download buffer - could be bigger..
> Maybe we work with 4K and 4K...
>
>The entry point would
There are *lots* of snippets around the code.
I'd like to see what's running under MIPS exercised by
and large by the ARM target
Nothing has happened so far though. Nobody is doing
this manual translation, nor has anyone suggested a
solution that everybody has fallen for...
I don't know if t
Committed take #3 + your patch to the config file to allow
more in depth testing.
A patch to document the event in openocd.texi would
be greatly appreciated!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Øyvind Harboe wrote:
Take #3...
I committed a fix for a bug where running jtag configure twice would
cause an infinite loop upon event nofitication, but it still bothers me that
jtag configure was invoked twice...
Seems to work for me (configuration patch in attachment):
> openocd -s lib/open
On Friday 11 September 2009, Strontium wrote:
> I know that OpenOCD contains support code for PIC 32. But TinCanTools
> say the following:
>
> > Please note that since this JTAG adapter board is intended for use
> > with a MIPS CPU, OpenOCD cannot be used with this adapter board.
> > OpenOCD
>
> I know that OpenOCD contains support code for PIC 32. But
> TinCanTools
> say the following:
>
> > Please note that since this JTAG adapter board is intended for use
> > with a MIPS CPU, OpenOCD cannot be used with this adapter board.
> > OpenOCD does not support MIPS processors.
>
>
Hi all.
I know that OpenOCD contains support code for PIC 32. But TinCanTools
say the following:
> Please note that since this JTAG adapter board is intended for use
> with a MIPS CPU, OpenOCD cannot be used with this adapter board.
> OpenOCD does not support MIPS processors.
This is clear
On Fri, 11 Sep 2009, Spencer Oliver wrote:
>
> > The SheevaPlug interface is now unusable since rev 2573:
> >
> > Error: unable to open ftdi device: device not found
> > Runtime error, file "command.c", line 469:
> >
> > Backing out changes from that revision does indeed fix the issue.
> > So w
> The SheevaPlug interface is now unusable since rev 2573:
>
> Error: unable to open ftdi device: device not found
> Runtime error, file "command.c", line 469:
>
> Backing out changes from that revision does indeed fix the issue.
> So what was the point of that patch?
>
The original patch was
On Fri, 11 Sep 2009, Øyvind Harboe wrote:
> Added the missing line in target.c and committed.
Thanks.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Fri, 11 Sep 2009, Øyvind Harboe wrote:
> Why doesn't target.c doesn't add dragonite_target to the target_types array?
Oops. I did add the extern declaration, but forgot to add it back into
the array as well when I cleaned up that patch.
Nicolas
__
+++ Sergey Lapin [2009-09-08 22:50 +0400]:
> Hi, all!
>
> When working with PXA270 I see the following messages on reset.
>
> JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part:
> 0x9265, ver: 0x4)
> value captured during scan didn't pass the requested check:
> captured: 0x00 che
duane> When this idea would be bad: Little quick downloads
david> Depends how little...
duane> When this idea would be good: BULK transfers, flash programing, etc.
[snip]
david> However, another way of looking at it: you suggest
david> a limited and standardized kind of "debug moni
duane> [ describing a method to do cross target stuff with ]
duane> [ a 'quaint' little C program ]
oyvind> How would you handle the C code for a particular flash chip?
oyvind> Would that algorithm have to go into the single "giant" app
oyvind> that is downloaded?
The general idea is this:
W
On Thursday 10 September 2009, Øyvind Harboe wrote:
> W.r.t. run_algorithm, I was thinking about how much work
> it would be to write a *small* machine code translator
> that would translate generic code in to machine specific
> code... Sounds impossibly hard, but is it really? I haven't
> looked a
On Thursday 10 September 2009, Duane Ellis wrote:
> When this idea would be bad: Little quick downloads
Depends how little...
> When this idea would be good: BULK transfers, flash programing, etc.
>
> The idea is this:
> Let us assume there is a 4K block (working space) of ram some
Here is another approach:
http://www.ecoscentric.com/ecospro/doc.cgi/html/ecospro-ref/ecoflash.html
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists
Øyvind Harboe wrote on 2009-09-11 09:57:08:
> Breaking out new subject...
>
> > We also talked a while back about the idea of a standardized download
to the
> > target.
> >
> > The general idea i was taking about at the time is described below.
> >
> > -Duane.
> >
> >
> > A small say 2K, 10
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Added the missing line in target.c and committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mail
Breaking out new subject...
> We also talked a while back about the idea of a standardized download to the
> target.
>
> The general idea i was taking about at the time is described below.
>
> -Duane.
>
>
> A small say 2K, 100% position independent common block of arm code.
> perhaps - an "a
On Fri, Sep 11, 2009 at 8:22 AM, Øyvind Harboe wrote:
> On Fri, Sep 11, 2009 at 6:54 AM, michal smulski
> wrote:
>>
>> Attached:
>> 1. debug output for load_image without and with memburst write on
>> arm1136. See the slow load time on first and error on the other one.
>
> Try "help arm11" and t
25 matches
Mail list logo
