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
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
