On Friday 12 June 2009, David Brownell wrote:
> On Monday 08 June 2009, Dirk Behme wrote:
> > - Tell exactly what is broken (from a technical point of view, maybe
> > on a level a not so experienced OpenOCD engineer could understand...
>
> Here's a start. Maybe other folk can add more. ...
Brief updates below. I can almost see the JRC stuff being fully
usable in the 0.2.0 release ... it seems like it's nearly there ...
> In no particular order, and with no expectation of completeness:
>
> - Can't handle IDCODE instruction for these DSPs, since the
> instruction length is 38 bits. Affects testing; I don't
> expect OpenOCD to ever support C55, C64x+, or C67+ DSPs!
> (I want to be able to look at *every* JRC port, to know
> that the code behaves in more than one single case.)
Still open. I don't expect this fixed in 0.2.0 code.
> - The current *model* of TAP enable/disable is a bit off.
>
> * There are two disable modes, but the code only has
> one right now. We should interpret the "-disable"
> option on TAP creation to reflect the state after
> exit from the JTAG Test_Logic_Reset state (doc fix
> for 0.2 IMO). The *desired runtime state* is a
> different beast, AFAICT.
Fixed in a patch I just sent.
> * Related, enabling TAPs is currently only done by
> a "jtag tapenable $TAP" command. It should be
> abstracted so it's done automatically in cases like
> initializing an ETM bound to a disabled ETB, and
> to re-enable after some code triggered TLR.
I expect that for 0.2.0 the workaround will be something
like adding a reset-deassert-post event handler embedding
that knowledge in openocd.cfg files.
> - The current TAP enable code is incomplete. It needs to
> kick the target(s) asociated with that TAP; examine()
> it and maybe more.
Fixed in a patch I just sent. For examine() only.
> - That TAP enable code is also excessively trusting. It
> should verify that the TAP actually appears! And that
> it's the expected device. The latter implies different
> kind of chain validation than we have now, since it may
> not enter TLR. (Presumably we can immediately verify
> the IR length with IRSCAN. Though it'd be good to sanity
> check that we didn't somehow enable *two* adjacent taps.
> If we know the IDCODE opcode we should then be able to
> verify the expected TAP id.)
>
> - Similarly with TAP disable. It should verify that the
> TAP disappeared. (We don't currently know how to make
> the ICEpick-C taps go away, but I'm fairly sure we could
> find out ... even without a logic analyser watching what
> happens on the JTAG bus!)
Both of those issues are still open. I suspect the enable
checks will be important.
> - I didn't see an obvious way to guarantee the expected
> 100+ TCK cycles after TLR. The cleanest way would be
> to define a new TAP event for TLR exit, and let the
> JRC provide a method that just does "runtest 100".
Open.
> - One of the header files says that interfaces may use
> arbitrary state transitions. I think that's got to
> be changed somewhat ... the new "pathmove" thing is
> not sufficient, given free running clocks. The hard
> and fast rule *here* must be: never enter RUN/IDLE
> implicitly.
Open. I wonder if I'm hitting a bug there?
> - Server can come up with the "current" target disabled.
> That shouldn't be possible.
Open.
> That's all for now. Comments from anyone who's looked
> at this before?
>
> - Dave
>
>
> # jrc == a JRC tap name
> # port == a port number, 0..15
> proc icepick_tapenable {jrc port} {
> irscan $jrc 7 -endstate IRPAUSE
> drscan $jrc 8 0x89 -endstate DRPAUSE
> irscan $jrc 2 -endstate IRPAUSE
> drscan $jrc 32 [expr 0xa0002108 + ($port << 24)] -endstate DRPAUSE
> irscan $jrc 0x3F -endstate RUN/IDLE
> runtest 10
> }
>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
