Re: [Openocd-development] [PATCH] interface decrease calling overhead
On 02/11/2011 07:29 AM, Øyvind Harboe wrote: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? I am not too fond of this since it exposes internals that should stay internals (variables that were static are now globally visible). This might be OK if there really is a noticeable speed gain. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
On Fri, Feb 11, 2011 at 8:41 AM, Michael Schwingen rincew...@discworld.dascon.de wrote: On 02/11/2011 07:29 AM, Øyvind Harboe wrote: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? I am not too fond of this since it exposes internals that should stay internals (variables that were static are now globally visible). This might be OK if there really is a noticeable speed gain. I'm also interested to see if there is a design flaw that results in this sort of change having a big impact. That said, with some numbers to back up this particular optimization and no other patch in sight, I'm happy to commit this one. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Here I have objection. Adding delay by flushing queue is not a good implementation, since the flush of the queue will have different timing regarding the JTAG probe used: - With Amontec JTAGkey USB full-speed a flush will be around 1-2ms - With Amontec JTAGkey-2 USB High-speed a flush will be around 125us - 250us. - With the coming Amontec Smart JTAGkey-x (running openocd on the JTAGkey) a flush will be around 100ns - 200ns. ... For JTAG the best to add delay will be to use a run tck in IDLE state. Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, i think this patch make sense because the functions are called very often (column calls in the profile data) and do a little bit more then nothing. Am 11.02.2011 07:29, schrieb Øyvind Harboe: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? If you start optimizing the code with the result of a performance improvement you are looking for functions that called very often and/or use a couple of the application runtime. Not all functions you find can be optimized and its always a compromise between maintainability/clearness, performance and a stable api. I mean the tap stuff inside the interface.c file is part of the heard of openocd and can be made more efficiency. In one part of the file fast tms sequence tables are used and mixed with case statements to determine the tms path and in another part of the file the tap state transistion is determined by a big case statement, why no faster tables there ? Is there any profiling data that backs up this particular optimization as particularly effective? Thats the profile stuff of my session. I read 1 words of the memory and because the nature of the once interface (dsp563xx) there are many tap state changes. With other targets this may not happen because a better/other jtag interface design. Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 31.82 0.07 0.07 131877 0.00 0.00 clock_tms 18.18 0.11 0.04 385430 0.00 0.00 tap_state_transition 13.64 0.14 0.037 0.00 0.00 buf_set_buf 9.09 0.16 0.02 800438 0.00 0.00 tap_get_state *** 9.09 0.18 0.02 607648 0.00 0.00 tap_move_ndx 4.55 0.19 0.01 385430 0.00 0.00 tap_set_state_impl *** 4.55 0.20 0.01 182295 0.00 0.00 tap_get_tms_path_len 4.55 0.21 0.0160767 0.00 0.00 tap_is_state_stable 4.55 0.22 0.0160765 0.00 0.00 ft2232_execute_scan 0.00 0.22 0.00 243066 0.00 0.00 cmd_queue_alloc 0.00 0.22 0.00 232715 0.00 0.00 tap_get_end_state *** 0.00 0.22 0.00 121530 0.00 0.00 jtag_scan_type 0.00 0.22 0.00 121529 0.00 0.00 tap_get_tms_path 0.00 0.22 0.007 0.00 0.00 buf_cpy 0.00 0.22 0.0071110 0.00 0.00 move_to_state 0.00 0.22 0.0060768 0.00 0.00 jtag_queue_command 0.00 0.22 0.0060767 0.00 0.00 ft2232_end_state 0.00 0.22 0.0060767 0.00 0.00 jtag_checks 0.00 0.22 0.0060767 0.00 0.00 jtag_prelude 0.00 0.22 0.0060767 0.00 0.00 tap_set_end_state *** ... snip ... In sum there are 4308134 function calls in this session and the marked 4 functions are called 1479350 times (34%) in sum without any real algorithm inside the function body. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
What kind of CPU are you running OpenOCD on? It's great that you are basing your optimizations on profiling information. That always makes for a convincing case. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:01, schrieb Øyvind Harboe: What kind of CPU are you running OpenOCD on? It's a Intel T7200. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
How about rewriting clock_tms then? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:17, schrieb Øyvind Harboe: How about rewriting clock_tms then? Because the used time? This session was to short (some seconds) to get a meaningful time statistic. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Anyone able to program ADuC7022?
Some progress. I just realized that my ADuC7022 is an x32 and my others (7020 7021) and x62 The x32 is 32k flash/4k ram and the x62 is 62k/8k /* flash bank aduc702x 0 0 0 0 target# * The ADC7019-28 devices all have the same flash layout */ It looks like that statement was not quite right. I may look at changing the flash bank command so you can pass in 32 or 62 like this: flash bank aduc702x 32 0 0 0 target# tom _ From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Tom Moulton Sent: Wednesday, February 09, 2011 11:48 AM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Anyone able to program ADuC7022? I am about to try programming my part again and was hoping someone has been able to use it. We can program ADuC7020's 7021's (and some others) but not 7022. I last tried last May. and am going to try again. tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cortex_a9: implement read/write memory through APB-AP
On 11/02/2011 1.26, Aaron Carroll wrote: Hi Luca, On 11 February 2011 02:00, du...@dummy.comdu...@dummy.com wrote: On 10/02/2011 11.10, Aaron Carroll wrote: On 10 February 2011 06:19, Luca Ellerolro...@gmail.comwrote: This patch adds read/write capability to memory addresses not accessible through AHB-AP (for example boot ROM code). To select between AHB and APB, a dap apsel command must be issued: dap apsel 0 -following memory accesses are throuhg AHB dap apsel 1 -following memory accesses are throuhg APB Seems a weird usage of apsel. Could this be made more general, say a command to set the memory access type (core, hostbus, etc). dap apsel 0 isn't very informative to users. ...well, yes, it is. But I didn't find a better way, without heavily impacting other architectures. Anyway, apart from getting some info on AP (which actually is wrong on cortex_A9) what is the exact usefulness of dap apsel? Good question, I have no idea. Regarding incorrect dap info, I think actually it's a correct interpretation... the APB-AP ROM is empty on all the omap4430's I've tried. Maybe it has to be set at dap level (in arm_adi_v5.c), but here it will eventually end-up in something like dap apsel? Have you any suggestions? Firstly, I don't think this is really a DAP or even an ARM issue. In general, there may be multiple ways to access main memory (through the core, through any number of direct bus connections... perhaps there are others), and this should be configurable. I think the right solution is some combination of: 1) a flag to the memory-accessing commands; 2) a table of memory regions to access methods. Probably this has some per-SoC/board defaults which can be amended/overridden in .cfgs. 3) a global user-configurable default. (3) is more-or-less what you've done. If we have a per-target configuration parameter (memtype_default, memaccess_default, something like that?), then the relevant target code can check it before performing the access. Maybe the best way of doing it is a per-target callback. This way, the memory access types don't need to be defined globally, targets can check that valid access types are specified, and it provides a nice transition... empty callback means it isn't supported. I agree, I'll investigate a bit to see if we can find a good solution. Anyway I think that this is a decision that must be approved by the majority of developers, because it impacts heavily all the source code and documentation. We have to keep in mind that also other commands use memory access, for example arm disassemble, dump_image, load_image I'm quite new in developing openocd, so I think I'm not the right one to take this decision ;-) cheers luca ellero ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
On a memory read/write access the queue has always flushed at the end. But if i read some more data without a queue excecute in the middle and only at the end i get this error: Error: ftdi_write_data: usb bulk write failed Error: couldn't write MPSSE commands to FT2232 I think there are to much data in the queue??? I don't know what happens there. With a queue excecute after every single memory word read/write access this function is horrible slow and the jtag sclk has really long pause between the single transfers. Regards, Mathias Am 11.02.2011 09:34, schrieb Laurent Gauch: Here I have objection. Adding delay by flushing queue is not a good implementation, since the flush of the queue will have different timing regarding the JTAG probe used: - With Amontec JTAGkey USB full-speed a flush will be around 1-2ms - With Amontec JTAGkey-2 USB High-speed a flush will be around 125us - 250us. - With the coming Amontec Smart JTAGkey-x (running openocd on the JTAGkey) a flush will be around 100ns - 200ns. ... For JTAG the best to add delay will be to use a run tck in IDLE state. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
Am 30.12.2010 13:51, schrieb Antonio Borneo:
On Thu, Dec 30, 2010 at 11:54 AM, Marek Vasutmarek.va...@gmail.com wrote:
} broken_cpus[] = {
- { 0x8000, 0x04770002, 0x6000, imx51 },
+ { 0x8000, 0x04770002, 0x1ba00477, 0x6000, imx51 },
Hi Marek,
your patch goes in the right direction, but I think there is a mistake.
You compare the JTAG idcode with 0x1ba00477.
This value belongs to ARM debug port, not to TI or Freescale devices.
S3CPC100 from Samsung is also detected as imx51 with this patch. Without this
patch it works.
Daniel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Hello,
Am 11.02.2011 16:21, schrieb Mathias K.:
On a memory read/write access the queue has always flushed at the end.
But if i read some more data without a queue excecute in the middle and only
at the end i get this
error:
Error: ftdi_write_data: usb bulk write failed
Error: couldn't write MPSSE commands to FT2232
I think there are to much data in the queue??? I don't know what happens
there.
I have found it. The command buffer overflows and the jtag stop working. I have
add a simple patch
and a description of a possible better solution (hopefully).
Regards,
Mathias
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index f8b2927..b6a1a3a 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2081,11 +2081,20 @@ static int ft2232_execute_queue(void)
while (cmd)
{
+ /* fill the write buffer with the desired command */
if (ft2232_execute_command(cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
- /* Start reading input before FT2232 TX buffer fills up */
+ /* Start reading input before FT2232 TX buffer fills up
+* TODO: sometimes this happens because we don't know the
+* length of the last executed command so we have to
+* rewind the buffer, start send_and_recv and execute
+* the last command again
+*
+* is this to much work for you simple decrease this magic
+* number and try it again ;-)
+*/
cmd = cmd-next;
- if (ft2232_expect_read 256)
+ if (ft2232_expect_read 255)
{
if (ft2232_send_and_recv(first_unsent, cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
W dniu 2010-12-30 08:34, Marek Vasut pisze: On Thursday 30 December 2010 08:27:52 Øyvind Harboe wrote: Merged. Thanks! Took it for a spin on AM3517 and that target is no longer incorrectly identified as an imx51. That target still needs work though: oyvind@titan:~/workspace/openocd$ openocd -c interface ZY1000; zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'ZY1000' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 50 kHz 10 kHz trst_only separate trst_push_pull jtag_speed 6000 = JTAG clk=10 kHz Info : clock speed 10 kHz Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG tap: am35x.dap enabled Info : am35x.cpu: hardware has 6 breakpoints, 2 watchpoints Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR These errors here, right ... need to investigate. Any pointers possibly ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Hello, Maybe the access to 0x5401 1140 error above has something to do with power domains? The registers accessed without error (in cortex_a8.c) are placed in debug power domain, and e.g. the breakpoint control registers (first address in 0x5401 1140) are in core power domain. Best regards, Kuba ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
