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 that there is some support > for this in OpenOCD. The flash chip would then be directly > connected to the JTAG chain.
You cannot define a NOR flash bank without defining a target first. IIRC, a target name is a required parameter for the 'flash bank' command. To be clear, I am not talking about NAND devices here, because - yes - those have different rules. > I don't understand the win for end-users to be required to specify, > target or flash chip when there is only one in the system. There's nothing stopping a user interface script from setting $CHIPNAME to avoid this problem. If our scripts are written consistently, this trick would generate the same base command names for all systems. Right? Indeed, we might decide to enable this as the default in a UI layer. It would result in a more regularized command set than we have today, even without any changes. However, this is a policy decision that should lie above the core mechanisms. Users should be able to override this decision without rebuilding OpenOCD; see below on how to do that. > On a technical level I see the problem of having e.g. cortex commands > passed to a mips target. That's exactly the kind of problem that I am trying to eliminate. With subcommands nested in the context which they can be used, each target or flash would provide only the commands that work for it. > > 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 think it is important to distinguish between user interface commands > and implementation commands. This discussion is showing the need for this distinction, yes. In these respects, Git provides a good example: lots of C programs are tied together in bash scripts for usability. Metaphorically, many of our commands are like those bash scripts, and we need more C programs. More concretely, our built-in commands should provide mechanisms that are used by TCL scripts to provide a user interface. > I view the flash write_image as high level utility command, not something that > the target offers. Sure. It seems we agree that anything like this could be done as a TCL wrapper around the type of low-level commands that I am proposing. > > >> 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. > > I'm positive this would be viewed as a regression in user experience. > > You have to know/keep in mind the name of the target. Especially > when switching between targets this can be annoying. Again, this can be avoided for the "90%-98% of the cases", but the code would be better off this way. > I don't think that the current "flash erase_address" syntax is something > 'bad' that we should support for backwards compatibility. I believe it is an > effective user interface to the underlying functionality. It's flawed in > several ways from a technical point of view, but that doesn't > make it less useful or effective. Okay, I am glad that you have admitted it's flawed technically. At this point, we seem to agree that there are problems that need to be fixed, and my plan should cover all of these bases. > >From your mail I saw that you're thinking along the lines of distinguishing > between a consistent and supportable representation in terms of > implementation and a tcl proc's that are the user interface. The user > interface will be less stringent and more "messy", but highly effective. Again, I think that we're agreeing overall. I want a low-level command language that solves the technical problems that we have identified, but you are concerned mosts users will probably want it to be wrapped up for them in a high-level TCL language. Any lingering issues will revolve in how to get from Here to There, but the grass should be greener for everyone if we can get There. Right? Anyway, the notion of this high-level UI begins to speak of a "startup" directory of TCL scripts to hold this code. Unlike the built-in scripts (which defines core commands used to build a high-level UIs), these scripts could be updated by users that want to work on more complicated systems than the high-level commands support. Heck, we could someday provide a set of default UIs. Beyond the "single system" profile (for 1-1 system to interface mapping, discussed above), there are also the gang-programming (1-N system to interface mapping), and multi-system debugging (N-1 system to interface mapping), and multi-head debugging (N-N system to interface mapping) profiles to consider as viable scenarios. Each of these requires a single scripting environment to control multiple interfaces or systems, and these are entirely within the scope of OpenOCD's domain. Personally, I expect OpenOCD to support all of these modes of operation, and I could discuss scenarios in my past where it would have been great to have a tool with such flexibility. Each profile would have been exercised during my career, were such a tool available at the time. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
