On Wed, May 7, 2014 at 5:10 PM, Duane Ellis <[email protected]> wrote:
> [quoting out of order ..]
>
> andreas>> I have thought about this a great deal over the past years and
> wandered quite far off from where OpenOCD is today. So my ideas are maybe
> not very realistic in the short term. But it hardly hurts to have a common
> vision before starting to take the baby steps towards it.
>
> So it sounds like you are to some degree removing your objection.
>
Regarding abusing the tap struct for non-JTAG data? Not at all. But we'll
probably need an intermediate solution, I just don't see clearly right now
what that should consist of.
> andreas>> Of course, this absolutely requires the current single
> jtag_interface instance to be dug up with its roots and burnt. I don't see
> how we could reasonably move forward otherwise.
>
> In effect, every TAP - should effectively have an “_ops” structure - much
> like the DAP structure has a SWD vrs JTAG ops structure.
>
I don't think that's required at the TAP level. Remember, the only
operations available on a TAP is scanning bits in/out of IR and DR and just
about the only state it has is whether it's in bypass/enabled. A TAP
doesn't implement those operations itself, that is provided by the JTAG
interface layer. A TAP is a very very thin object that basically just links
a target, or whatever controls it, to a part of a scan chain.
For baby steps, I propose we put DAP structure in the JTAG structure (it
> must live somewhere, and that is the physical point of commonality)
>
But it doesn't belong there. (And what do you mean with the JTAG structure?
struct jtag_interface?) Modelling relationships and hierarchies that do not
exist in the real world will just give headaches later on.
duane>> [about SWD multi drop mode, with multiple DAPs ]
> andreas>> Sure, just create more DAP objects and connect them to the SWD
> link, specifying their TARGETID.
> I think you mean DAPID - not TARGETID - in my terms: TARGET = CPU core I
> wish to debug, the TARGETID = is some handle by which I find that CPU core.
>
No I mean TARGETID as defined by ADIv5.2, which must be known to be able to
select a device on a multidrop SWD link.
> Bottom line: Are you ok with putting the DAP structure in the TAP
> structure as the first step?
>
No, I'm not even OK with the DAP *pointer* that's currently there.
> I don’t see another simple first step.
>
I'm not sure there is a *simple* step. Simple steps in the wrong direction
are what put us in this entangled mess in the first place.
> I do think that the TAP structure is perhaps - in hindsight poorly named.
> We could add another field called: TAPTYPE = { IS_JTAG_TAP,
> IS_DAP_TAP } and then one day, we rename the structure to be DAPTAP …
>
I don't see what you're getting at. DAPs are not related to TAPs in the
same way as JTAG is related to TAPs. It makes no sense to mix concepts like
this.
> Then - future: Create a TAP operations structure … full of pointers … it
> would default to JTAG tap modes, but could then be over-ridden later.
>
Overridden with what? The TAP operations are necessarily implemented by a
JTAG interface (via some convoluted wrappers to handle the complete scan
chain... and queuing, yuk!). A DAP object can never implement a TAP. (A
JTAG-AP, connected to a DAP, could however implement a scan chain
consisting of a number of TAPs. But the DAP itself can't.)
> More future items - dealing with multiple tap chains.
> Another problem with the TAP structure - it assumes a linked list of all
> taps and thus also implies that this list is the one and only list, and
> thus the number of IR bits before and after can thus be calculated.
> I do notice that other debuggers do not have the concept of a DAP CHAIN -
> they instead, do something simpler - Each TAP is independently specified
> by (A) the number of taps before and after, and (B) the number of IR bits
> before/after
> We could (future) add 4 vars to the TAP structure, ir_bits_before,
> ir_bits_after, dr_bits_before, dr_bits_after.
> Allow user to specify the exact values of these, and if they are not
> specified - they are calculated during initliazation based on their
> position in the JTAG_TAP linked list.
>
What would be the point? The existing code already adds the correct number
of leading and trailing clocks depending on the TAP's position in the chain.
I think you're after the problem caused by the lack of a scan_chain object
(provided by a JTAG interface), with a pointer to it from each TAP in the
chain.
> This looks like changes localized in the interface layer. - But that would
> be future work (addressed when the dap-jtag-ap is supported)
>
Supporting JTAG-AP is far down the road. I guess it's almost the ultimate
test of a successful restructuring of OpenOCD internals.
/Andreas
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
