On Wednesday 03 June 2009, Duane Ellis wrote:
> (d) There should be *NO* concept of "active tap", nor "active target"
I think you mean "current" not "active". Agreed, nothing of
that level of significance should be implicit in a wire protocol.
At the user interface level, it may be a very diffe
Saying "AJAX" or talking about any other implementation tech feels
to me like putting the cart before the horse. I still don't know
what problems would expect be solved ... though I can think of three
right off the bat that *I* would expect to work:
* Eclipse integration. Probably covered for G
Let disabled targets be ignored during normal operation:
- In target_examine(), ignore disabled TAPs
- Reset handling must not poke at them either:
* fail $target_name arp_* operations on disabled TAPs
* in startup.tcl, don't even issue the arp_* wait ops
No other target cleanup incl
On Saturday 06 June 2009, Duane Ellis wrote:
> duane> $TARGETNAME mdw
Though "mdw" is really impractical for scripting. The "memread32"
thing would be better ... but notice that *it* ignores $TARGETNAME
too, for much the same reason other scripts can't use it.
> david> You'll notice most of t
On Sunday 07 June 2009 04:05:53 Duane Ellis wrote:
> I think you are *buried* in the details.
That is obviously true.. but you really helped to make things more clear.
> This is handled *automagically* by the FT2232H
> chip, you only need to enable it.
>
> The ftdi-2232-H monitors the RTCK signal
Patrick Wieland wrote:
> So the JTAG-debugger needs an input pin attached to RTCK. OpenOCD has to
> monitor the state of this pin an wait for a falling edge. When this has been
> detected, OpenOCD can generate the next clock tick, resp. rising edge on
> TCK..
> right? Is this that what the Amon
On Sunday 07 June 2009 01:51:21 Duane Ellis wrote:
> In the ARM diagram, Look at the TCK synchronizer and the RTCK signal to
> the TAP in the block diagram on the ARM site.
So the JTAG-debugger needs an input pin attached to RTCK. OpenOCD has to
monitor the state of this pin an wait for a falling
duane> $TARGETNAME mdw
david> You'll notice most of the reset-init event handlers can't use that.
CAN'T - or "just happen to not use that" - Big difference.
By design, they should be able to do exactly that, see:
src/target/target.c - lines 3559 ... 3731
By design, it should work, that
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
points out another concep
On Sunday 07 June 2009 01:51:21 Duane Ellis wrote:
> Patrick Wieland wrote:
> >> (I added some ultra high speed level shifters
>
> FYI - the XVERVE -signalyzer has this "built in", as does many of the
> SEGGER dongles, do check, you can screw up a target board easily enough.
>
> http://www.sig
On Saturday 06 June 2009, David Brownell wrote:
> if { [jtag tapisenabled [$t tapname]] == 0 } {
> continue
> }
Turns out I can already:
if {[jtag tapisenabled [$t cget -chain-position]] == 0} {
continue
}
so can make $SUBJECT work
Thank you Duane for your super fast reply!
My dongle is pin compatible to openocd by now (I just added high speed level
shifters to support targets from 1.2V to 3.3V with TCK speed greater than
30MHz). You said I'd have to set jtag clock speed to zero to enable adaptive
clocking, ok, but as I am
Patrick Wieland wrote:
>> (I added some ultra high speed level shifters
FYI - the XVERVE -signalyzer has this "built in", as does many of the
SEGGER dongles, do check, you can screw up a target board easily enough.
http://www.signalyzer.com/
Warning: the signalyzer *LITE* version - is 3.3
On Sunday 07 June 2009 01:07:29 Duane Ellis wrote:
> Patrick Wieland wrote:
> > I am working on a OpenOCD dongle based on the FT2232H. I want to support
>
> The "FT2232H" is already supported :-)
>
> See the configure option:
> --enable-ftd2xx-highspeed
> Enable building
On Saturday 06 June 2009, Duane Ellis wrote:
> FYI - The original idea was to support multi-core targets with different
> names, for example:
>
> mdw - works on the current target, what ever that is...
> $TARGETNAME mdw
You'll notice most of the reset-init event handlers can't use th
[ 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"
> >>
Splitting my response here in two parts ... this first one
seems more in the "after 0.2.0 ships" territory.
On Saturday 06 June 2009, Rick Altherr wrote:
> On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
> Sorry, I thought you were recommending naming things such as
> "omap3530" for both the
Patrick Wieland wrote:
> I am working on a OpenOCD dongle based on the FT2232H. I want to support
>
The "FT2232H" is already supported :-)
See the configure option:
--enable-ftd2xx-highspeed
Enable building support for FT2232H and
FT4232H-
This is my first posting to this mailing list, so I friendly say 'hello' to
everyone :-)
I am working on a OpenOCD dongle based on the FT2232H. I want to support
adaptive clocking, but I don't know how to accomplish this task. AFAIK there
are no FT2232 based designs with this feature available.
>>> [ targetname & tapnames are the same, and is confusing]
Yea, ugh, that is my fault, I did all that last year, I set the
example. What I did not consider well was the TAP names when I setup my
examples after creating the "tcl-target-as-an-object-command.
FYI - The original idea was to supp
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 encourage
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
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 s
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 direct
24 matches
Mail list logo
