On May 3, 2014, at 7:42 AM, Paul Fertser <[email protected]> wrote:
>>>>
>>>> That DAP with other processors via the JTAG_AP port.
>>>
>>> What if OpenOCD would expose JTAG_AP ports via a regular socket with a
>>> JTAG-level protocol
>>
>> It should provide a standalone tap-struct - just like all of the
>> other taps, no different. Probably will need to introduce a
>> “jtag-ops” function pointer to the tap-struct, much like the dap has
>> a dap_ops structure.
>
> I'm not sure we understand each other well here. Let me try to clear
> the confusion.
>
> If I understand it right, JTAG-AP is a special AP (accessible via DAP)
> which provides access to a "hidden JTAG chain", and that hidden chain
> is no different from a real JTAG chain as in every device on the said
> chain has a JTAG state machine, IR and DR etc.
>
Look at the OMAP parts - they have a DAP and a DSP, the cortex CPUs are on the
DAP, the DSPs are not “core-sight” meaning their debug features are jtag only.
Option 1:
Insert these into the JTAG chain … and deal with them powering on and off
and breaking the JTAG chain
The TI solution is the icepick - which modifies the chain.
Option 2:
Is the JTAG-AP port, there are upto 8 TMS signals, 8 TCK signals, 8 TDI,
and 8 TDO …
You could connect each of those OMAP dsps individually to the JTAG-AP port
Think of these as sub-port numbers on the DAP
In theory, the DAP can present 3 registers:
The JTAG selection register (which of those 8 sub-ports are in use)
The IR register, when written cycles the downstream tap through
SHIFT-IR and LATCH-IR
The DR register, when written - cycles through SHIFT-DR and LATCH DR … etc
This is pathologically hard…
Step 1: Your physical interface is JTAG
That tap has its own IR/DR register
Step 2: You rd/wr the jtag-mux register.
Thus, IR/DR register set(1) - transitions trough multiple
states.
Step 3: You rd/wr the second level IR/DR
The problem is - the 1st level IR/DR very different.
This is a big structural problem in OpenOCD - lots of globals :-(
Why do you do this? Because you don’t want or cannot use the ICEPICK solution.
> So if OpenOCD gains support for this kind of AP, it'll need to basically
> handle two completely different JTAG chains at the same time.
Exactly correct.
> I think that implementing that would be unreasonably hard (due to lots of
> assumptions, global variables etc) and on the other hand running a separate
> openocd instance with special interface driver would be quite easy, hence my
> proposal.
Are you familiar with Rube Goldberg Designs … A very american cartoon.
(British may recognize: W. Heath Robinson)
http://www.rubegoldberg.com
A rather bizarrely complicated system that is overly complicated.
>
>>> It seems that would look like a sane layering matching real hardware;
>>
>> that is the intent - there is one dap, with cortex_A and cortex_M
>> and other CPUs attached via the AP
>>
>> the problem right now is this: cortex_A has private DAP struct, and
>> the cortex_M has a another private DAP struct, and if support for
>> JTAG-AP is added, it should not have another private DAP struct -
>> because there is only one DAP.
>
> Then my proposal is this:
>
> 1. When "target create <name> cortex_[ma]" is called with a
> "-chain-position <tapname>" (actually, "swd newdap" is cheating by
> creating exactly the same tap structure as "jtag newtap" does, so it
> would be applicable as well here; multidrop swd would be creating N
> tap structures just as many taps can be created with jtag now),
> cortex_* target code callocates a new reference-counted "dap"
> structure and stores a pointer to it;
>
> 2. When "target create <name> cortex_[ma]" is called with
> e.g. "-master-target <target-name>", cortex_* code receives a pointer
> to the "master" target, fetches the dap pointer from there and stores
> it inside its private struct.
Why not just keep this in the TAP structure… Because I may need to access
memory without referring to a target…
Example: I want the DAP to access system memory by way of the system memory
port.
Today - for JTAG, the DAP = TAP
For SWD - that uses the underling TAP structure …
If I had two SWDs - there would be TWO tap structures…
My proposal was this:
When the target code examines the “TAP” structure - looking for a DAP
If none is present - it will create a DAP structure and save a pointer.
If the DAP pointer is present, it will just use that one.
That is what Andreas was objecting to.
> So changes to the generic target code would be minimal here,
> compatibility with all the existing configs would be preserved, and
> for multi-core devices a new capability of sharing the DAP would be
> created. Or am I missing something?
All I am saying is the TAP structure should have an “optional” DAP associated
with it, if the TAP represents a DAP the pointer is non-NULL
We could - keep a chain of DAPs … which are *independent* of the TAPs
The Cortex(A/M) could point to the DAP structure , which in turn points to a
JTAG-TAP or SWD
The problem is, there is also the “TARGET” structure which is important.
Hence what I am saying is this:
Cortex_A/M -> TARGET STRUCT -> TAP(with non-NULL-DAP pointer)
ARM_9 -> TARGET STRUCTURE -> TAP - in the standard way (exists today)
Not possible:
ARM_9 -> TARGET STRUCTURE -> TAP -> to DAP_PTR + JTAG_AP sub-port number
-> JTAG transport
ARM_9 -> TARGET STRUCTURE -> TAP -> to DAP_PTR + JTAG_AP sub-port number
-> SWD transport
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:[email protected]
>
------------------------------------------------------------------------------
"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
