On Fri, Jul 18, 2008 at 8:31 AM, Michael Schwingen
<[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>
>>> If there is a reset init script and a reset_init command, of course the
>>> init script should be run. If I do a reset, there are many possible
>>> scenarios where I want to keep as much proce
Øyvind Harboe wrote:
>> If there is a reset init script and a reset_init command, of course the
>> init script should be run. If I do a reset, there are many possible
>> scenarios where I want to keep as much processor state as possible, so
>> reset halt is a very reasonable bahiviour unless a dif
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
On Thu, Jul 17, 2008 at 10:41 PM, Charles Hardin <[EMAIL PROTECTED]> wrote:
> move the jim inits out of openocd.c
> move array2mem and mem2array to target.c
> remove openocd_tcl.h and add jim into command.h
>
> this should be near the final incarnation of jim in command.c as an extension
> to the e
On Fri, Jul 18, 2008 at 4:45 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> I have an observation about Jim, and the way OpenOCD is going.
I believe that the command set is pretty hard to grasp and that a revision
to make it more consistent would make sense. However, I'd like to do
that *after* the
On Fri, Jul 18, 2008 at 12:18 AM, Charles Hardin <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2008 at 5:07 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
>> On Wed, Jul 16, 2008 at 11:41 PM, Charles Hardin <[EMAIL PROTECTED]> wrote:
>>> Following patch added some incremental debugging for a devices t
On Thu, Jul 17, 2008 at 10:02 PM, Magnus Lundin <[EMAIL PROTECTED]> wrote:
>> On Thu, Jul 17, 2008 at 8:41 PM, Spen <[EMAIL PROTECTED]> wrote:
Any objections?
>>>
>>> Personally i would prefer to keep the existing behaviour.
>>
>> I guess you mean that you are speaking on behalf of w
Spen - you seem to be the guy who can fix any cortex problem I've had, I
do thank you.
Perhaps you can help explain this.
I have 2 boards - as I said earlier.
#1 has stm32f103vbt6 z 22 dav 93 mlt 22 746 - 128K flash part.
board stm32f10x-128k-eval
#2 has stm32f103zet6 22089vc mlt 3r816
Spen or Oyvind, Please add/commit - another jtag controller
configuration as follows:
src/target/interface/olimex-jtag-tiny-a.cfg
# REFERENCE: http://www.olimex.com/dev/arm-usb-tiny.html
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"
ft2232_layout olimex-jtag
-Duane.
__
I have an observation about Jim, and the way OpenOCD is going.
Things like the target, the flash, etc I believe should have a "formal"
tcl type name, and should act like TCL things.
In some cases, some commands are like that now. Some are not :-(
I do not like commands_with_lots_of_under_lines_i
On Thu, Jul 17, 2008 at 5:07 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 11:41 PM, Charles Hardin <[EMAIL PROTECTED]> wrote:
>> Following patch added some incremental debugging for a devices that are
>> broken - ie print the number of the device in bypass that is having i
move the jim inits out of openocd.c
move array2mem and mem2array to target.c
remove openocd_tcl.h and add jim into command.h
this should be near the final incarnation of jim in command.c as an extension
to the existing command processing engine
Index: src/openocd_tcl.h
===
> On Thu, Jul 17, 2008 at 8:41 PM, Spen <[EMAIL PROTECTED]> wrote:
>>>
>>> Any objections?
>>>
>>
>> Personally i would prefer to keep the existing behaviour.
>
> I guess you mean that you are speaking on behalf of what users
> would want?
That is a VERY good argument !
> The problem is that the b
On Thu, Jul 17, 2008 at 8:41 PM, Spen <[EMAIL PROTECTED]> wrote:
>>
>> Any objections?
>>
>
> Personally i would prefer to keep the existing behaviour.
I guess you mean that you are speaking on behalf of what users
would want?
The problem is that the behaviour is *unexpected*.
If there is a rese
>
> Any objections?
>
Personally i would prefer to keep the existing behaviour.
I have targets where i use reset_halt and run_and_halt depending on when i
want the script to run from a hard reset.
the other reset modes are far from deprecated, they are probably used more
then reset_init.
Again
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
To preserve the SVN history of the integrate, this patch does not include the
following commands.
cd src
svn mv jim.c helper/jim.c
svn mv jim.h helper/jim.h
svn mv bin2char.c helper/bin2char.c
svn mv startup.tcl helper/startup.tcl
The following patch can then be applied - this is my interpretatio
Instead of stashing the context in a global variable, just use the "context"
associated with the interp structure being passed around
And fixed the message referring to mem2array in the array2mem function
Index: src/helper/command.c
Instead of stashing the context in a global variable, just use the "context"
associated with the interp structure being passed around
Index: src/helper/command.c
===
--- src/helper/command.c(revision 820)
+++ src/helper/comman
Any objections?
The attached patch enforces "reset init" as the behaviour for "reset"
(no args) always.
This helps reduce confusion.
A warning is logged if the deprecated syntax is used. The option
old reset_mode option is simply ignored.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7
On Wed, Jul 16, 2008 at 11:41 PM, Charles Hardin <[EMAIL PROTECTED]> wrote:
> Following patch added some incremental debugging for a devices that are
> broken - ie print the number of the device in bypass that is having issues
>
> Mainly patches the drscan back to the handle_drscan because of the f
Committed.
This is still work in progress... a few more thorny issues to resolve
and we should be through the woods.
Output from OpenOCD commands, like puts, is printed
immediately.
The output is now collected into a local variable
"openocd_output".
This allows script code access to the outpu
duane> Hmm, something does not work with the cortexm3 breakpoints.
spen> The problem is caused by the target_resume function, try svn head now
Much better.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://list
On Thu, Jul 17, 2008 at 1:24 AM, Charles Hardin <[EMAIL PROTECTED]> wrote:
> There isn't a real value to the cfg_cmd_ctx since everything should
> be run thru the initial context created at start.
>
> Just remove this - note this assumes the command_context_mode api is
> present instead of just doi
I've added code to handle multilevel commands on top of your
patch.
Committed.
This is a rather messy bit that we have to get in place and I expect some
regression, but it is important to get this out of the way to synchronize work.
I'll be following feedback closely and do more testing as soon
> Subject: [Openocd-development] cortex m3 - breakpoints
>
> Hmm, something does not work with the cortexm3 breakpoints.
>
The problem is caused by the target_resume function, try svn head now
Cheers
Spen
___
Openocd-development mailing list
Openocd-
On Thu, Jul 17, 2008 at 1:09 AM, Charles Hardin <[EMAIL PROTECTED]> wrote:
> Don't think bin2char needs to be installed as part of openocd
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
28 matches
Mail list logo
