Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps

[Rick Altherr]

On Jun 6, 2009, at 4:27 PM, David Brownell wrote:

[ 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

should force target and TAP names to be the same (so "-chain-
position"
becomes redundant), *or* (b) we need a "list enabled taps"
primitive.

points out another conceptual problem ... either (a) "target create"

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.  :)

It doesn't make the code any simpler and doesn't change the typical case for the end user either. It just limits the flexibility and forces a code change if we ever run into such a device. $TAPNAME == $TARGETNAME can definitely be the typical case, but we should support $TAPNAME != $TARGETNAME since the cost to do so is minimal.

                 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

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.

enabled. In the simple case, it can be implemented as just looking up

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.

Actually, many Cortex-A8 designs include power/clock gating for the processor core. Such devices may have the TAP enabled, but the target isn't enabled because the power/clock is turned off to it. I'm not sure that a "$target_name curstate" is the right idea either since as you pointed out, it would need to grow to handle these cases and we won't necessarily know what all of them are.

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.

I'm aware.  I was pointing out the parallel.

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.


there may be only one tap == a target.)

(Some TAPs are isomorphic to targets too, and in the simplest systems

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.

Right. I don't think our command structure today does a very good job

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?

Either that or add '$target_name isenabled' that has an implementation that does '[jtag tapisenabled [$target_name tapname]]'. The latter means we won't need to revisit this when we do the full '$target_name isenabled' handling.

And fixing "$target_name configure ..." so it disallows changing the
target position or endianness after target setup.

- Dave

Yup.  Definitely necessary for 0.2.0.

--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

"He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development