> 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. 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. On a technical level I see the problem of having e.g. cortex commands passed to a mips target. > 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. I view the flash write_image as high level utility command, not something that the target offers. >> 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. 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. 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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
