Maybe there is some other way to omit this parameter, I'll be happy to use it
if it is possible.
I just pointed out the problem why it doesn't work if we use dap_queue_ap_read
and dap_queue_dp_read instead of adi_jtag_dp_scan.
BTW, I'll visit Switzerland and France, hope there will be free wifi in my
hotel.
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" <simonqian.open...@gmail.com>
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
OpenOCD-devel@lists.sourceforge.net
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
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
