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. :(
> > Well, "flash banks" doesn't show anything any more. Why?
> >
> > Nothing calls flash_bank_add() ... handle_flash_bank_command()
> > just leaks the structure it filled out.
>
> Whoops.... that must be a "minor" refactoring think-o. When I moved the
> functionality and added the new helper, I must have forgot to call it.
> Sorry. :(
It happens ... but this is the kind of thing that makes
me certain that we need more than just a couple of weeks
of testing in the RC phase. Too much has changed for me
to believe there aren't a bunch more problems lurking.
Notice for example what arm720 and arm920 are now doing
when you try to write a coprocessor register. They're
trying to write it using the *READ* instruction ...
> > 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.
(I'd think this should not be problematic. If there's
already an override TCL script registered, don't define
a new one.)
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.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
