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
------------------------------------------------------------------------------
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
