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

[Rick Altherr]

Having the target and tap names be the same is _not_ preferable. It makes the relationship between those two layers very confusing. For example, when a target is created, it introduces a new command names for the target. The same does _not_ happen for a TAP. If you make the names the same, people get confused when the $(target name) command isn't available but the TAP has been created.

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


 -- Unsigned



On Jun 6, 2009, at 12:15 PM, David Brownell wrote:

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

On Thursday 04 June 2009, David Brownell wrote:

... although this touches on some other glitches in the
vicinity of tap enable/disable logic.  The "tapenable"
code paths don't seem to have an obvious way to fail and
report that the tap was not enabled.

Still true, but not directly related to the notion that
targets on disabled taps should "just work".

Glitch in the patch I sent, nyet sorted out:  "reset" makes
the server abort:


Aborted

I seem to have missed something.

lt-openocd: jtag_driver.c:243: interface_jtag_add_dr_scan: Assertion `field == out_fields + scan->num_fields' failed.

There are two problems I've turned up so far, through
the startup.tcl code:

- The $target_name arp_* methods should not try to talk
  to targets that are disabled.

- Conceptual problem:  all the startup.tcl loops go
        foreach t [target names] {
                ... doit ...
        }
   but the loop should be "for each *ENABLED* target.

Re that conceptual problem, my first thought was just
growing the loops:

                if { 0 == [jtag tapisenabled $t] } {
                        continue
                }

But for "target create MyTarget cortex_m3 -chain-position mychip.foo"
that loses, because there is no JTAG tap named MyTarget.  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.

I tend to think that (a) is preferable.

Comments?


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

smime.p7s
Description: S/MIME cryptographic signature

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