> > So you would say the "JTAG API" is dealing with -- I'm guessing
> > here -- just (a) state transitions/TMS (b) clocking during RUN,
> > and (c) data shifting during IRSCAN/DRSCAN? Plus maybe basic
> > policy for scan entry/exit, to ensure that free-running clocks
> > don't cause un-requested state transitions?
>
> Essentially yes. More specifically I'm thinking about the functions which
> sit directly on top of the minindrivers.
OK by me. At some point I may be doing some code at that level,
to do scan chain verification without entering TLR ... so that I
can get a handle on these JRC thingies. So far I've been doing a
top-down dive, not poking (much) at Real Code here.
Such a transport layer may also need to handle things like switching
to two-wire modes (someday)...
(One might then posit a "TAP" layer on top of that "JTAG" layer.
Whether a "JRC" would belong to that layer, or go on top of it,
is maybe worth thinking about. It *appears* so far that not only
will there be ICEpick-C -- unclear if older ICEpick-B and -A will
matter for current work -- but there will also be IEEE 1149.7,
and some folk talk about Cortex DAP as a flavor of JRC.)
> > That'd be OK. So long as there's a simple representation of
> > the bit arrays to be shifted in/out. Again, that's one thing
> > I like about the Linux framework: it basically takes a pointer
> > to an "unsigned long", and a bit count.
>
> I guess we *could* use unsigned long + bit count, but if unsigned long
> is 32 & 64 bit respectively, then I'm not familiar with how to write
> code using unsigned long for >32 bit arrays.
Notice how Linux does it; the BIT_{MASK,WORD}() macros are simple bit
ops (e.g. for 32 bits, MASK ands with 0x1f and WORD rightshifts 5).
static inline void set_bit(int nr, volatile unsigned long *addr)
{
unsigned long mask = BIT_MASK(nr);
unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
unsigned long flags;
_atomic_spin_lock_irqsave(p, flags);
*p |= mask;
_atomic_spin_unlock_irqrestore(p, flags);
}
Obviously the spinlocking isn't needed for OpenOCD. A bigger issue
is that OpenOCD needs bitfield endian-swapping ... "here's an N-bit
value in CPU byte-order, make it {big,little}-endian". And vice
versa ... those should be NOPs half the time.
> If you look at the invocation sites of the JTAG scan fn's, then >95%
> are <= 32 bits...
Which is nice in terms of optimizability. But that should be hidden
behind whatever calls are involved.
I'm missing something here. Are you discussing this to better
understand the issues, or do you actually have some attachment to
the notion of 32 bit values?
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
