Hello Simon :-) Things that I have proposed are already implemented and can be verified at my local fork at http://repo.or.cz/w/openocd/libswd.git :-)
I want to make rebase but I have filtered connection problems abroad and I will do that after my return next week :-) On Tue, Apr 17, 2012 at 8:49 AM, simonqian.openocd <[email protected]> wrote: >>Adapter is another layer, an interface. Target functions should not touch >> anything except target. The transport has its own routines: SELECT and INIT, >> they are part of the transport dap_ops, maybe you are regarding to them? :-) > > OK, it can be implemented when SELECT and INIT transport. It's a better > solution. I have created swd_* files in src/transport. Maybe I should rename them to swd_libswd and make it clear that swd transport is implemented with libswd, while your transport would be named swd_versaloon or something else as you use totaly different functions to init and control your device..? :-) There was a clarification required what is the exact function of the SELECT and INIT, I made it this way as presented in the for sources (http://repo.or.cz/w/openocd/libswd.git/blob/2780cba2c744258838af250c56312ac29a61da05:/src/transport/swd_core.c): 1. INIT prepares selected transport for later use and bus/target initialization (it allocates internal transport memory, do the internal transport setup AND verifies the connection by calling libswd_dap_detect() so there is a connection to a target made). 3. SELECT selects SWD transport on interface pointed by global *jtag_interface structure and selects/registers the SWD command set. Select is assumed to be called before transport init. It prepares everything, including context memory and command set for higher layers, but not hardware and does not interrogate target device (with IDCODE read that is done by transport init call). This function does not touch the hardware because hardware use signals that are not yet read from config file at this point! In general SELECT do the setup for OpenOCD and it should be called before INIT. INIT do the setup for the transport internals and launches the transport by detecting DAP. >>> No, all this is necessary. Again, no care how it is implemented, but it >>> must be implemented in some way for SWD. > >>Then it can be another function in dap_ops, a smarter replacement for >> current ABORT..? > > Yes, I prefer this. But OpenOCD maintainer should look into this and do the > decision. At the moment there is only a ABORT function that can ABORT the DAP. This could be extended to more versatile status read/write with no great API change or additional functions :-) There is already such function in libswd and the abort can only become a wrapper for this as in dp/ap_read/write case :-) Please take a look at line 120, the swd_dap_errors_handle(swd_ctx_t *swdctx, swd_operation_t operation, int *ctrlstat, int *abort) in http://libswd.git.sourceforge.net/git/gitweb.cgi?p=libswd/libswd;a=blob;f=src/libswd_dap.c. >>> But if JTAG memap_read is transport independent, maybe there will be a >>> performance problem. >>> I'm not sure how to process this patch. > >>This can be true as the impelementation of this part can take retry and >> error flags handling into account whereas other functions dont anf this >> could produce a slowdown. Will take a look at this when swd is finished, >> right now it it working and noone complains so I would not touch this >> part:-) > > No, you mis-understanding, I mean that remove adi_jtag_dp_scan in > mem_ap_read_buf_u32, so that this function can be transport independent. > > And again, OpenOCD maintainer should look into this and do the decision. At the moment with the master branch there is a direct call to the jtag in mem_ap_read_buf_u32(). In my fork I have simply created a wrapper that checks what is the transport and then calls mem_ap_read_buf_u32_jtag() or mem_ap_read_buf_u32_swd() accordingly. This is what I mean - the simple solution that keeps things working untouched as they were. If you want to modify the jtag transport go ahead and produce the transport independent version of dp/ap_read/write! The only thing that is required it need the automatic error flags and retry handling, so it returns the result or error, no matter how things are handled internally, so it will work the same for JTAG, SWD and other transports st the TARGET level :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
