Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Matt Hsu wrote: The following is my log of setting up a breakpoint: Telnet session Did you already try to attach and control all this with gdb? Or anybody else? Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Hi all,
This series patches fix the hardware single-step logic mainly.
With these patches, you can do the step operation on the telnet session.
Also, the programming breakpoints works as well.
Cheers,
Matt
From 8fc6c1839b80447e06c368b0d8948f5feda3e474 Mon Sep 17 00:00:00 2001
From: Matt Hsu m...@0xlab.org
Date: Thu, 3 Sep 2009 21:21:02 +0800
Subject: [PATCH 1/3] [Cortex_A8] Add Bit-offset for DSCR
Signed-off-by: Matt Hsu m...@0xlab.org
---
src/target/cortex_a8.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/target/cortex_a8.h b/src/target/cortex_a8.h
index bb57b13..a1efe66 100644
--- a/src/target/cortex_a8.h
+++ b/src/target/cortex_a8.h
@@ -67,6 +67,15 @@ extern char* cortex_a8_state_strings[];
#define BRP_NORMAL 0
#define BRP_CONTEXT 1
+/* DSCR Bit offset */
+#define DSCR_CORE_HALTED 0
+#define DSCR_CORE_RESTARTED 1
+#define DSCR_EXT_INT_EN 13
+#define DSCR_HALT_DBG_MODE 14
+#define DSCR_MON_DBG_MODE 15
+#define DSCR_INSTR_COMP 24
+#define DSCR_DTR_TX_FULL 29
+
typedef struct cortex_a8_brp_s
{
int used;
--
1.6.0.4
From 2b8c724c79378440ec1cd37aa221453565b934c1 Mon Sep 17 00:00:00 2001
From: Matt Hsu m...@0xlab.org
Date: Thu, 3 Sep 2009 21:29:35 +0800
Subject: [PATCH 2/3] [Cortex_A8] Fix step/breakpoint logic
The breakpoints could be generated by enabling halting debug mode.
This patch also fixes hardware step, since signle-stepping is implemented by
allocating mismatch breakpoint.
Signed-off-by: Matt Hsu m...@0xlab.org
---
src/target/cortex_a8.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 829bf3d..948536a 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -430,6 +430,13 @@ int cortex_a8_halt(target_t *target)
retval = mem_ap_write_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1);
+ /*
+ * enter halting debug mode
+ */
+ mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
+ retval = mem_ap_write_atomic_u32(swjdp,
+ OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr | (1 DSCR_HALT_DBG_MODE));
+
if (retval != ERROR_OK)
goto out;
--
1.6.0.4
From a12b910299e740a0b8c1847ed883c24b284a4931 Mon Sep 17 00:00:00 2001
From: Matt Hsu m...@0xlab.org
Date: Thu, 3 Sep 2009 21:35:43 +0800
Subject: [PATCH 3/3] [Cortex_A8] Tidy up the bit-offset operation for DSCR register
Signed-off-by: Matt Hsu m...@0xlab.org
---
src/target/cortex_a8.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 948536a..5fa3103 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -166,7 +166,7 @@ int cortex_a8_exec_opcode(target_t *target, uint32_t opcode)
retvalue = mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
}
- while ((dscr (1 24)) == 0); /* Wait for InstrCompl bit to be set */
+ while ((dscr (1 DSCR_INSTR_COMP)) == 0); /* Wait for InstrCompl bit to be set */
mem_ap_write_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_ITR, opcode);
@@ -175,7 +175,7 @@ int cortex_a8_exec_opcode(target_t *target, uint32_t opcode)
retvalue = mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
}
- while ((dscr (1 24)) == 0); /* Wait for InstrCompl bit to be set */
+ while ((dscr (1 DSCR_INSTR_COMP)) == 0); /* Wait for InstrCompl bit to be set */
return retvalue;
}
@@ -291,7 +291,7 @@ int cortex_a8_dap_read_coreregister_u32(target_t *target,
retval = mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
}
- while ((dscr (1 29)) == 0); /* Wait for DTRRXfull */
+ while ((dscr (1 DSCR_DTR_TX_FULL)) == 0); /* Wait for DTRRXfull */
retval = mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DTRTX, value);
@@ -443,7 +443,7 @@ int cortex_a8_halt(target_t *target)
do {
mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
- } while ((dscr (1 0)) == 0);
+ } while ((dscr (1 DSCR_CORE_HALTED)) == 0);
target-debug_reason = DBG_REASON_DBGRQ;
@@ -542,7 +542,7 @@ int cortex_a8_resume(struct target_s *target, int current,
do {
mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
- } while ((dscr (1 1)) == 0);
+ } while ((dscr (1 DSCR_CORE_RESTARTED)) == 0);
target-debug_reason = DBG_REASON_NOTHALTED;
target-state = TARGET_RUNNING;
@@ -589,7 +589,7 @@ int cortex_a8_debug_entry(target_t *target)
/* Enable the ITR execution once we are in debug mode */
mem_ap_read_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
- dscr |= (1 13);
+ dscr |= (1 DSCR_EXT_INT_EN);
retval = mem_ap_write_atomic_u32(swjdp,
OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr);
--
1.6.0.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
On Thu, Sep 3, 2009 at 3:58 PM, Matt Hsum...@0xlab.org wrote: Hi all, This series patches fix the hardware single-step logic mainly. With these patches, you can do the step operation on the telnet session. Also, the programming breakpoints works as well. Cheers, Matt Great! I haven't looked them over, but if nobody protests, I'll commit them in 24 hours. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Matt Hsu wrote: Hi all, This series patches fix the hardware single-step logic mainly. With these patches, you can do the step operation on the telnet session. Applying this patch series to r2663, what I can say from output of program counter (pc) this seems to work. So: Tested-by: Dirk Behme dirk.be...@googlemail.com Please apply. Also, the programming breakpoints works as well. Could you give some examples how you use this? Giving some logs of how you are testing would help other to reproduce this ;) Many thanks Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Re #1 and #3: I'd combine the add #defines and use #defines into one patch myself... minor point. Re #2: On Thursday 03 September 2009, Matt Hsu wrote: --- a/src/target/cortex_a8.c +++ b/src/target/cortex_a8.c @@ -430,6 +430,13 @@ int cortex_a8_halt(target_t *target) retval = mem_ap_write_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1); Surely that if (retval != ERROR_OK) goto out; is still needed here... + /* + * enter halting debug mode + */ + mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr); + retval = mem_ap_write_atomic_u32(swjdp, + OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr | (1 DSCR_HALT_DBG_MODE)); + if (retval != ERROR_OK) goto out; ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Matt Hsu wrote: Hi all, This series patches fix the hardware single-step logic mainly. With these patches, you can do the step operation on the telnet session. Also, the programming breakpoints works as well. Cheers, Matt ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Hi Matt, It makes me very happy to se active work with this code. The bit offset handling is very nice, patches 0001 and 0003. The second patch is more worth thinking about. For the Omap353x we set the DSCR[DSCR_HALT_DBG_MODE] bit in the setup script, and we then assume that the running application does not actively play with the debug settings. This can of course be discussed. Anyway, if we want to set this bit every time we call halt, a small extra cost in USB return trips, then I think the logical place is before we try to halt the core by writing to bit 0 of DRCR. I cannot really se how this patch modifies single stepping or breakpoint handling, can you describe that. It would be helpful with some descriptions of how and when problems occured that you are solving with your patches. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
On Thursday 03 September 2009, Magnus Lundin wrote: For the Omap353x we set the DSCR[DSCR_HALT_DBG_MODE] bit in the setup script, and we then assume that the running application does not actively play with the debug settings. This can of course be discussed. Cortex M3 does similar stuff but not in the init script; I see no reason not to just put this in the C code for both cores. A generic issue related to setting the halt mode debug flag (and similar debug hooks) is that if OpenOCD were to support debugging monitors for more than XScale -- which seems to require one! -- we'd need to change that and related things. I can't come up with a reason why debug settings would be changed that doesn't involve monitor mode (or equivalent). To recap: an alternative to halt mode debug is monitor mode, where debug traps are intercepted by target-resident code which handles them, and which communicates (using DCC or equivalent) with the external debugger. A compelling example of where that is needed seems to be motor control: the motor won't stop just because a breakpoint was hit, motor control activities need to continue. Maybe debug just this task applications fit too. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Matt Hsu wrote: David Brownell wrote: Re #1 and #3: I'd combine the add #defines and use #defines into one patch myself... minor point. Hi David, It sounds fine to me and makes the description clear. I will make v2 patches and submit later. Please note that patches #1 and #3 are already committed. We still need (an updated?) #2, though. https://lists.berlios.de/pipermail/openocd-development/2009-September/010343.html Best regards Dirk Re #2: On Thursday 03 September 2009, Matt Hsu wrote: --- a/src/target/cortex_a8.c +++ b/src/target/cortex_a8.c @@ -430,6 +430,13 @@ int cortex_a8_halt(target_t *target) retval = mem_ap_write_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1); Surely that if (retval != ERROR_OK) goto out; is still needed here... + /* +* enter halting debug mode +*/ + mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr); + retval = mem_ap_write_atomic_u32(swjdp, + OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr | (1 DSCR_HALT_DBG_MODE)); + if (retval != ERROR_OK) goto out; ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Øyvind Harboe wrote: 1 and 3 committed. Can you let me know when 2 is ready to commit? Hi Øyvind, I will resend the patch #2 since I think the following code segment should be merged. retval = mem_ap_write_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1); mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr); retval = mem_ap_write_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr | (1 DSCR_HALT_DBG_MODE)); About the correct place to enable the debug mode bit, right now, I could not think about a better place for it. My personal thinking is commit first. At least, it works for me. People can refine this later. Cheers, Matt (I'm not following the details, but there appears to be some discussion on that change still...) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
