Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Zach Welch
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread David Brownell
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread David Brownell
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Michael Schwingen
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Øyvind Harboe
> 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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Zach Welch
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Albert ARIBAUD
Ø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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Øyvind Harboe
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread David Brownell
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

Re: [Openocd-development] [RFC] massive command restructuring!!!

2009-11-29 Thread Øyvind Harboe
> 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

[Openocd-development] [RFC] massive command restructuring!!!

2009-11-28 Thread Zach Welch
Hi all, I used exclamation points in $SUBJECT, because these suggestions will have drastic user-visible impact -- though the effects can be mitigated. All of the work done that I have done recently on the command handling system has established a foundation for migrating the script language to use