On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
On Saturday 06 June 2009, Rick Altherr wrote:Having the target and tap names be the same is _not_ preferable. It makes the relationship between those two layers very confusing.Hmm, having them be the same is the convention that's encouraged already, as well as being the one used in every target/*.cfg script I've looked at. And I just grepped ... all the current "target create" commands use $_TARGETNAME for both the target and TAP names. Notice how the "targets" command shows two names, normally the same. If it's confusing (and I wouldn't agree that it is), it's not a new type of confusion. And I would argue that having more than one namespace is itself very confusing... particularly since the current policy more or less hides one of the namespaces.
Sorry, I thought you were recommending naming things such as "omap3530" for both the target and TAP. As long as we stick to descriptive names such as "omap3530.cpu" for both, I'm OK with it. The confusion can partially be resolved by changing the layout of the commands. Right now, the TAP-related commands are spread out (some are under JTAG, some are top-level (irscan, drscan), etc). The target commands are less so, but still are to an extent (targets are created with 'target create', but every other operation is done on the target name rather than 'target <target_name>'). If we straightened out the commands such that it is obvious which namespace we are working in, then the confusion of overlapping namespaces would be reduced considerably. I'd still prefer to keep the -chain-pos portion of the target command since I'd not a fan of automagic operations. We could make it optional and have the default be the target name, but I'd like to keep the option of being explicit and to allow for non-standard naming.
If you make the names the same, people get confused when the $(target name) command isn't available but the TAP has been created.People are always free to be foolish. If "targets" doesn't list the name, there is no target. TAP != target except on very simple systems.
As long as the command structure and documentation make this obvious, it's fine. As it stands today, it's not obvious that the reason 'halt' failed it because it is trying to use the current target name as a command, but that target doesn't exist. This gets worse if you have more than one target.
Although ... this reminds me how the "scan_chain" command is buried so deeply in the user's guide. I'll send a patch to present it when scan chains are presented ... which will help better distinguish the "list of TAPs" and "list of targets" concepts, by properly presenting both of them. (Though it'd be nice to have tap-list primitives like we have target-list primitives...)
There is a definite learning curve when dealing with OpenOCD. We don't do a good job of hiding the details of JTAG from the user. Fixing that is a long-term project, but we can at least make it better in the short term by describing the JTAG layer early on and partitioning commands into logical layers.
Which just points out another conceptual problem ... either (a) "target create"should force target and TAP names to be the same (so "-chain- position" becomes redundant), *or* (b) we need a "list enabled taps" primitive.Minor nit: I should have written "mechanism" not primitive. And part of why I think that (a) is preferable is that it would let us avoid creating parallel "$target_name tapisenabled" predicates to match the already-working "jtag tapisenabled $tap_name" one.
Such a redundancy wouldn't be great, but relying on target_name == tap_name isn't good for long-term extensibility. Chip designers like to lots of strange things. Imagine a single TAP that has the debug registers for two separate target types. You can't have 2 targets with the same name even though they use the same TAP. Of course, the 'target $target_name isenabled' isn't always a direct translation to checking if the TAP is enabled. There could easily be some other set of items within the target's registers that determine if it is enabled. In the simple case, it can be implemented as just looking up the tap name and asking the JTAG layer if the tap is enabled. A more complex case would likely always check if the TAP is enabled and then perform other checks. I can see value in a general "target is enabled" command.
Another is to avoid the nastiness inherent in the current capability of running "target configure -chain-position foo.bar" *after* the target has been set up. I can't ever see goodness coming from that...
Yup. We definitely should partition things into init-time settings and run-time settings. There are a number of things that really should only be set on target (or tap) creation. Imagine someone trying to change the width of the TAP IR at runtime.
That is, it would help keep the layer distinction: there's a TAP layer, and a target layer. TAP operations don't work on targets, and vice versa. (Some TAPs are isomorphic to targets too, and in the simplest systems there may be only one tap == a target.)
Right. I don't think our command structure today does a very good job of keeping them separate or distinguishing which layer a command is part of. If we group the TAP commands under the 'jtag' command and target commands under the 'target' command, it is _much_ clearer.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
