[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.
andreas>> so the Cortex-A and M targets *should not* contain a struct dap but
*should* contain a pointer to one (the same instance in case of a
multiprocessor chip).
Exactly the problem, we are in agreement.
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.
That’s a huge change - that will not happen over night.
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) and provide an
accessor function: target_to_dap(), transition all DAP based debug items to
that method as step 1.
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.
In effect, TAPID and DAPID sort of become equal - the sort of mean the exact
same thing, sort of a transport scheme.
====
Bottom line: Are you ok with putting the DAP structure in the TAP structure as
the first step?
I don’t see another simple first step.
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 …
Then - future: Create a TAP operations structure … full of pointers … it would
default to JTAG tap modes, but could then be over-ridden later.
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.
This looks like changes localized in the interface layer. - But that would be
future work (addressed when the dap-jtag-ap is supported)
-Duane.
On May 4, 2014, at 12:08 PM, Andreas Fritiofson <[email protected]>
wrote:
>
>
> On Sat, May 3, 2014 at 7:42 AM, Duane Ellis <[email protected]> wrote:
>
> On Apr 30, 2014, at 11:27 PM, Duane Ellis <[email protected]> wrote:
>
> > duane>> In the “TAP” structure - add a “DAP” pointer
> >
> > andreas> No, target->tap is JTAG specific. An SWD only setup should not
> > need to have a tap pointer.
> >
> > That’s a problem - Please thing about a solution.
> >
> > BTW - also need a solution for a JTAG tap that is accessed via the DAP ->
> > JTAG_AP interface..
> >
> > ie: Openodd -> interface -> SWD mode -> DAP -> JTAG_AP
> >
> > -Duane.
> >
> >
>
>
> Andreas
>
> Perhaps you are on vacation, or a holiday and having a good time :-) I have
> not seen a reply
>
> Indeed I was! :)
>
>
> Do you have a suggestion? Or can you please present an alliterative way to
> resolve this?
>
> As you realize, the only solution is to decouple the struct dap from the
> targets. A DAP is not a target feature (at least not with the current target
> == core definition) so the Cortex-A and M targets *should not* contain a
> struct dap but *should* contain a pointer to one (the same instance in case
> of a multiprocessor chip). The question is who creates that instance. From my
> point of view it's simple; the user does. A DAP should be a user managed
> object like the target. (In fact my vision is for *all* internal APIs in
> OpenOCD to be user managed (or manageable) objects.) On the lower levels, the
> DAP is layered over either JTAG, SWD or CMSIS-DAP. On the high side, the DAP
> provides connectivity to any number (up to the number of APs allowed) of
> targets (cores, or memory subsystems, if that concept existed in OpenOCD).
>
> I think we all understand the current problem - “multiple dap structures” -
> they should be only one.
>
> In summary, these are the issues:
>
> One DAP - with more then 1 CortexM3 present.
> That DAP with a Cortex_A type processor (several)
>
> Connect all "targets"/cores to the same DAP.
>
> That DAP with other processors via the JTAG_AP port.
>
> It should be possible to create a JTAG-AP on a DAP, which in turn is accessed
> over a JTAG-DP on a TAP on a JTAG interface. That JTAG-AP should provide a
> separate JTAG interface (or up to 8) through which the user can
> create/autodetect other TAPs, targets or whatever.
>
> 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.
>
>
> And - there can be more then 1 DAP if the target uses SWD2 (multi-drop SWD
> mode)
>
>
> Sure, just create more DAP objects and connect them to the SWD link,
> specifying their TARGETID.
>
> I don’t want to create a solution that will be rejected, it’s sort of a waste
> of time.
>
> No and that's why it's great that you've taken the initiative to get these
> discussions started. I'm sure you have a lot of valuable input and use-cases
> I never had in mind.
>
> 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.
>
> /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
