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 <target> arg anymore
> > foo.cpu bank0 info # presently, it's 'flash info bank0'
>
> First of all: although I'm not able to follow all the changes to the command
> stuff you are working on, I generally like the result and I'm happy to let
> you run with it.
>
> However, significant changes to the syntax is another matter. Here
> I need to pay proper attention :-)
I know this proposal presents an opportunity for controversy, so I
wanted to make sure it is ratified before writing a single line of code.
> I think it is important to distinguish between telnet and scripting as a
> user interface and tcl as a programming model.
When it comes to the fundamental command set, I think it is important to
treat all interfaces equally. If they differ at all, then these reflect
_policy_ decisions that should be made at a higher-level than the core
_mechanisms_ that I have targeted for overhaul.
The distinction should _not_ matter when designing the core language.
> In >90-98% of all cases there is only a single flash configured.
Funny, my very first configuration used two banks. :) I'm an outlier!
And...so what?
> In this case the current form in telnet & scripting with just
> using a "flash" command without referring to a particular
> flash chip makes sense.
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.
The _easiest_ way to provide this kind of access control and associative
context is to make it a subcommand of the target instance commands.
Indeed, that provides no extra coding to determine whether the command
should be allowed to run, and the user cannot forget the connection
between that flash and its target.
This is a win for our developers _and_ for our users.
> However, we here "flash erase_address" and "flash write_image" are
> interesting. These flash commands do not operate on any flash
> chips or banks, but rather figure out which flash chips in the current
> target that a command goes to.
You just said it: they operate on a target. Thus, it seems logical to
say that they are target commands; conversely, they should not be part
of the 'flash' command. They seem improperly categorized at present.
> I don't think that it is an improvement to the user experience to
> require a prefix to the flash command(current target or sole
> flash in system), even if the tcl programming model is crisper.
Ummm.. it's not requiring anything more than it already does. All of
the flash commands (except those you note above) require the flash bank
or its name as the first parameter. These changes would _replace_ the
'flash' verb with the bank name. As such, this step will remove the
bank parameter, in the same way a target's commands do not require one.
As an _extra_ step, we could put all of the NOR flash bank commands
under the target command. This emphasizes the point that those
resources cannot be accessed were it not for the target itself.
> 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 of addresses,
> but the fact of the matter is that they do.
No functionality will be lost or changed. Just the command names.
If I add support for 'script' subcommands, then you could write a small
wrapper for 'flash write_address'. The relevant startup.tcl code might
look something like this:
command proc flash write_address {args} {
eval [target current] write_address $args
}
add_usage_text flash write_address {....}
add_help_text flash write_address {....}
Obviously, this requires writing the 'command proc' handler that can
stuff the body into a new 'script_handler' field of a command structure.
That is not rocket science, but it'd take a little work to do right.
Presently, this would not useful without the '$t flash' command, but
this shows how we might provide scripted subcommands for compatibility.
> I also think it is a goal that OpenOCD should ship with high
> quality board configuration scripts, where a user would not
> really have any exposure to what a flash or cpu would be
> named. The user would here happily use the higher level
> fn's.
>
> Perhaps a solution would be to implement high level tcl proc's
> that present a user friendly way to manipulate flash and
> to have the c level tcl interface be more clean and address
> the technical concerns you raised?
As shown above, this could be a workable solution. Developers could be
free to create their own policy languages, if the command language had a
set of new policy-neutral mechanisms. Thus, you could provide the same
policies that exist today, using the same command names (AFAICT).
Furthermore, this would allow purging all policy decisions from the
low-level command set. Be careful: you're actually making me think
about taking this to a further extreme. ;)
Right now, a script author cannot separate some OpenOCD policies from
their mechanisms. The 'init' command is probably the pinnacle example
were these two facets of design have been mixed together. An improved
command structure should remove these limitations, once and for all.
Unfortunately, this entails tearing the command language apart to
decouple the policies from mechanisms, but I think it can be done in a
backward-compatible manner (as described previously). If anything, this
response has outlined additional mechanisms for providing backwards
compatibility where it may be desired.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
