me rebasing/reworking 3124 to test it on snapdragon :) On Thu, 10 Dec 2015 20:15:34 +0100, Andreas Fritiofson wrote:
> On Thu, Dec 10, 2015 at 1:21 PM, Matthias Welwarsky <matth...@welwarsky.de> > wrote: > >> On Thursday 10 December 2015 06:29:01 gerrit wrote: >> > This is an automated email from Gerrit. >> > >> > Andreas Fritiofson (andreas.fritiof...@gmail.com) 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:matth...@welwarsky.de"; > target="_blank">matth...@welwarsky.de</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:andreas.fritiof...@gmail.com"; > target="_blank">andreas.fritiof...@gmail.com</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 > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
