On Sun, 2009-12-06 at 19:55 -0800, 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? > > > > 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. :(
Pushed the fix. > > 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. I recognized this > problem at some point, but there were bigger things on my radar. > > I have conceive of 'command' module upgrade that would be provide the > same functionality, but I would prefer to see if this is actually a > problem that needs to be solve in the general case. For now, I think it > might be best to recreate the flash banks wrapper functionality in the C > handler. Thoughts, before I dive into this? Too late. I pushed a patch (with a braindead wrong comment), so we can get the old output with 'flash_banks'. I suppose that a real solution is in order, but I cannot think of how to restore this without rather drastic measures. Comments? > > But now I can't "flash probe 0" ... why? > > Given the amount of change that's occurred in that module lately, it > would be nice to know when I broke it. I will try to figure it out from > casual inspection, but I probably need more details on this one. I tested it here. Naturally, it works fine for me with the above fixes in place. Until I hear more, I am not going to investigate this piece of the puzzle further. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
