The global_cmd_ctx variable is never used in-tree, but rather serves the
eCos build. As such, it does not seem safe remove directly; however, it
represents an architectural blemish and needs to be removed.
Adds comments and ouputs warnings regarding this feature's deprecation.
Signed-off-by: Zac
Finish removing references to the 'interp' global variable from the
command module, encapsulating all reference via command_context.
Eliminates use of the global entirely, so it can be removed. Hurrah!
Signed-off-by: Zachary T Welch
---
src/helper/command.c | 38 -
Adds 'interp' field to command_context, chasing the few remaining
references to the global variable outside of the command module.
Signed-off-by: Zachary T Welch
---
src/helper/command.c|2 +-
src/helper/command.h|3 +--
src/jtag/core.c |2 +-
src/openocd.c
Adds 'interp' field to jtag_tap_event_action structure to avoid
using the global variable of same name.
Signed-off-by: Zachary T Welch
---
src/jtag/jtag.h | 11 ---
src/jtag/tcl.c |8 +---
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/jtag/jtag.h b/src/jt
Adds a log_capture_state structure to pass to the log capture
callback used by the command module. Ensures that the capture occurs
in the proper context.
Signed-off-by: Zachary T Welch
---
src/helper/command.c | 49 ++---
1 files changed, 34 inserti
Adds 'interp' to target_event_action structure to avoid using the
global variable of the same name.
Signed-off-by: Zachary T Welch
---
src/target/target.c | 19 ++-
src/target/target.h |1 +
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/target/target.c
Hi all,
This series removes the 'interp' global variable from the system,
bringing us a step closer to supporting several active command contexts.
Applies on top of the last to series. All three may be pulled from
my repo.or.cz mirror master branch.
Cheers,
Zach
__
Splits the old help strings to provide proper usage as well.
Signed-off-by: Zachary T Welch
---
src/hello.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/hello.c b/src/hello.c
index 2e5c928..cfd6e2f 100644
--- a/src/hello.c
+++ b/src/hello.c
@@ -58,19 +58,2
The 'help' text will become more verbose, so its entire text will be
far more than desired when you only borked your syntax. The usage
still allows the commands to be looked up for more help.
Signed-off-by: Zachary T Welch
---
src/helper/command.c |6 +++---
src/helper/startup.tcl |2
Somehow, the comment block for command handlers ended up associated
with the output_handler. Move it to the command_handler_t declaration.
Signed-off-by: Zachary T Welch
---
src/helper/command.h | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --
command_done() does not need to return an error, but it needed
Doxygen comment. Provide some for copy_command_context as well.
Note: this audit revealed some potential bugs with the command context
implementation. There was a reason that commands were added at the
end of the list. Shallow copyi
Hi all,
This series includes only minor changes. Applies on top of the last
series to allow deferred 'init'.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-deve
Adds 'noinit' command to prevent OpenOCD from running 'init' at the end
up startup, allowing it to be given from telnet or TCL. This provides
the old behavior by default, and users can add this command to their
scripts to get the new behavior.
Signed-off-by: Zachary T Welch
---
src/openocd.c |
Moves the telnet and TCL server startup to server_init(), moving their
respective command registration in to server_register_commands().
Adds proper error checking for these particular startup processes.
Moves the core server startup to openocd_main(), improving related error
checking and preparin
With the ability to defer 'init', users can access the help system while
still in CONFIG mode. This patch omits commands from the help and usage
list when they cannot be run in the current command mode, making it much
easier to see what can be done at a given time.
Signed-off-by: Zachary T Welch
Moves the telnet and TCL server startup to server_init(), moving their
respective command registration in to server_register_commands().
Adds proper error checking for these particular startup processes.
Adds 'noinit' command to prevent OpenOCD from running 'init' at the end
up startup, allowing i
Rework gdb_init to create flexible APIs (gdb_target_add_{one,all}) and
static helper (gdb_target_start) for starting GDB services. Eliminates
duplicated code and provides general mechanisms for adding GDB services.
The 'init' command is updated to call the new API, and later patches can
decouple i
Hi all,
These patches clean up the server and system startup. The first patch
factors the GDB server setup to be more conducive to deferred
initialization of targets (in a later series).
The second provides the 'noinit' command which can be used in a script
to removing 'init' from the end of the
On Sun, 2009-11-29 at 21:01 +0100, Øyvind Harboe wrote:
> > I disagree. You can't use flash without a target. We should never
> > offer that command without a target for it to be used with. The user
> > should not need to pull the two together on their own.
>
> Sure you can! I even believe tha
On Sunday 29 November 2009, Marek Vasut wrote:
>
> Ok, here's an updated patch
Merged both. Don't you need to update setting the BYPASS instruction
though? 0x7f isn't an 11-bit constant. :)
___
Openocd-development mailing list
Openocd-development@li
On Sunday 29 November 2009, Michael Schwingen wrote:
> David Brownell wrote:
> > With NAND it's easy to see why they won't use CPU addresses. :)
> >
> > In general, using { bank, sector } addressing gives finer control
> > over the actual chip resources, and is less error prone, even for
> > NOR f
On Sunday 29 November 2009, Øyvind Harboe wrote:
> > I disagree. You can't use flash without a target. We should never
> > offer that command without a target for it to be used with. The user
> > should not need to pull the two together on their own.
>
> Sure you can! I even believe that there
David Brownell wrote:
> With NAND it's easy to see why they won't use CPU addresses. :)
>
> In general, using { bank, sector } addressing gives finer control
> over the actual chip resources, and is less error prone, even for
> NOR flash. You kind of want to avoid accidentally erasing (or
> even
> I disagree. You can't use flash without a target. We should never
> offer that command without a target for it to be used with. The user
> should not need to pull the two together on their own.
Sure you can! I even believe that there is some support
for this in OpenOCD. The flash chip would
On Sun, 2009-11-29 at 18:47 +0100, Øyvind Harboe wrote:
> > Finally, would it be logical to create the dynamic flash banks commands
> > as subcommands of their relevant target?
> >
> >foo.cpu flash bank bank0 . # but no arg anymore
> >foo.cpu bank0 info # presently, it's 'fla
On Sat, 2009-11-28 at 18:16 -0800, David Brownell wrote:
> On Saturday 28 November 2009, Zach Welch wrote:
> >
> > Yeah, I figure there are some scripts (or users) that have not been
> > sufficiently strict about CONFIG vs. EXEC modes, as that logic has been
> > broken for ages
>
> Broken how
Øyvind Harboe a écrit :
>> Finally, would it be logical to create the dynamic flash banks commands
>> as subcommands of their relevant target?
>>
>>foo.cpu flash bank bank0 . # but no arg anymore
>>foo.cpu bank0 info # presently, it's 'flash info bank0'
>
> First of all: alt
On Sun, Nov 29, 2009 at 6:53 PM, David Brownell wrote:
> On Sunday 29 November 2009, Ųyvind Harboe wrote:
>> I have seen that some users feel very strongly about erasing
>> particular banks and sectors and writing to these sectors, rather
>> than using addresses. I have never fully understand why
On Sunday 29 November 2009, Øyvind Harboe wrote:
> I have seen that some users feel very strongly about erasing
> particular banks and sectors and writing to these sectors, rather
> than using addresses. I have never fully understand why they
> feel so strongly about going the way of banks instead
> Finally, would it be logical to create the dynamic flash banks commands
> as subcommands of their relevant target?
>
> foo.cpu flash bank bank0 . # but no arg anymore
> foo.cpu bank0 info # presently, it's 'flash info bank0'
First of all: although I'm not able to follow all
Dne Ne 29. listopadu 2009 06:10:57 David Brownell napsal(a):
> On Saturday 28 November 2009, Marek Vasut wrote:
> > > > +static int xscale_version = XSCALE_IXP4XX_PXA2XX;
> > >
> > > Please put this in the instance-specific struct ... this approach
> > > obviously breaks on a board with both a PXA2
Dne Ne 29. listopadu 2009 06:10:57 David Brownell napsal(a):
> On Saturday 28 November 2009, Marek Vasut wrote:
> > > > +static int xscale_version = XSCALE_IXP4XX_PXA2XX;
> > >
> > > Please put this in the instance-specific struct ... this approach
> > > obviously breaks on a board with both a PXA2
On Sunday 29 November 2009, Zach Welch wrote:
> Excellent. I came up with nearly the same patch before running out for
> the evening. The difference being that I put _after_ the last possible
> failure path, so it's possible to recover and try again.
It has to be before, because the initializati
Excellent. I came up with nearly the same patch before running out for
the evening. The difference being that I put _after_ the last possible
failure path, so it's possible to recover and try again.
On Sat, 2009-11-28 at 22:43 -0800, David Brownell wrote:
> On Saturday 28 November 2009, David Br
34 matches
Mail list logo
