hmm, on jetson (cortex a15) works halt/resume, but what doesn't work is mdw:
> mdw 0x70832000 1024
data abort at 0x70832000, dfsr = 0x00000206
> dap info
AP ID register 0x44770001
Type is MEM-AP AHB
MEM-AP BASE 0xffffffff
No ROM table present
> mdw 0x70832000 1024
data abort at 0x70832000, dfsr = 0x00000206
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0 tegra124.cpu0 cortex_a little tegra124.dap halted
1 tegra124.cpu1 cortex_a little tegra124.dap halted
2 tegra124.cpu2 cortex_a little tegra124.dap halted
3* tegra124.cpu3 cortex_a little tegra124.dap halted
> resume
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0 tegra124.cpu0 cortex_a little tegra124.dap running
1 tegra124.cpu1 cortex_a little tegra124.dap running
2 tegra124.cpu2 cortex_a little tegra124.dap running
3* tegra124.cpu3 cortex_a little tegra124.dap running
> shutdown
On Thu, 10 Dec 2015 20:15:34 +0100, Andreas Fritiofson wrote:
> On Thu, Dec 10, 2015 at 1:21 PM, Matthias Welwarsky <[email protected]>
> wrote:
>
>> On Thursday 10 December 2015 06:29:01 gerrit wrote:
>> > This is an automated email from Gerrit.
>> >
>> > Andreas Fritiofson ([email protected]) just uploaded a new
>> patch
>> > set to Gerrit, which you can find at http://openocd.zylin.com/3165
>>
>> I very much like where this is heading.
>
>
> Good to hear! Please if you can test run this series on some more advanced
> targets it would be nice. I have only access to Cortex-M and I've actually
> only yet tested with the SWD transport so I may very well have broken
> something in the JTAG layer.
>
> A remaining cleanup is to move dap.apsel to armv7a_common, remove the dap
> apsel command and add a cortex_a specific command to the same effect
> (cortex_a memaccess_ap, as you suggested).
>
> Perhaps it should just be a switch to select either debug_ap or memory_ap,
> instead of allowing a specific AP number. That, or removing autodetect of
> memory_ap and requiring the AP to be selected manually if you don't want to
> use the debug_ap. Either way it should be an easy change.
>
> After that I would really like to see the DAP/AP lifecycle be made
> independent of the target but I'm not quite sure how to integrate that on
> the Tcl level. Any ideas are welcome. Best plan as of now is to do the same
> as we do for JTAG TAPs, which is to maintain a global list of TAPs and
> match the Tcl TAP specifier by name in C. But I'd like the name to be a Tcl
> "object" as well, with it's own methods (e.g. mdw mww for the AP
> objects...) and I don't think the TAPs work that way (but targets do...).
>
>
>
>> Apart from the obvious conceptual
>> cleaning, it is going to make it easier to fix WAIT handling in the DAP
>> layer.
>>
>
> I didn't have that in mind at all actually, so I'm a bit surprised to hear
> that. What kind of model do you imagine for WAIT handling?
>
> /Andreas
> <div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On
> Thu, Dec 10, 2015 at 1:21 PM, Matthias Welwarsky <span dir="ltr"><<a
> href="mailto:[email protected]";
> target="_blank">[email protected]</a>></span> wrote:<br><blockquote
> class="gmail_quote" style="margin:0px 0px 0px
> 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On
> Thursday 10 December 2015 06:29:01 gerrit wrote:<br>
> > This is an automated email from Gerrit.<br>
> ><br>
> > Andreas Fritiofson (<a href="mailto:[email protected]";
> target="_blank">[email protected]</a>) just uploaded a new
> patch<br>
> > set to Gerrit, which you can find at <a
> href="http://openocd.zylin.com/3165"; rel="noreferrer"
> target="_blank">http://openocd.zylin.com/3165</a><br>
> <br>
> I very much like where this is heading.</blockquote><div><br></div><div>Good
> to hear! Please if you can test run this series on some more advanced targets
> it would be nice. I have only access to Cortex-M and I've actually only
> yet tested with the SWD transport so I may very well have broken something in
> the JTAG layer.</div><div><br></div><div>A remaining cleanup is to move
> dap.apsel to armv7a_common, remove the dap apsel command and add a cortex_a
> specific command to the same effect (cortex_a memaccess_ap, as you
> suggested).</div><div><br></div><div>Perhaps it should just be a switch to
> select either debug_ap or memory_ap, instead of allowing a specific AP
> number. That, or removing autodetect of memory_ap and requiring the AP to be
> selected manually if you don't want to use the debug_ap. Either way it
> should be an easy change.</div><div><br></div><div>After that I would really
> like to see the DAP/AP lifecycle be made independent of the target but
> I'm not quite sure how to integrate that on the Tcl level. Any ideas are
> welcome. Best plan as of now is to do the same as we do for JTAG TAPs, which
> is to maintain a global list of TAPs and match the Tcl TAP specifier by name
> in C. But I'd like the name to be a Tcl "object" as well, with
> it's own methods (e.g. mdw mww for the AP objects...) and I don't
> think the TAPs work that way (but targets do...).</div><div><br></div><div>
> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px
> 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Apart
> from the obvious conceptual<br>
> cleaning, it is going to make it easier to fix WAIT handling in the DAP
> layer.<br></blockquote><div><br></div><div>I didn't have that in mind at
> all actually, so I'm a bit surprised to hear that. What kind of model do
> you imagine for WAIT
> handling?</div><div><br></div><div>/Andreas</div></div></div></div>
> ------------------------------------------------------------------------------
> _______________________________________________
> OpenOCD-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
------------------------------------------------------------------------------
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
