> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe
> Sent: vrijdag 27 november 2009 7:59
> To: openocd-development@lists.berlios.de
> Subject: [Openocd-development] Radically improving
On Fri, Nov 27, 2009 at 8:40 AM, David Brownell wrote:
> On Thursday 26 November 2009, Ųyvind Harboe wrote:
>> How about enabling fast/DCC memory transfers by default?
>
> This was previously the default on many systems, so not
> having it be enabled is a performance regression ...
I don't unders
On Thursday 26 November 2009, Øyvind Harboe wrote:
> How about enabling fast/DCC memory transfers by default?
This was previously the default on many systems, so not
having it be enabled is a performance regression ...
> We could document a requirement that a correct target
> script would disabl
On Thursday 26 November 2009, Øyvind Harboe wrote:
> Does this change the syntax for scripts?
And what might have caused "nand list" output to repeat? As if
the command got called twice...
> nand list
#0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8,
blocksize: 131072, block
How about enabling fast/DCC memory transfers by default?
We could document a requirement that a correct target
script would disable fast/DCC memory transfers if necessary.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM1
What's this??? A pure virtual test target?
Does it work with the dummy interface and faux flash driver?
Would be neat :-)
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programme
Does this change the syntax for scripts?
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
David Brownell wrote:
> Use the new "reset-assert" event; else SRST; else fail.
> Tested on an OMAP3, using the event.
>
> NOTE: still doesn't handle "reset halt". For some reason
> neither VCR nor PRCR seemed effective; they held the value
> that was written, but VCR didn't trigger debug entry w
Splits bulk of the jtag_tap_configure into jtag_tap_configure_event,
removing three or four levels of indentation in the process.
The resulting code was stylistically improved in other ways, but it
should be functionally identical.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 165 +++
Moves the ID and IR-related option parsing to static helpers, removing
two levels of indent.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 164
1 files changed, 94 insertions(+), 70 deletions(-)
diff --git a/src/jtag/tcl.c b/src/jt
Use 'continue' to reduce identation levels and superfluous logic.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 53 ++---
1 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index 929c784..837196
Eliminate the monolithic tcl_target_func by registering each of its
commands using the new chained command registration mechanism.
Also chains the target's commands under the CPU command, though these
may not work properly without some further modification.
Signed-off-by: Zachary T Welch
---
sr
The 'target' command group was implemented using its own command
dispatching, which can be eliminated by using the new chained command
registration mechanism. This patch splits the jim_target() function
into individual handlers, which makes them to be visible to the help and
usage commands. These
Prevent everything from crashing when exercising various commands.
Signed-off-by: Zachary T Welch
---
src/target/testee.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/src/target/testee.c b/src/target/testee.c
index ca3d56e..f858232 100644
--- a
Hi all,
This series continues to work to simplify OpenOCD's command handling.
Herein, you'll find some rather crude and heavy-handed attempts to
cleave apart some monolithic top-level command handlers into individual
handlers that get registered using the new command chaining mechanism.
The code
Explodes the 'jtag' into separate command handlers, which are easier
to understand and extend. Makes the code much easier to understand,
though further simplifications are possible. This patch tries to
minimize the noise when viewed with 'git diff -w'.
Gives these commands improved built-in help
Moves the tertiary jim handlers and required static helpers to the top
of tcl.c, defining them in a new registration array that is chained in
both the top-level context and under the jtag command. The top-level
commands can be removed at some point in the future to reduce clutter.
Signed-off-by:
Use the new "reset-assert" event; else SRST; else fail.
Tested on an OMAP3, using the event.
NOTE: still doesn't handle "reset halt". For some reason
neither VCR nor PRCR seemed effective; they held the value
that was written, but VCR didn't trigger debug entry when
the reset vector fired (maybe
Replaces previous "reset-assert-pre" workaround.
---
tcl/target/omap3530.cfg |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -65,10 +65,10 @@ proc omap3_dbginit {target} {
jtag_rclk 1000
$_TARGETNAME configure -event "r
This defines a "reset-assert" event and a supporting utility
routine, and documents both how targets should implement it
and how config scripts should use it. Core-specific updates
are needed to make this work.
---
This is necessary for supporting reset on boards without SRST.
I'm sending around t
> > > > Error: type 'xscale' is missing write_phys_memory
> > > > Error: type 'xscale' is missing read_phys_memory
>
> In this case a minimal correct implementation of those two
> methods would be to return ERROR_FAIL. Obviously, something
> that does the relevant hard work would be better.
Comm
On Thursday 26 November 2009, Zach Welch wrote:
> For the future, commit messages should have a short subject line and at
> least one line of description.
Agreed with the usual exception: there are minor patches
where the subject line suffices, and there's no point in
trying to create a second s
On Thu, 2009-11-26 at 18:12 +0100, Uwe Hermann wrote:
> Hi,
>
> please pull from the "doc-fixes" branch from my OpenOCD repo:
>
> Clone URL:
>
> git clone git://gitorious.org/openocd/openocd.git
>
>
> The branch has a bunch of minor typos and documentation fixes.
Pulled, rebased against the
On Thursday 26 November 2009, Zach Welch wrote:
> On Thu, 2009-11-26 at 14:05 +0100, Øyvind Harboe wrote:
> > Hi Andrey,
> >
> > > Error: type 'xscale' is missing write_phys_memory
> > > Error: type 'xscale' is missing read_phys_memory
> >
> > Ignore these errors. They are only reminders to the d
Hi,
please pull from the "doc-fixes" branch from my OpenOCD repo:
Clone URL:
git clone git://gitorious.org/openocd/openocd.git
The branch has a bunch of minor typos and documentation fixes.
The "git format-patch" output is attached for easier review.
Thanks, Uwe.
--
http://www.hermann-uw
Pushed, with another minor-but-related help text fix. Thanks!
--Z
On Wed, 2009-11-25 at 08:36 -0500, Eric Wetzel wrote:
> Hello,
>
> 'flash erase_sector' and 'flash protect' have not been working for me
> recently. Passing them the correct number of arguments (3 and 4,
> respectively) returns t
On Thu, 2009-11-26 at 14:05 +0100, Øyvind Harboe wrote:
> Hi Andrey,
>
> > Error: type 'xscale' is missing write_phys_memory
> > Error: type 'xscale' is missing read_phys_memory
>
> Ignore these errors. They are only reminders to the developers
> to add this support to the xscale target.
I saw t
loody a écrit :
> Hi:
> thanks for your kind help ^^
> it works find right now.
> 2009/11/26 Dean Glazeski :
>> You appear to mixing the two FTDI libraries in that configure command. If
>> you want to use the FTD2XX libraries, you need to use --enable-ft2232_ftd2xx
>> instead of --enable-ft2232_li
Thank you for referring to this. It solved the problem.
Regarding the previous problem "couldn't open blob-im2" I also solved
it: I needed to run both 'openocd' and 'telnet localhost ' from the
same directory (my mistake).
Cheers,
Andrey
Øyvind Harboe wrote:
> Have you tried:
>
> https://l
Have you tried:
https://lists.berlios.de/pipermail/openocd-development/2009-November/012907.html
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_
Hi:
thanks for your kind help ^^
it works find right now.
2009/11/26 Dean Glazeski :
> You appear to mixing the two FTDI libraries in that configure command. If
> you want to use the FTD2XX libraries, you need to use --enable-ft2232_ftd2xx
> instead of --enable-ft2232_libftdi. If you want to use
Hi Øyvind,
Thanks for your previous message. Do you have any idea about the nature
of the following "runtime" error (I get it when I try to protect a
memory part for blob)?
> reset halt
JTAG tap: imote2.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
0x9265, ver: 0x7)
target state: halted
Hi Andrey,
> Error: type 'xscale' is missing write_phys_memory
> Error: type 'xscale' is missing read_phys_memory
Ignore these errors. They are only reminders to the developers
to add this support to the xscale target.
Try writing up a fresh bug report using these guidelines:
http://openocd.ber
David Brownell a écrit :
> On Wednesday 25 November 2009, Albert ARIBAUD wrote:
>>> http://packages.debian.org/squeeze/amd64/libftdi-dev/filelist
>>>
>>> Maybe they treat this /usr/include/ftdi thing as a bug and
>>> work around it ... :)
>> Hmm... Checking the versions, Debian is talking about 0.
Hi,
I am sorry if this the wrong place for this kind of help request.
I am using Openocd (latest version from git) to program my imote2 sensor
via an Amontec JTAG-tiny. To configure and build openocd I use the
following commands:
./configure --prefix=/usr/local/lib/ --enable-ft2232_libftdi CFL
On Wednesday 25 November 2009, Albert ARIBAUD wrote:
>
> > http://packages.debian.org/squeeze/amd64/libftdi-dev/filelist
> >
> > Maybe they treat this /usr/include/ftdi thing as a bug and
> > work around it ... :)
>
> Hmm... Checking the versions, Debian is talking about 0.16. I'm using
> the
Albert ARIBAUD a écrit :
> David Brownell a écrit :
>> On Wednesday 25 November 2009, Albert ARIBAUD wrote:
>>> Dean Glazeski a écrit :
This patch shouldn't be necessary. I have the libftdi version working
fine with current head. I think this might be an issue with mixing
librari
37 matches
Mail list logo
