Another problem:
Should we create script files for targets which support SWD, remove jtag
commands?
For example, create stm32f1_jtag.cfg and stm32f1_swd.jtag instead of
stm32f1.cfg.
If "transport select swd" is called before processing target scripts,
get_current_target in swd_init will fail.
If "transport select swd" is called after processing target scripts, all jtag
commands in target scripts will fail.
simonqian.openocd
From: simonqian.openocd
Date: 2012-03-19 21:17
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
I attached the patch for mem_ap_read_buf_swd, which looks like Tomek's patch.
But the code it just same as JTAG ones.
I'll later try implementing a swd_driver structure for Versaloon SWD driver.
To Tomek: Do you have any supplement for swd_driver structure?
I hope this job could be finished before 24th April, before which I can have
enough time.
simonqian.openocd
From: simonqian.openocd
Date: 2012-03-17 20:22
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yes, these functions are in dap_ops structure.
To implement SWD, nothing more than a dap_ops structure and a transport
structure will be necessary.
So, you mean use dap_ops struct as swd driver struct?
A interface which supports SWD, will provide a dap_ops sturcture for swd
operations?
It's also OK for me, I can even write these functions in versaloon hardware.
If we could define a common API for SWD, I can do the test ASAP.
I found a swd_driver struct in swd.h, which seems much simpler.
But I haven't tried using this driver.
The driver has only 3 main APIs:
int (*init)(uint8_t trn);
int (*read_reg)(uint8_t cmd, uint32_t *value);
int (*write_reg)(uint8_t cmd, uint32_t value);
And current swd_dap_ops in adi_v5_swd.c simply calls these functions.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-03-17 18:15
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
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
