Re: [Openocd-development] AT91SAM9 NAND Driver
On Fri, Nov 27, 2009 at 7:13 PM, David Brownell wrote:
> On Friday 27 November 2009, Dean Glazeski wrote:
> > On Fri, Nov 27, 2009 at 2:12 AM, David Brownell
> wrote:
> >
> > > On Monday 23 November 2009, Dean Glazeski wrote:
> > > > point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git
> .
> > > I've
> > >
> > > I merged a few of these. The page command refactoring:
> > >
> > > + if (oob && NAND_CMD_READ0 && nand->page_size <= 512) {
> > > + cmd = NAND_CMD_READOOB;
> > > + }
> > >
> > > looks buggy for "&& NAND_CMD_READ0 && " ... and I'd drop the
> > > needless brackets.
> >
> >
> > You make a good point and I did think of that when I originally wrote
> this.
>
> What -- that "&& constant ..." is a constant? I think you misread
> that ...
>
Oh, now I see. Nice catch. Don't I feel silly :). I don't have a NAND
with a page size that fits that comparison so I never saw it. I'll fix that
up.
// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 1/3] target: groundwork for "reset-assert" event
On Thursday 26 November 2009, David Brownell wrote: > 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 the three patches that make it work on > BeagleBoard ... and will merge along with similar stuff that > addresses at least one other board which need it. I merged that, but am holding back the other patches for a bit yet. It'd be nice if someone could verify the ARM11 stuff works on an iMX3x chip; and maybe I'll sort out what the issue is combining vector catch and SRST. If not, I'll merge that early next week. ARM9 ... in the works. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 srst behavior
On Friday 16 October 2009, Øyvind Harboe wrote:
> On Wed, Oct 14, 2009 at 7:03 PM, David Brownell wrote:
> > On Tuesday 13 October 2009, Øyvind Harboe wrote:
> >> > So I'd think the current code is behaving, modulo issues
> >> > you might have with iMX31 ...
> >>
> >> The currrent code target/arm11* code doesn't assert srst,
> >> it just issues a halt during assert.
> >
> > A quick skim of the docs suggests the right way to get a
> > halt after SRST involves setting halt mode, then setting
> > the reset bit in the vector catch hardware.
>
> Patch anyone? :-) I've got iMX31 hardware to test on. I tried
> this quickly, but it didn't work first try...
See the appended ... SRST is working just fine, despite the
comments in the current code. I think iMX31 must have a few
quirks in that space.
The vector catch is a bit dicey, but I've seen that fire too.
The only caveats for now: (a) use the "reset-assert" code
to reset, not SRST, and (b) lower the JTAG clock, since it
really does catch reset very early ... before kicking in the
PLLs that allow faster clocking!!
- Dave
== CUT HERE
Teach ARM11 how to use:
- the new "reset-assert" event
- vector catch to implement "reset halt"
- use SRST more like other cores do.
Tested on OMAP2420, where vector catch seems to work ok with the
reset-assert case, but not SRST ... not clear what's up with that.
> reset halt
...
Debug entry: VCR vector catch
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x01d3 pc: 0x
>
If using SRST, it just warns that it didn't halt soon enough.
---
src/target/arm11.c | 65 ---
1 file changed, 41 insertions(+), 24 deletions(-)
--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -819,27 +819,41 @@ static int arm11_step(struct target *tar
static int arm11_assert_reset(struct target *target)
{
- int retval;
struct arm11_common *arm11 = target_to_arm11(target);
- retval = arm11_check_init(arm11, NULL);
- if (retval != ERROR_OK)
- return retval;
+ /* FIXME when halt is requested, make it work somehow... */
- target->state = TARGET_UNKNOWN;
+ /* optionally catch reset vector */
+ if (target->reset_halt && !(arm11_vcr & 1))
+ arm11_sc7_set_vcr(arm11, arm11_vcr | 1);
- /* we would very much like to reset into the halted, state,
-* but resetting and halting is second best... */
- if (target->reset_halt)
- {
- CHECK_RETVAL(target_halt(target));
+ /* Issue some kind of warm reset. */
+ if (target_has_event_action(target, TARGET_EVENT_RESET_ASSERT)) {
+ target_handle_event(target, TARGET_EVENT_RESET_ASSERT);
+ } else if (jtag_get_reset_config() & RESET_HAS_SRST) {
+ /* REVISIT handle "pulls" cases, if there's
+* hardware that needs them to work.
+*/
+ jtag_add_reset(0, 1);
+ } else {
+ LOG_ERROR("%s: how to reset?", target_name(target));
+ return ERROR_FAIL;
}
+ /* registers are now invalid */
+ register_cache_invalidate(arm11->arm.core_cache);
+
+ target->state = TARGET_RESET;
+
+ return ERROR_OK;
+}
/* srst is funny. We can not do *anything* else while it's asserted
* and it has unkonwn side effects. Make sure no other code runs
* meanwhile.
*
+* (That's not true on OMAP2 chips; maybe an iMX3* series bug?)
+*
* Code below assumes srst:
*
* - Causes power-on-reset (but of what parts of the system?). Bug
@@ -860,26 +874,29 @@ static int arm11_assert_reset(struct tar
* state?
*/
- jtag_add_reset(0, 1);
- jtag_add_reset(0, 0);
+static int arm11_deassert_reset(struct target *target)
+{
+ struct arm11_common *arm11 = target_to_arm11(target);
+ int retval;
- /* How long do we have to wait? */
- jtag_add_sleep(5000);
+ /* be certain SRST is off */
+ jtag_add_reset(0, 0);
- /* un-mess up TAP state */
- jtag_add_tlr();
+ retval = arm11_poll(target);
- retval = jtag_execute_queue();
- if (retval != ERROR_OK)
- {
- return retval;
+ if (target->reset_halt) {
+ if (target->state != TARGET_HALTED) {
+ LOG_WARNING("%s: ran after reset and before halt ...",
+ target_name(target));
+ if ((retval = target_halt(target)) != ERROR_OK)
+ return retval;
+ }
}
- return ERROR_OK;
-}
+ /* restore vector catch config */
+ if (target->reset_halt && !(arm11_vcr & 1))
+ arm11_sc7_set_vcr(arm11, arm11_vcr);
-static int arm11_deassert_reset(struct target *target)
-{
Re: [Openocd-development] [RFC] proposal to fix another regression
On Fri, 2009-11-27 at 16:24 -0800, Zach Welch wrote: > Well, drat. The patch that I pushed had some unintended consequences. > Any Jim subcommand handlers' output now gets suppressed too, which > negatively affected my recently posted series to split apart the > top-level Jim handlers. The patches that I just posted appear to solve all of the problems with both the existing commands and with my additional patches. I will push all of these changes soon, unless I hear objections. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] improve command handler wrapper script
Adds 'ocd_bouncer' in startup.tcl that is called as a helper for
all command handlers, shrinking the embedded C wrapper to a mere stub.
Jim handlers are called directly, simple handlers get called with the
wrapper to capture and discard their output on error, and placeholders
call help directly (though the unknown handler still does this too).
It attempts to improve the quality of the error messages as well.
Signed-off-by: Zachary T Welch
---
src/helper/command.c |5 ++---
src/helper/startup.tcl | 24
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/helper/command.c b/src/helper/command.c
index b34847b..64db95d 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -314,9 +314,8 @@ static int register_command_handler(struct command *c)
}
/* we now need to add an overrideable proc */
- const char *override_name = alloc_printf("proc %s {args} {"
- "if {[catch {eval ocd_%s $args}] == 0} "
- "{return \"\"} else {return -code error}}",
+ const char *override_name = alloc_printf(
+ "proc %s {args} {eval ocd_bouncer %s $args}",
full_name, full_name);
if (NULL == override_name)
goto free_full_name;
diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl
index f11d5b6..cb5fb02 100644
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -10,6 +10,30 @@ proc exit {} {
ocd_throw exit
}
+# All commands are registered with an 'ocd_' prefix, while the "real"
+# command is a wrapper that calls this function. Its primary purpose is
+# to discard 'handler' command output,
+proc ocd_bouncer {name args} {
+ set cmd [format "ocd_%s" $name]
+ set type [eval command type $cmd $args]
+ if {$type == "native"} {
+ return [eval $cmd $args]
+ } else {if {$type == "simple"} {
+ if {[catch {eval $cmd $args}] == 0} {
+ return ""
+ } else {
+ set errmsg "Command handler execution failed"
+ }
+ } else {if {$type == "group"} {
+ catch {eval help $name $args}
+ set errmsg [format "%s: command requires more arguments" \
+ [concat $name " " $args]]
+ } else {
+ set errmsg [format "Unknown command type: %s" $type]
+ }}}
+ return -code error $errmsg
+}
+
# Try flipping / and \ to find file if the filename does not
# match the precise spelling
proc find {filename} {
--
1.6.4.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] add 'command type' introspective handler
Adds the 'command' group handler, with the 'type' command producing
a string that tells whether the given command is 'native' (for Jim-based
command handlers), 'simple' (for simple built-in commands), 'group'
for command group placeholders, and 'unknown' if not found in the
command registration tables (e.g. core built-ins functions).
Signed-off-by: Zachary T Welch
---
src/helper/command.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/src/helper/command.c b/src/helper/command.c
index 65421f5..b34847b 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -948,6 +948,31 @@ static int command_unknown(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
return script_command_run(interp, count, start, c, found);
}
+int jim_command_type(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
+{
+ if (1 == argc)
+ return JIM_ERR;
+
+ struct command_context *cmd_ctx = current_command_context();
+ struct command *c = cmd_ctx->commands;
+ int remaining = command_unknown_find(argc - 1, argv + 1, c, &c, true);
+ // if nothing could be consumed, then it's an unknown command
+ if (remaining == argc - 1)
+ {
+ Jim_SetResultString(interp, "unknown", -1);
+ return JIM_OK;
+ }
+
+ if (c->jim_handler)
+ Jim_SetResultString(interp, "native", -1);
+ else if (c->handler)
+ Jim_SetResultString(interp, "simple", -1);
+ else
+ Jim_SetResultString(interp, "group", -1);
+
+ return JIM_OK;
+}
+
int help_add_command(struct command_context *cmd_ctx, struct command *parent,
const char *cmd_name, const char *help_text, const char *usage)
{
@@ -1069,6 +1094,18 @@ COMMAND_HANDLER(handle_sleep_command)
return ERROR_OK;
}
+static const struct command_registration command_subcommand_handlers[] = {
+ {
+ .name = "type",
+ .mode = COMMAND_ANY,
+ .jim_handler = &jim_command_type,
+ .usage = " ...",
+ .help = "Returns the type of built-in command:"
+ "'native', 'simple', 'group', or 'unknown'",
+ },
+ COMMAND_REGISTRATION_DONE
+};
+
static const struct command_registration command_builtin_handlers[] = {
{
.name = "add_help_text",
@@ -1106,6 +1143,12 @@ static const struct command_registration
command_builtin_handlers[] = {
.help = "show basic command usage",
.usage = "[ ...]",
},
+ {
+ .name = "command",
+ .mode= COMMAND_ANY,
+ .help = "core command group (introspection)",
+ .chain = command_subcommand_handlers,
+ },
COMMAND_REGISTRATION_DONE
};
--
1.6.4.4
>From aafcd6e134f413bb610f26a342d9cbf13d923a14 Mon Sep 17 00:00:00 2001
From: Zachary T Welch
Date: Fri, 27 Nov 2009 19:14:30 -0800
Subject: [PATCH 2/2] improve command handler wrapper script
Adds 'ocd_bouncer' in startup.tcl that is called as a helper for
all command handlers, shrinking the embedded C wrapper to a mere stub.
Jim handlers are called directly, simple handlers get called with the
wrapper to capture and discard their output on error, and placeholders
call help directly (though the unknown handler still does this too).
It attempts to improve the quality of the error messages as well.
Signed-off-by: Zachary T Welch
---
src/helper/command.c |5 ++---
src/helper/startup.tcl | 24
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/helper/command.c b/src/helper/command.c
index b34847b..64db95d 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -314,9 +314,8 @@ static int register_command_handler(struct command *c)
}
/* we now need to add an overrideable proc */
- const char *override_name = alloc_printf("proc %s {args} {"
- "if {[catch {eval ocd_%s $args}] == 0} "
- "{return \"\"} else {return -code error}}",
+ const char *override_name = alloc_printf(
+ "proc %s {args} {eval ocd_bouncer %s $args}",
full_name, full_name);
if (NULL == override_name)
goto free_full_name;
diff --git a/src/helper/startup.tcl b/src/helper/startup.tcl
index f11d5b6..cb5fb02 100644
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -10,6 +10,30 @@ proc exit {} {
ocd_throw exit
}
+# All commands are registered with an 'ocd_' prefix, while the "real"
+# command is a wrapper that calls this function. Its primary purpose is
+# to discard 'handler' command output,
+proc ocd_bouncer {name args} {
+ set cmd [format "ocd_%s" $name]
+ set type [eval command type $cmd $args]
+ if {$type == "native"} {
+ return [eval $cmd $args]
+
Re: [Openocd-development] Radically improving out of the box performance for armX
On Sat, Nov 28, 2009 at 2:14 AM, David Brownell wrote: > On Thursday 26 November 2009, Øyvind Harboe wrote: >> 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 understand the above. OpenOCD has had DCC >> disabled by default forever, right? > > I seem to have been misreading c0d14dc7f19d785702eee5f69de5b1a63902554b ... The "fast" variable was just an attempt at trying to make OpenOCD have better performance out of the box. Never panned out. -- Ø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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Radically improving out of the box performance for armX
On Thursday 26 November 2009, Øyvind Harboe wrote: > 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 understand the above. OpenOCD has had DCC > disabled by default forever, right? I seem to have been misreading c0d14dc7f19d785702eee5f69de5b1a63902554b ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
On Friday 27 November 2009, Dean Glazeski wrote:
> On Fri, Nov 27, 2009 at 2:12 AM, David Brownell wrote:
>
> > On Monday 23 November 2009, Dean Glazeski wrote:
> > > point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git.
> > I've
> >
> > I merged a few of these. The page command refactoring:
> >
> > + if (oob && NAND_CMD_READ0 && nand->page_size <= 512) {
> > + cmd = NAND_CMD_READOOB;
> > + }
> >
> > looks buggy for "&& NAND_CMD_READ0 && " ... and I'd drop the
> > needless brackets.
>
>
> You make a good point and I did think of that when I originally wrote this.
What -- that "&& constant ..." is a constant? I think you misread
that ...
> To tell you the truth, I'm not entirely certain how to do this better. I
> suppose the logic could be pulled back to before the function call, but the
> logic is redundant as it would be placed before every read command function
> call. Would it be better to create a read version of the page command
> function that has this logic? I'm not sure.
I don't object to having a special case there which *works* ...
> > Later in that file nand_read_page_raw() reads
> >
> > + uint8_t command = NAND_CMD_READ0;
> > + int retval;
> > +
> > + retval = nand_page_command(nand, page, command, !data);
> >
> > where "command" as a variable looks needless.
> >
>
> Yeah, that's a remnant of me trying to do the above logic outside of the
> function. It is needless. I've been backed up recently with some VLSI
> layout, so we'll see if I can beat you to cleaning up some of the other
> non-applied patches :).
I'm not doing it so ... it'll have to be you. ;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC] proposal to fix another regression
Well, drat. The patch that I pushed had some unintended consequences.
Any Jim subcommand handlers' output now gets suppressed too, which
negatively affected my recently posted series to split apart the
top-level Jim handlers.
While I am impacted severely, most everything that worked before my
refactoring should work again with only a couple of minor exceptions
(e.g. 'flash banks'). At the moment, any Jim-based subcommands will
appear to be broken; this can be overcome by prefixing the first command
verb with 'ocd_' (e.g. 'flash banks' works fine as 'ocd_flash banks').
This is a feeble temporary workaround, until I can put a more lasting
solution into place; however, there are few such handlers at present.
My proposed solution would be to update the "catcher" script to check
whether the ocd_ variant needs to be wrapped, which depends on the last
command verb. I am thinking about implementing this by introducing a
new 'command type' built-in, which would return 'jim' or 'handler' for a
given command invocation.
All 'handler' commands would continue to use the 'catch' block to
capture and consume the output, while 'jim' commands would pass their
output unmolested. The use of the 'command' verb paves the way to
support other useful introspective actions, but those features would
come in a subsequent patch series.
Incidentally, I am allowing for the future extension of a 'script' type,
which would allow calling another Jim function as a subcommand. Thus,
users might add their own subcommands in any part of the command tree,
using only Jim commands to do so. This also suggests a Jim event for
registering context-specific Jim commands (e.g. 'foo.cpu mycommand') or
updating the event system to define handlers as 'script' subcommands.
Thoughts?
--Z
On Fri, 2009-11-27 at 14:52 -0800, Zach Welch wrote:
> I just pushed a slightly improved version of the patch, which improves
> the fallback logic. It also uses the same trick for the help fallback,
> which was broken in the original version below.
>
> --Z
>
> On Fri, 2009-11-27 at 14:08 -0800, Zachary T Welch wrote:
> > The command refactoring caused subcommand handlers to produce duplicate
> > output when run. The problem was introduced by failing to ensure all
> > such invocations went through a top-level "catcher" script, prefixing
> > the command name with the 'ocd_' prefix and consuming its results.
> >
> > The fix is to ensure such a top-level "catcher" script gets created
> > for each top-level command, regardless of whether it has a handler.
> > Indeed, this patch removes all command registrations for sub-commands,
> > which would not have worked in the new registration scheme anyway.
> >
> > For now, dispatch of subcommands continues to be handled by the new
> > 'unknown' command handler, which gets fixed here to strip the 'ocd_'
> > prefix if searching for the top-level command name fails initially.
> > Some Jim commands may be registered with this prefix, and that situation
> > seems to require the current fallback approach. Otherwise, that prefix
> > could be stripped unconditionally and the logic made a little simpler.
> >
> > Overall, the command dispatching remains more complicated than desired,
> > but this patch fixes the immediate regressions.
> >
> > Signed-off-by: Zachary T Welch
> > ---
> > src/helper/command.c | 45 +++--
> > 1 files changed, 31 insertions(+), 14 deletions(-)
> >
> > diff --git a/src/helper/command.c b/src/helper/command.c
> > index 62fb487..135cd3f 100644
> > --- a/src/helper/command.c
> > +++ b/src/helper/command.c
> > @@ -44,6 +44,9 @@
> > #include "jim-eventloop.h"
> >
> >
> > +/* nice short description of source file */
> > +#define __THIS__FILE__ "command.c"
> > +
> > Jim_Interp *interp = NULL;
> >
> > static int run_command(struct command_context *context,
> > @@ -185,8 +188,12 @@ static int script_command(Jim_Interp *interp, int
> > argc, Jim_Obj *const *argv)
> > return script_command_run(interp, argc, argv, c, true);
> > }
> >
> > -/* nice short description of source file */
> > -#define __THIS__FILE__ "command.c"
> > +static struct command *command_root(struct command *c)
> > +{
> > + while (NULL != c->parent)
> > + c = c->parent;
> > + return c;
> > +}
> >
> > /**
> > * Find a command by name from a list of commands.
> > @@ -296,19 +303,22 @@ static int register_command_handler(struct command *c)
> > if (NULL == full_name)
> > return retval;
> >
> > - const char *ocd_name = alloc_printf("ocd_%s", full_name);
> > - if (NULL == full_name)
> > - goto free_full_name;
> > + if (NULL != c->handler)
> > + {
> > + const char *ocd_name = alloc_printf("ocd_%s", full_name);
> > + if (NULL == full_name)
> > + goto free_full_name;
> >
> > - Jim_CreateCommand(interp, ocd_name, script_command, c, NULL);
> > - free((void *)ocd_name);
> > + Jim_C
Re: [Openocd-development] [PATCH] fix regression causing duplicated output
I just pushed a slightly improved version of the patch, which improves
the fallback logic. It also uses the same trick for the help fallback,
which was broken in the original version below.
--Z
On Fri, 2009-11-27 at 14:08 -0800, Zachary T Welch wrote:
> The command refactoring caused subcommand handlers to produce duplicate
> output when run. The problem was introduced by failing to ensure all
> such invocations went through a top-level "catcher" script, prefixing
> the command name with the 'ocd_' prefix and consuming its results.
>
> The fix is to ensure such a top-level "catcher" script gets created
> for each top-level command, regardless of whether it has a handler.
> Indeed, this patch removes all command registrations for sub-commands,
> which would not have worked in the new registration scheme anyway.
>
> For now, dispatch of subcommands continues to be handled by the new
> 'unknown' command handler, which gets fixed here to strip the 'ocd_'
> prefix if searching for the top-level command name fails initially.
> Some Jim commands may be registered with this prefix, and that situation
> seems to require the current fallback approach. Otherwise, that prefix
> could be stripped unconditionally and the logic made a little simpler.
>
> Overall, the command dispatching remains more complicated than desired,
> but this patch fixes the immediate regressions.
>
> Signed-off-by: Zachary T Welch
> ---
> src/helper/command.c | 45 +++--
> 1 files changed, 31 insertions(+), 14 deletions(-)
>
> diff --git a/src/helper/command.c b/src/helper/command.c
> index 62fb487..135cd3f 100644
> --- a/src/helper/command.c
> +++ b/src/helper/command.c
> @@ -44,6 +44,9 @@
> #include "jim-eventloop.h"
>
>
> +/* nice short description of source file */
> +#define __THIS__FILE__ "command.c"
> +
> Jim_Interp *interp = NULL;
>
> static int run_command(struct command_context *context,
> @@ -185,8 +188,12 @@ static int script_command(Jim_Interp *interp, int argc,
> Jim_Obj *const *argv)
> return script_command_run(interp, argc, argv, c, true);
> }
>
> -/* nice short description of source file */
> -#define __THIS__FILE__ "command.c"
> +static struct command *command_root(struct command *c)
> +{
> + while (NULL != c->parent)
> + c = c->parent;
> + return c;
> +}
>
> /**
> * Find a command by name from a list of commands.
> @@ -296,19 +303,22 @@ static int register_command_handler(struct command *c)
> if (NULL == full_name)
> return retval;
>
> - const char *ocd_name = alloc_printf("ocd_%s", full_name);
> - if (NULL == full_name)
> - goto free_full_name;
> + if (NULL != c->handler)
> + {
> + const char *ocd_name = alloc_printf("ocd_%s", full_name);
> + if (NULL == full_name)
> + goto free_full_name;
>
> - Jim_CreateCommand(interp, ocd_name, script_command, c, NULL);
> - free((void *)ocd_name);
> + Jim_CreateCommand(interp, ocd_name, script_command, c, NULL);
> + free((void *)ocd_name);
> + }
>
> /* we now need to add an overrideable proc */
> const char *override_name = alloc_printf("proc %s {args} {"
> "if {[catch {eval ocd_%s $args}] == 0} "
> "{return \"\"} else {return -code error}}",
> full_name, full_name);
> - if (NULL == full_name)
> + if (NULL == override_name)
> goto free_full_name;
>
> Jim_Eval_Named(interp, override_name, __THIS__FILE__, __LINE__);
> @@ -343,7 +353,7 @@ struct command* register_command(struct command_context
> *context,
>
> if (NULL != c->handler)
> {
> - int retval = register_command_handler(c);
> + int retval = register_command_handler(command_root(c));
> if (ERROR_OK != retval)
> {
> unregister_command(context, parent, name);
> @@ -875,15 +885,22 @@ COMMAND_HANDLER(handle_help_command)
> }
>
> static int command_unknown_find(unsigned argc, Jim_Obj *const *argv,
> - struct command *head, struct command **out)
> + struct command *head, struct command **out, bool top_level)
> {
> if (0 == argc)
> return argc;
> - struct command *c = command_find(head, Jim_GetString(argv[0], NULL));
> + const char *cmd_name = Jim_GetString(argv[0], NULL);
> + struct command *c = command_find(head, cmd_name);
> if (NULL == c)
> - return argc;
> + {
> + if (top_level && strncmp(cmd_name, "ocd_", 4) == 0)
> + c = command_find(head, cmd_name + 4);
> +
> + if (NULL == c)
> + return argc;
> + }
> *out = c;
> - return command_unknown_find(--argc, ++argv, (*out)->children, out);
> + return command_unknown_find(--argc, ++argv, (*out)->children, out,
Re: [Openocd-development] Radically improving out of the boxperformance for armX
Øyvind > How about enabling fast/DCC memory transfers by default? Yes, why not - now that we have (a) good TAP identification place. (b) good number of board configurations (c) Many things have a workbuffer in the cfg file.. Then, it is a no-brainer to enable that feature by default. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] fix regression causing duplicated output
The command refactoring caused subcommand handlers to produce duplicate
output when run. The problem was introduced by failing to ensure all
such invocations went through a top-level "catcher" script, prefixing
the command name with the 'ocd_' prefix and consuming its results.
The fix is to ensure such a top-level "catcher" script gets created
for each top-level command, regardless of whether it has a handler.
Indeed, this patch removes all command registrations for sub-commands,
which would not have worked in the new registration scheme anyway.
For now, dispatch of subcommands continues to be handled by the new
'unknown' command handler, which gets fixed here to strip the 'ocd_'
prefix if searching for the top-level command name fails initially.
Some Jim commands may be registered with this prefix, and that situation
seems to require the current fallback approach. Otherwise, that prefix
could be stripped unconditionally and the logic made a little simpler.
Overall, the command dispatching remains more complicated than desired,
but this patch fixes the immediate regressions.
Signed-off-by: Zachary T Welch
---
src/helper/command.c | 45 +++--
1 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/src/helper/command.c b/src/helper/command.c
index 62fb487..135cd3f 100644
--- a/src/helper/command.c
+++ b/src/helper/command.c
@@ -44,6 +44,9 @@
#include "jim-eventloop.h"
+/* nice short description of source file */
+#define __THIS__FILE__ "command.c"
+
Jim_Interp *interp = NULL;
static int run_command(struct command_context *context,
@@ -185,8 +188,12 @@ static int script_command(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
return script_command_run(interp, argc, argv, c, true);
}
-/* nice short description of source file */
-#define __THIS__FILE__ "command.c"
+static struct command *command_root(struct command *c)
+{
+ while (NULL != c->parent)
+ c = c->parent;
+ return c;
+}
/**
* Find a command by name from a list of commands.
@@ -296,19 +303,22 @@ static int register_command_handler(struct command *c)
if (NULL == full_name)
return retval;
- const char *ocd_name = alloc_printf("ocd_%s", full_name);
- if (NULL == full_name)
- goto free_full_name;
+ if (NULL != c->handler)
+ {
+ const char *ocd_name = alloc_printf("ocd_%s", full_name);
+ if (NULL == full_name)
+ goto free_full_name;
- Jim_CreateCommand(interp, ocd_name, script_command, c, NULL);
- free((void *)ocd_name);
+ Jim_CreateCommand(interp, ocd_name, script_command, c, NULL);
+ free((void *)ocd_name);
+ }
/* we now need to add an overrideable proc */
const char *override_name = alloc_printf("proc %s {args} {"
"if {[catch {eval ocd_%s $args}] == 0} "
"{return \"\"} else {return -code error}}",
full_name, full_name);
- if (NULL == full_name)
+ if (NULL == override_name)
goto free_full_name;
Jim_Eval_Named(interp, override_name, __THIS__FILE__, __LINE__);
@@ -343,7 +353,7 @@ struct command* register_command(struct command_context
*context,
if (NULL != c->handler)
{
- int retval = register_command_handler(c);
+ int retval = register_command_handler(command_root(c));
if (ERROR_OK != retval)
{
unregister_command(context, parent, name);
@@ -875,15 +885,22 @@ COMMAND_HANDLER(handle_help_command)
}
static int command_unknown_find(unsigned argc, Jim_Obj *const *argv,
- struct command *head, struct command **out)
+ struct command *head, struct command **out, bool top_level)
{
if (0 == argc)
return argc;
- struct command *c = command_find(head, Jim_GetString(argv[0], NULL));
+ const char *cmd_name = Jim_GetString(argv[0], NULL);
+ struct command *c = command_find(head, cmd_name);
if (NULL == c)
- return argc;
+ {
+ if (top_level && strncmp(cmd_name, "ocd_", 4) == 0)
+ c = command_find(head, cmd_name + 4);
+
+ if (NULL == c)
+ return argc;
+ }
*out = c;
- return command_unknown_find(--argc, ++argv, (*out)->children, out);
+ return command_unknown_find(--argc, ++argv, (*out)->children, out,
false);
}
static int command_unknown(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
@@ -893,7 +910,7 @@ static int command_unknown(Jim_Interp *interp, int argc,
Jim_Obj *const *argv)
struct command_context *cmd_ctx = current_command_context();
struct command *c = cmd_ctx->commands;
- int remaining = command_unknown_find(argc - 1, argv + 1, c, &c);
Re: [Openocd-development] [Patch 0/8] more command cleaning
On Fri, 2009-11-27 at 12:47 -0800, David Brownell wrote: > On Friday 27 November 2009, Zach Welch wrote: > > > And what might have caused "nand list" output to repeat? As if > > > the command got called twice... > > Saw the same with "arm reg". Do all commands repeat their output? All not-top-level commands, yes. I will post the fix shortly. > > > > nand list > > > #0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > > blocksize: 131072, blocks: 8192 > > > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > > blocksize: 131072, blocks: 8192 > > > #0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > > blocksize: 131072, blocks: 8192 > > > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > > blocksize: 131072, blocks: 8192 > > > > > > > exit > > > > > > > Great question. I'll look at this regression, though it looks like that > > command "wants" to return the same format as the 'flash banks' command > > (i.e. as a list that can be further manipulated in TCL). > > Didn't do so before... Yup. :) > > Would it be > > preferable to fix this issue by rewriting it in such terms? > > As part of a wholesale effort to make sure every command's output can > be manipulated in TCL, and to separately document the "native" format > and the TCL-reformatters? Sure. But not just for this commands; > let's just fix the regression. Yeah. That is a separate patch, for sure. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] pull request: Typos and documentation fixes
On Thu, Nov 26, 2009 at 11:46:03AM -0800, David Brownell wrote: > 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 sentence of description. Yep, agreed. One-line short log and multi-line detailed explanations are good to have, except for simple "Fix typo" cases like this, where just the short one-liner should suffice. It's still displayed nicely in gitk etc. What about attaching the diffs to the "pull request" emails? Do you want to have those attached, or is "please pull from xyz" enough? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch 0/8] more command cleaning
On Friday 27 November 2009, Zach Welch wrote: > > And what might have caused "nand list" output to repeat? As if > > the command got called twice... Saw the same with "arm reg". Do all commands repeat their output? > > > nand list > > #0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > blocksize: 131072, blocks: 8192 > > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > blocksize: 131072, blocks: 8192 > > #0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > blocksize: 131072, blocks: 8192 > > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > > blocksize: 131072, blocks: 8192 > > > > > exit > > > > Great question. I'll look at this regression, though it looks like that > command "wants" to return the same format as the 'flash banks' command > (i.e. as a list that can be further manipulated in TCL). Didn't do so before... > Would it be > preferable to fix this issue by rewriting it in such terms? As part of a wholesale effort to make sure every command's output can be manipulated in TCL, and to separately document the "native" format and the TCL-reformatters? Sure. But not just for this commands; let's just fix the regression. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix interface regression
On Fri, Nov 27, 2009 at 9:16 PM, Zach Welch wrote: > On Fri, 2009-11-27 at 20:48 +0100, Øyvind Harboe wrote: >> On Fri, Nov 27, 2009 at 8:00 PM, Zach Welch wrote: >> > On Fri, 2009-11-27 at 19:52 +0100, Øyvind Harboe wrote: >> >> Fixes regression in interface command registration. >> >> >> >> master branch currently fails to build with --enable-minidriver-dummy >> >> (and other interfaces). >> > >> > Do not apply. The register_commands callback was removed on purpose, as >> > it does not provide any value (except redundant code). The correct fix >> > requires converting the minidrivers to use the new command registration. >> >> I've updated the zy1000 code. There has been so many updates >> lately and the bit where you added support for jim commands passed >> me by. > > FWIW, the patch you committed is broken slightly. You must use > COMMAND_REGISTRATION_DONE at the end of your command registration array, > as that appends the NULL record that terminates the list. Presently, > you will get a crash when the ZY1000 interface commands are registered. Right... > You might also consider adding additional records that allow the ZY1000 > commands to the be restructured into a nested structure: > > zy1000 (command group placeholder) > zy1000 power [on|off|status] > zy1000 firmware (command group placeholder) > zy1000 firmware version > zy1000 firmware update > > You could almost do this simply by adding 2 chained registration arrays, > though this suggests rewriting the power and powerstatus commands to > work as a single handler (in both this and its existing context). Hmmm yeah... I'll look into that. -- Ø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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix interface regression
On Fri, 2009-11-27 at 20:48 +0100, Øyvind Harboe wrote: > On Fri, Nov 27, 2009 at 8:00 PM, Zach Welch wrote: > > On Fri, 2009-11-27 at 19:52 +0100, Øyvind Harboe wrote: > >> Fixes regression in interface command registration. > >> > >> master branch currently fails to build with --enable-minidriver-dummy > >> (and other interfaces). > > > > Do not apply. The register_commands callback was removed on purpose, as > > it does not provide any value (except redundant code). The correct fix > > requires converting the minidrivers to use the new command registration. > > I've updated the zy1000 code. There has been so many updates > lately and the bit where you added support for jim commands passed > me by. FWIW, the patch you committed is broken slightly. You must use COMMAND_REGISTRATION_DONE at the end of your command registration array, as that appends the NULL record that terminates the list. Presently, you will get a crash when the ZY1000 interface commands are registered. You might also consider adding additional records that allow the ZY1000 commands to the be restructured into a nested structure: zy1000 (command group placeholder) zy1000 power [on|off|status] zy1000 firmware (command group placeholder) zy1000 firmware version zy1000 firmware update You could almost do this simply by adding 2 chained registration arrays, though this suggests rewriting the power and powerstatus commands to work as a single handler (in both this and its existing context). --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix interface regression
On Fri, Nov 27, 2009 at 8:00 PM, Zach Welch wrote: > On Fri, 2009-11-27 at 19:52 +0100, Øyvind Harboe wrote: >> Fixes regression in interface command registration. >> >> master branch currently fails to build with --enable-minidriver-dummy >> (and other interfaces). > > Do not apply. The register_commands callback was removed on purpose, as > it does not provide any value (except redundant code). The correct fix > requires converting the minidrivers to use the new command registration. I've updated the zy1000 code. There has been so many updates lately and the bit where you added support for jim commands passed me by. I like the bit where you split out command syntax from help. -- Ø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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix interface regression
On Fri, 2009-11-27 at 11:00 -0800, Zach Welch wrote: > On Fri, 2009-11-27 at 19:52 +0100, Øyvind Harboe wrote: > > Fixes regression in interface command registration. > > > > master branch currently fails to build with --enable-minidriver-dummy > > (and other interfaces). > > Do not apply. The register_commands callback was removed on purpose, as > it does not provide any value (except redundant code). The correct fix > requires converting the minidrivers to use the new command registration. I just pushed the following fix for the dummy minidriver. --Z commit 6ce3a299f395ef7f778661ae3f79d63659d133f7 Author: Zachary T Welch Date: Fri Nov 27 11:02:54 2009 -0800 update minidummy interface driver command handling Changes the interface definition field reference from register_commands to commands, which allows the module to compile. diff --git a/src/jtag/minidummy/minidummy.c b/src/jtag/minidummy/minidummy.c index 1bee74e..986a8be 100644 --- a/src/jtag/minidummy/minidummy.c +++ b/src/jtag/minidummy/minidummy.c @@ -29,7 +29,7 @@ struct jtag_interface minidummy_interface = .name = "minidummy", .execute_queue = NULL, .speed = NULL, - .register_commands = NULL, + .commands = NULL, .init = NULL, .quit = NULL, .khz = NULL, ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix interface regression
On Fri, 2009-11-27 at 19:52 +0100, Øyvind Harboe wrote: > Fixes regression in interface command registration. > > master branch currently fails to build with --enable-minidriver-dummy > (and other interfaces). Do not apply. The register_commands callback was removed on purpose, as it does not provide any value (except redundant code). The correct fix requires converting the minidrivers to use the new command registration. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix interface regression
Fixes regression in interface command registration.
master branch currently fails to build with --enable-minidriver-dummy
(and other interfaces).
--
Ø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
From 6917bc8b9feab21fbbf98c897b13bf960c4f1bcf Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Fri, 27 Nov 2009 19:36:40 +0100
Subject: [PATCH] interface: interfaces can use a callback or a static array
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
A static array is convenient when it's just a list
of classic style OpenOCD commands, otherwise a callback
is much more flexible of course.
Signed-off-by: Øyvind Harboe
---
src/jtag/interface.h |8
src/jtag/tcl.c |7 +++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/jtag/interface.h b/src/jtag/interface.h
index d55782a..99ba74f 100644
--- a/src/jtag/interface.h
+++ b/src/jtag/interface.h
@@ -204,6 +204,14 @@ struct jtag_interface {
/**
* The interface driver may register additional commands to expose
* additional features not covered by the standard command set.
+ * @param cmd_ctx The context in which commands should be registered.
+ * @returns ERROR_OK on success, or an error code on failure.
+ */
+ int (*register_commands)(struct command_context* cmd_ctx);
+
+ /**
+ * The interface driver may register additional commands to expose
+ * additional features not covered by the standard command set.
*/
const struct command_registration *commands;
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index e755dd7..57b706c 100644
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -636,6 +636,13 @@ COMMAND_HANDLER(handle_interface_command)
if (strcmp(CMD_ARGV[0], jtag_interfaces[i]->name) != 0)
continue;
+ if (NULL != jtag_interfaces[i]->register_commands)
+ {
+ int retval = jtag_interfaces[i]->register_commands(CMD_CTX);
+ if (ERROR_OK != retval)
+return retval;
+ }
+
if (NULL != jtag_interfaces[i]->commands)
{
int retval = register_commands(CMD_CTX, NULL,
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch 0/8] more command cleaning
On Thu, 2009-11-26 at 23:37 -0800, David Brownell wrote: > 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, blocks: 8192 > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > blocksize: 131072, blocks: 8192 > #0: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > blocksize: 131072, blocks: 8192 > #1: NAND 1GiB 3,3V 8-bit (Micron) pagesize: 2048, buswidth: 8, > blocksize: 131072, blocks: 8192 > > > exit > Great question. I'll look at this regression, though it looks like that command "wants" to return the same format as the 'flash banks' command (i.e. as a list that can be further manipulated in TCL). Would it be preferable to fix this issue by rewriting it in such terms? Of course, the 'targets' command might also be fixed similarly (and linked into the improved heirarchy as 'target list'), though that command does not show this same duplicated output bug at present. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 5/8] add more stub handlers to testee target
On Fri, Nov 27, 2009 at 6:13 PM, Zach Welch wrote: > On Fri, 2009-11-27 at 07:56 +0100, Øyvind Harboe wrote: >> What's this??? A pure virtual test target? >> >> Does it work with the dummy interface and faux flash driver? >> >> Would be neat :-) > > That's the idea. It's a work in progress that went in during my initial > command registration restructuring, wherein it was birthed to receive > the 'hello' and 'foo' commands. I am using it and testing a purely > virtual configuration during my command restructuring. > > Finally, I just wrote a 'nonce' nand driver, to test the regression with > 'nand list' that David pointed out for me. Neat! For automatic regression testing this could be handy as well... Eventually... -- Ø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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 5/8] add more stub handlers to testee target
On Fri, 2009-11-27 at 07:56 +0100, Øyvind Harboe wrote: > What's this??? A pure virtual test target? > > Does it work with the dummy interface and faux flash driver? > > Would be neat :-) That's the idea. It's a work in progress that went in during my initial command registration restructuring, wherein it was birthed to receive the 'hello' and 'foo' commands. I am using it and testing a purely virtual configuration during my command restructuring. Finally, I just wrote a 'nonce' nand driver, to test the regression with 'nand list' that David pointed out for me. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch 0/8] more command cleaning
On Fri, 2009-11-27 at 07:55 +0100, Øyvind Harboe wrote: > Does this change the syntax for scripts? No, but it does extend it. All relevant top-level commands have been made available underneath the jtag and target-instance commands. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
On Fri, Nov 27, 2009 at 2:12 AM, David Brownell wrote:
> On Monday 23 November 2009, Dean Glazeski wrote:
> > point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git.
> I've
>
> I merged a few of these. The page command refactoring:
>
> + if (oob && NAND_CMD_READ0 && nand->page_size <= 512) {
> + cmd = NAND_CMD_READOOB;
> + }
>
> looks buggy for "&& NAND_CMD_READ0 && " ... and I'd drop the
> needless brackets.
You make a good point and I did think of that when I originally wrote this.
To tell you the truth, I'm not entirely certain how to do this better. I
suppose the logic could be pulled back to before the function call, but the
logic is redundant as it would be placed before every read command function
call. Would it be better to create a read version of the page command
function that has this logic? I'm not sure.
>
> Later in that file nand_read_page_raw() reads
>
> + uint8_t command = NAND_CMD_READ0;
> + int retval;
> +
> + retval = nand_page_command(nand, page, command, !data);
>
> where "command" as a variable looks needless.
>
Yeah, that's a remnant of me trying to do the above logic outside of the
function. It is needless. I've been backed up recently with some VLSI
layout, so we'll see if I can beat you to cleaning up some of the other
non-applied patches :).
// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AT91SAM9 NAND Driver
On Monday 23 November 2009, Dean Glazeski wrote:
> point. The new play area is http://repo.or.cz/w/openocd/dnglaze.git. I've
I merged a few of these. The page command refactoring:
+ if (oob && NAND_CMD_READ0 && nand->page_size <= 512) {
+ cmd = NAND_CMD_READOOB;
+ }
looks buggy for "&& NAND_CMD_READ0 && " ... and I'd drop the
needless brackets.
Later in that file nand_read_page_raw() reads
+ uint8_t command = NAND_CMD_READ0;
+ int retval;
+
+ retval = nand_page_command(nand, page, command, !data);
where "command" as a variable looks needless.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Radically improving out of the boxperformance for armX
On Fri, Nov 27, 2009 at 8:58 AM, Nico Coesel wrote: >> -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 out of the boxperformance >> for armX >> >> 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. > > How would that affect users that a new to OpenOCD? If > there is a possibility that they run into trouble then it would > be better to leave it off and print a message instead OR > implement a fall-back scenario that tries to use DCC first > and then fall back to the standard transfer method. Otherwise > you'll see the same question repeated over and over on > the OpenOCD mailing list: 'why isn't it working?'. Perhaps, but not necessarily. Note that memory transfers smaller than 128 bytes(?) are not done with DCC. This means that any reset init sequence that I've seen should be unaffected. It is before the CPU is running at full speed(during reset) that I see the biggest chance of DCC failing. Also DCC is only used when working memory is enabled. Presumably a new user would either take an existing script and tweak it(add working memory), here the it would fail after he tweaked it. I don't see a user starting *from scratch* and then not being able to disable parts until discovering that "working memory" makes it fail and then that working memory minus DCC does not make it fail. There was some talk about adding a simple checksum to the DCC algorithm that is read back and checked. It should be something *fast* though(a few instructions at most). Note that this may be superfluous as we detect an incorrect end address of a DCC transfer now, i.e. we catch the case where the open loop is too fast on the OpenOCD side. -- Ø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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
