[ second part of reply, focussed on before-0.2.0 ]
On Saturday 06 June 2009, Rick Altherr wrote:
> On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
>
> >>> 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.
I had imagined that, but realized that since we don't have any such
monstrosity today, we could defer that issue until later if we wanted
to go the simpler "require $TAPNAME == $TARGETNAME" route. :)
> 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.
Again, we don't have such cases today. We can speculate all kinds
of things, but in the absence of real hardware I don't think the
results of speculation are compelling. Plus, "$target_name curstate"
has a very limited range of state outputs, and it would need to grow
to accomodate such states.
The IEEE 1149.7 stuff seems to incorporate a "tap state" model of
sorts ... parts relevant to OpenOCD would be the power states, and
whether it's routed into the scan chain or not. I'd say those use
cases are relatively "near future". Not so with "target state".
> > 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.
Part of why that's not allowed. :)
It's the target stuff that's goofy that way, not TAP stuff.
> > 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.
So to get back to the real "it's *BROKEN* and 0.2.0 needs a fix"
issue ... sounds like you would be happier with
$target_name tapname
command to return the TAP, so the startup.tcl loops would look
something like
if { [jtag tapisenabled [$t tapname]] == 0 } {
continue
}
or something similar, instead of assuming the target is enabled.
Yes?
And fixing "$target_name configure ..." so it disallows changing the
target position or endianness after target setup.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
