Yes, your functions are OK.
But in my implementation, there are no mem_ap_read_buf_u32_jtag and
mem_ap_read_buf_u32_swd, because the patch with 2 mem_ap_read_buf_u32 functions
is not allowed.
So I have to implement a single mem_ap_read_buf_u32, which is already in the
review list.
But it's not simple because of the differences between JTAG and SWD.
You can try to use dap_queue_dp_read and dap_queue_ap_read instead of
adi_jtag_dp_scan, to see whether it works for JTAG.
But for SWD, it's OK, because of the difference when access RDBUFF on JTAG and
SWD.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-04-24 17:36
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Hello Simon :-) What is the exact function of the posprocess and why it is not
possible to work without that parameter? My code does not change the API and it
works both for JTAG and SWD. Why is wrapper bad? It has to be implemented
anyway..?
Have a nice trip to Europe! Which country(ies) will you visit? :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Apr 24, 2012 11:23 AM, "simonqian.openocd" <[email protected]>
wrote:
I have implemented the mem_ap_read_buf_u32 function which is adaptor
independent.
But I added a extra parameter to dap_queue_dp_read and dap_queue_ap_read,
because of posted operations when read.
Actually, there is difference between JTAG and SWD in RDBUFF behaviour, please
refer to IHI0031A_ARM_debug_interface_v5 file, section 6.2.5 and some other
related sections. So there is always problem when implementing a unique
dap_queue_dp_read for both JTAG and SWD.
Below is dap_queue_dp_read:
static inline int dap_queue_dp_read(struct adiv5_dap *dap,
unsigned reg, uint32_t *data, uint8_t post_process)
{
assert(dap->ops != NULL);
return dap->ops->queue_dp_read(dap, reg, data, post_process);
}
I add post_process to indicate whether the driver should process posted
operations when read.
Of course, post_process parameter is also added to queue_ap_read and
queue_dp_read in dap_ops structure.
And I tested it OK on JTAG on stm32 with no performance lost.
I'll leave tomorrow to Europe for my vacation, so I'll test SWD adaptor when
back after 2 weeks.
I commit the code to review today, and people can post comments.
simonqian.openocd
From: Peter Stuge
Date: 2012-04-17 16:39
To: openocd-devel
Subject: Re: [OpenOCD-devel] about making mem_ap_read_buf_u32 adaptor
independent
Tomek CEDRO wrote:
> 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 :-)
Please focus on Simon's patch in Gerrit, do you see some way that it
can be made more meaningful for the libswd effort?
It does not have to be an exact fit, but it should be in the right
direction. There can and should be further patches after we get this
patch from Simon's included.
Thanks!
//Peter
------------------------------------------------------------------------------
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------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
