On Sun, 2009-12-06 at 20:34 -0800, David Brownell wrote:
> On Sunday 06 December 2009, Zach Welch wrote:
> > On Sun, 2009-12-06 at 18:05 -0800, David Brownell wrote:
> > > I thought I'd try "mem info" in GDB. Nothing. Why?
>
> The first thing I tried, by the way, was
>
> gdb_memory_map enable
>
> but that failed with extreme rudeness. :(
How so? :)
[snip]
> > > So I add that missing call, and now I see the various flash
> > > commands again, and "flash banks" gives output ... curious
> > > and not-helpful output, but output. (This command used to
> > > be post-processed by some TCL stuff.)
> >
> > The post-processing stuff is problematic, in so far as it's no longer
> > possible to wrap second-tier commands as it was in the past. Honestly,
> > total feature compatibility will be difficult to reinstate, but I am not
> > sure that anyone uses this feature at present.
>
> Which feature ... "flash banks"? I use it to see what's
> been set up. There's no other way to get *concise* data.
The "'flash banks' gets mapped to 'flash_banks'" feature.
> (I'd think this should not be problematic. If there's
> already an override TCL script registered, don't define
> a new one.)
This would be fine, except there is no longer a means to directly
override anything but top-level commands. All sub-commands are called
through the dispatching mechanism of the top-level placeholder handler.
To rectify this new deficiency, I was thinking about supporting a
"command hook" syntax such as: 'command hook -post flash banks {...}',
which allows the script to associate post-processing functions to the
results of any given command.
This would be fairly easy to implement, and it would allow us to avoid
using override scripts for built-in commands. It offers a clean
mechanism for pre/post-processing, and this could even be disabled in
certain contexts (e.g. 'command raw flash banks' to run the command
without any hook scripts). Users already know how to write script with
callbacks, so a mechanism for calling script before/after the built-in
command seems plausible.
However, this is not required in the current situation. I have pushed a
patch that renames the existing 'flash banks' as 'flash list', replacing
replaces the TCL flash_banks wrapper with equivalent built-in C code.
As far as users will be concerned, nothing should appear to have changed
in this command.... Script writers may have further beefs with me.
> Though I'd actually prefer to see a subset of what the
> "flash info" command shows, for each bank: skip all the
> per-block status (most of which is "don't know" until you
> check a few things, and the rest of which is repetitive),
> but give more detailed info about each bank.
For now, I've just fixed the regression in apparent behavior. Feel free
to continue tweaking things from here.
--Z
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
