Re: [Openocd-development] [PATCH] cortex_a9: implement read/write memory through APB-AP
On Thu, Feb 10, 2011 at 8:57 AM, luca ellero lro...@gmail.com wrote: Sorry for the double posting. I made some mess :-( Please discard 1st posting, 2nd is the right one. Apologies for any inconvenience This is the right one? https://lists.berlios.de/pipermail/openocd-development/2011-February/018067.html -- Ø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] cortex_a9: implement read/write memory through APB-AP
2011/2/10 Øyvind Harboe oyvind.har...@zylin.com On Thu, Feb 10, 2011 at 8:57 AM, luca ellero lro...@gmail.com wrote: Sorry for the double posting. I made some mess :-( Please discard 1st posting, 2nd is the right one. Apologies for any inconvenience This is the right one? https://lists.berlios.de/pipermail/openocd-development/2011-February/018067.html Yes ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cortex_a9: fix dap_ap_select() usage
On 09/02/2011 10.57, Øyvind Harboe wrote: Hi Aaron, On Wed, Feb 9, 2011 at 10:54 AM, Aaron Carrollaar...@cse.unsw.edu.au wrote: Hi all, I think the consensus on this issue is that AP handling could be improved. Until someone has the motivation to fix it properly, can this patch be applied? A9 reset is broken without it. What I generally do is that I let discussions play out, but if no-one steps up with a better patch, then the first one goes in. Does this patch break anything that you know of? Any objections out there to committing for now? I confirm that this patch solves some issues with reset. Without it, when I inserted a hw breakpoint and then issued a reset, the processor correctly halted at the bp but I wasn't able to resume or step. Breakpoint already set was the error. With this patch applied, it works OK. Maybe the gotos are not very good-looking but sometimes necessary ;-) in any case we can fix them in the future. regards Luca Ellero ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cortex_a9: fix dap_ap_select() usage
Merged. Thanks! -- Ø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] cortex_a9: implement read/write memory through APB-AP
Merged. Thanks! -- Ø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
[Openocd-development] Problems with commit messages
I think perhaps there is a problem with commit messages these days on sourceforge. Anyone? Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 1.37 KiB, done. Total 5 (delta 4), reused 0 (delta 0) hooks/post-receive: line 639: /usr/sbin/sendmail: No such file or directory error: cannot run hooks/post-receive: No such file or directory -- Ø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] cortex_a9: implement read/write memory through APB-AP
Hi Luca,
On 10 February 2011 06:19, Luca Ellero lro...@gmail.com wrote:
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.
@@ -1478,29 +1478,76 @@ static int cortex_a9_read_phys_memory(struct target
*target,
Won't access via the core end up being translated by the MMU? IOW, is
this really a 'phys' access?
+ if ( apsel == 0) {
Use the swjdp_memoryap macro.
+ /* save registers r0 and r1, we are going to corrupt
them */
+ retval = cortex_a9_dap_read_coreregister_u32(target,
saved_r0, 0);
+ if (retval != ERROR_OK)
+ return retval;
What if the core isn't halted?
Cheers,
-- Aaron
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with commit messages
On 10/02/2011 09:09, Øyvind Harboe wrote: I think perhaps there is a problem with commit messages these days on sourceforge. Anyone? I just did a small commit and received no email, so looks like something has broken. I was sent an email yesterday about changes: http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web#ChangesasofFebruary2011 Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] current and maximum jtag queue size for jtag hardware ?
Hello, is there any way to determine the current and maximum queue size before a jtag_execute_queue() has to be executed ? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] current and maximum jtag queue size for jtag hardware ?
On Thu, Feb 10, 2011 at 8:05 PM, Mathias K. kes...@freenet.de wrote: Hello, is there any way to determine the current and maximum queue size before a jtag_execute_queue() has to be executed ? no and no. There is no maximum queue size and the api doesn't and should expose the queue size. Also the api allows for the queue to start executing *before* jtag_execute_queue() is invoked(e.g. hardware FIFO), jtag_execute_queue() just ensures that the queue is flushed. -- Ø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] current and maximum jtag queue size for jtag hardware ?
no and no. There is no maximum queue size and the api doesn't and should expose the queue size. 'should not' -- Ø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] Correct definition of JTAG_INSTR_CLAMP in dsp563xx_once.c
Hello, in app. note AN1839 (dsp563xx) its 3 ;-). In DSP56300FM and AN2074 they use the correct number 5. Regards, Mathias Am 10.02.2011 20:25, schrieb Phil Fong: Hi, I've been working on Rodrigo on adding support to flash Freescale dsp56800e devices and have been looking at the dsp563xx code. I think the define for the JTAG CLAMP instruction in dsp563xx_once.c is incorrect. It should be 0x05 according the Freescale AN2074 (and is also 0x05 in the dsp568xx according to AN1935). It won't actually change anything in OpenOCD since this define is not used anywhere (as far as I can tell). The patch below fixes this. Phil --- src/target/dsp563xx_once.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/target/dsp563xx_once.c b/src/target/dsp563xx_once.c index b7443fa..1d04e89 100644 --- a/src/target/dsp563xx_once.c +++ b/src/target/dsp563xx_once.c @@ -37,8 +37,8 @@ #define JTAG_INSTR_EXTEST0x00 #define JTAG_INSTR_SAMPLE_PRELOAD0x01 #define JTAG_INSTR_IDCODE0x02 -#define JTAG_INSTR_CLAMP0x03 #define JTAG_INSTR_HIZ0x04 +#define JTAG_INSTR_CLAMP0x05 #define JTAG_INSTR_ENABLE_ONCE0x06 #define JTAG_INSTR_DEBUG_REQUEST0x07 #define JTAG_INSTR_BYPASS0x0F ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] dsp563xx mem rw changes
Changes:
- delay jtag queue excecution to decrease memory read/write times
- fix an early queue excecution in once interface
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 4371d0a..9bfb9a1 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -29,8 +29,6 @@
#include dsp563xx.h
#include dsp563xx_once.h
-//#define DSP563XX_JTAG_INS_LEN 4
-
#define ASM_REG_W_R0 0x60F400
#define ASM_REG_W_R1 0x61F400
#define ASM_REG_W_R2 0x62F400
@@ -1129,6 +1127,7 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
uint32_t i, x;
uint32_t data, move_cmd;
uint8_t *b;
+ int flush_cnt;
LOG_DEBUG(address: 0x%8.8 PRIx32 , size: 0x%8.8 PRIx32 , count:
0x%8.8 PRIx32, address, size, count);
@@ -1141,6 +1140,7 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
switch (mem_type)
{
case MEM_X:
+ /* TODO: mark effected queued registers */
move_cmd = 0x61d800;
break;
case MEM_Y:
@@ -1167,23 +1167,43 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
x = count;
b = buffer;
+ flush_cnt = 0;
if ((err = dsp563xx_once_execute_dw_ir(target-tap, 0x60F400, address))
!= ERROR_OK)
return err;
for (i = 0; i x; i++)
{
- data = 0;
if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, 0x08D13C))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
0x08D13C)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_reg_read(target-tap,
DSP563XX_ONCE_OGDBR, data)) != ERROR_OK)
+ if ((err = dsp563xx_once_reg_read_nq(target-tap,
DSP563XX_ONCE_OGDBR, (uint32_t*)b)) != ERROR_OK)
return err;
- target_buffer_set_u32(target, b, data);
b += 4;
- LOG_DEBUG(R: %08X, data);
+ /* delay jtag queue excecution */
+ if ( ++flush_cnt = 20 )
+ {
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+ flush_cnt = 0;
+ }
+ }
+
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+
+ /* walk over the buffer and fix target endianness */
+ b = buffer;
+
+ for (i = 0; i x; i++)
+ {
+ data = *((uint32_t*)b) 0x00FF;
+// LOG_DEBUG(R: %08X, *((uint32_t*)b));
+ target_buffer_set_u32(target, b, data);
+ b += 4;
}
return ERROR_OK;
@@ -1201,6 +1221,7 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
uint32_t i, x;
uint32_t data, move_cmd;
uint8_t *b;
+ int flush_cnt;
LOG_DEBUG(address: 0x%8.8 PRIx32 , size: 0x%8.8 PRIx32 , count:
0x%8.8 PRIx32 , address, size, count);
@@ -1239,6 +1260,7 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
x = count;
b = buffer;
+ flush_cnt = 0;
if ((err = dsp563xx_once_execute_dw_ir(target-tap, 0x60F400, address))
!= ERROR_OK)
return err;
@@ -1246,18 +1268,30 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
for (i = 0; i x; i++)
{
data = target_buffer_get_u32(target, b);
- data = 0x00ff;
- LOG_DEBUG(W: %08X, data);
+// LOG_DEBUG(W: %08X, data);
+
+ data = 0x00ff;
if ((err = dsp563xx_once_execute_dw_ir_nq(target-tap,
0x61F400, data)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, move_cmd))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
-
b += 4;
+
+ /* delay jtag queue excecution */
+ if ( flush_cnt++ = 20 )
+ {
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+ flush_cnt = 0;
+ }
}
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+
return ERROR_OK;
}
@@ -1266,6 +1300,11 @@ static int dsp563xx_write_memory_p(struct target
*target, uint32_t address, uint
return dsp563xx_write_memory(target, MEM_P, address, size, count,
buffer);
}
+static int
Re: [Openocd-development] [PATCH] cortex_a9: implement read/write memory through APB-AP
Hi Luca, On 11 February 2011 02:00, du...@dummy.com du...@dummy.com wrote: On 10/02/2011 11.10, Aaron Carroll wrote: On 10 February 2011 06:19, Luca Ellerolro...@gmail.com wrote: 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. Cheers, -- Aaron ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] JTAG_STABLECLOCKS for jlink
After some experimenting with building the right cable and generating an appropriate SVF file, I was able to program a Lattice XP2 using OpenOCD and a Signalyzer-H2. Since I also have a jlink, I figured why not give that a shot. It seems that the jlink does not have the JTAG_STABLECLOCKS jtag command implemented which is required for this SVF file. Poking around jlink.c, seems to indicate that JTAG_STABLECLOCKS could be implemented using jlink_tap_append_step() if you knew what TDI should be during the clocking. Any clues on how to figure out what TDI is supposed to be? Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] interface decrease calling overhead
Changes:
- declare tap_set_state_impl, tap_get_state, tap_set_end_state,
tap_get_end_state as static inline,
this will decrease the calling overhead for this status getter and setter
functions
diff --git a/src/jtag/interface.c b/src/jtag/interface.c
index 1ed4512..8d5d514 100644
--- a/src/jtag/interface.c
+++ b/src/jtag/interface.c
@@ -38,38 +38,13 @@
* @see tap_set_state() and tap_get_state() accessors.
* Actual name is not important since accessors hide it.
*/
-static tap_state_t state_follower = TAP_RESET;
-
-void tap_set_state_impl(tap_state_t new_state)
-{
- /* this is the state we think the TAPs are in now, was cur_state */
- state_follower = new_state;
-}
-
-tap_state_t tap_get_state()
-{
- return state_follower;
-}
+tap_state_t state_follower = TAP_RESET;
/**
* @see tap_set_end_state() and tap_get_end_state() accessors.
* Actual name is not important because accessors hide it.
*/
-static tap_state_t end_state_follower = TAP_RESET;
-
-void tap_set_end_state(tap_state_t new_end_state)
-{
- /* this is the state we think the TAPs will be in at completion of the
- current TAP operation, was end_state
- */
- end_state_follower = new_end_state;
-}
-
-tap_state_t tap_get_end_state()
-{
- return end_state_follower;
-}
-
+tap_state_t end_state_follower = TAP_RESET;
int tap_move_ndx(tap_state_t astate)
{
diff --git a/src/jtag/interface.h b/src/jtag/interface.h
index 958af8f..623b106 100644
--- a/src/jtag/interface.h
+++ b/src/jtag/interface.h
@@ -36,9 +36,15 @@
* cable.
*/
+/** */
+extern tap_state_t state_follower;
/** implementation of wrapper function tap_set_state() */
-void tap_set_state_impl(tap_state_t new_state);
+static inline void tap_set_state_impl(tap_state_t new_state)
+{
+ /* this is the state we think the TAPs are in now, was cur_state */
+ state_follower = new_state;
+}
/**
* This function sets the state of a state follower which tracks the
@@ -74,7 +80,13 @@ static inline void tap_set_state(tap_state_t new_state)
* state of the TAPs connected to the cable. @see tap_set_state @return
* tap_state_t The state the TAPs are in now.
*/
-tap_state_t tap_get_state(void);
+static inline tap_state_t tap_get_state(void)
+{
+ return state_follower;
+}
+
+/** */
+extern tap_state_t end_state_follower;
/**
* This function sets the state of an end state follower which tracks
@@ -87,13 +99,23 @@ tap_state_t tap_get_state(void);
* @param new_end_state The state the TAPs should enter at completion of
* a pending TAP operation.
*/
-void tap_set_end_state(tap_state_t new_end_state);
+static inline void tap_set_end_state(tap_state_t new_end_state)
+{
+ /* this is the state we think the TAPs will be in at completion of the
+ current TAP operation, was end_state
+ */
+ end_state_follower = new_end_state;
+}
/**
* For more information, @see tap_set_end_state
* @return tap_state_t - The state the TAPs should be in at completion of the
current TAP operation.
*/
-tap_state_t tap_get_end_state(void);
+static inline tap_state_t tap_get_end_state(void)
+{
+ return end_state_follower;
+}
+
/**
* This function provides a bit sequence indicating what has to be
___
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
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? Is there any profiling data that backs up this particular optimization as particularly effective? It is very surprising that this would make an impact, but that's what good profiling data result in, small changes that are surprisingly effective. -- Ø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
