On Mar 17, 2012 8:40 AM, "simonqian.openocd" <simonqian.open...@gmail.com>
wrote:
> Next will be adding the SWD drivers.
In order to have generic driver for transport layer I have introduced
TRANSFER and BITBANG methods to the interface structure. transfer can send
in and out bitstream from the array of chars, array of chars is provided by
transport-interface bridge, so the same function can be used in transport
for different drivers. BITBANG is used to control interface port state, it
can read and write to the port, specificaly driver then RnW/TRN buffers.
These two functions are the minimal set of functions to implement any
transport possible :-)
> I recommend to user the current JTAG queue functions.
Nope, that would create dependecy of transport on the openocd queue.
OpenOCD queue should be left for internal use only (also jtag queue should
be moved out from there into jtag transport). TRANSPORT is here to
translate target commands (ie. mem-ap read) into interface sequences (ie.
bitstream for generic drivers such as ft2232 or gpio and commands for
inteligent drivers such as versaloon).
LibSWD has its own internal queue and can handle DP/AP read/write and pass
the result to the drivers. The design idea was to have swd working even on
the gpio or parallel port with two resistor (maybe some diode) interface
:-) Versaloon as the intelligent driver has also its own queue in the
interface, target would simply send commands to the interface and interface
will handle the dp/ap read/write. Transport structure use function pointers
for this - jtag has its own (or should), swd has its own - selecting
transport simply switches the function set and calls transport_select
function from the set...
The transport functions are defined in transport.h and it goes something
like:
DAP_IDCODE
DAP_ABORT
DAP_FLUSH
DP_READ
DP_WRITE
AP_READ
AP_WRITE
This is all what is necessary to talk to the ADI using SWD.
LibSWD get commands and translates it into operations that can be used by
any interface, lets call it swd_generic transport - it requires at least
two interface functions: 1 to transfer bitstream in efficient way, 2 to set
the buffers for TRN. Versaloon can handle the commands itself so it can use
another transport that simply pass the dap operations to the interface,
lets call it swd_dedicated transport - in this case the inferface needs
only one function that would pass the dap operations into/from the
dedicated driver. The mentioned queue mechanism should be implemented in
this place, at best in the versaloon interface driver, because different
drivers can have different needs for buffering/enqueing..
This is clean and elegant solution huh..? :-)
> In my original SWD patch, I add SWD_SEQ and SWD_TRANSACT commands to
jtag_command_type.
> And add the corresponding struct in jtag_command_container.
> Add swd_add_sequence, swd_add_transact_out, swd_add_transact_in.
> And corresponding implementations in driver.c.
> Implement the SWD codes in adi_v5_swd.c, and fix ahbap_debugport_init.
I would recommend to put all this stuff into dedicated versaloon inferface
driver and do not put any solution dependent code into arm_adi_v5 as this
is neither part of the adi/target, nor swd transport itself... this would
also allow designers to handle operations just as they like/need :-)
> What's more, we'll need a command to set trn of SWD.
This is done by the interface function bridge that use only transfer and
bitbang generic calls. Please take a look at kt-link-swd.cfg and note
"interface_signal add RnW 0xMASK" definitions. For versaloon things should
be even simpler because it only gets dp_read and it handles the request
itself, no need to handle TRN by the user.. however it would be also nice
if versaloon provide bitbang interface in future to make it even more
versatile :-)
Best regards! :-)
Tomek
ps/2: greetings from a train, nice to have email access in pocket :-)
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
