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 :-)
0002-add-mem_ap_read_buf_u32_swd.patch
Description: Binary data
------------------------------------------------------------------------------ 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
