[Openocd-development] LPCxxxx soft_reset_halt usage
Why is soft_reset_halt being used in the LPC init sequences?
I've tested LPC2478 and the reset init sequence seems flaky
When I modify the reset init sequence to use armv4_5 core_state arm
and things seems *much* more stable, e.g. I can erase/program flash
without getting spurious error messages.
I'm not quite sure why soft_reset_halt would make things flaky. Could
it be two problems here?
1. don't use soft_reset_halt to set ARM state
2. soft_reset_halt is flaky
Thoughts?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: tcl/target/lpc2478.cfg
===
--- tcl/target/lpc2478.cfg (revision 2652)
+++ tcl/target/lpc2478.cfg (working copy)
@@ -35,7 +35,7 @@
$_TARGETNAME configure -event reset-init {
# Force target into ARM state
- soft_reset_halt
+ armv4_5 core_state arm
# Do not remap 0x-0x0020 to anything but the Flash
mwb 0xE01FC040 0x01
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rft] arm_nandwrite()
Committed. Thanks! -- Ø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] FASTDATA bulk write optimization for mips_m4k file transfers
David Brownell wrote: Committed less init + reset init which does not belong in target configuration script. I think the reset-init handler likely belongs in a board init script too ... :) Specifics of DDR and clock setup vary between boards. Also, having the reset init script recurse into the reset halt logic can't be correct... The reset-halt was added because the pll configuration requires a processor reset for the PLL register settings to latch. The write to 0xb8050008 resets the processor If reset_halt is not there the processor is not halted after this new reset. Perhaps there is another way to do this, but it's working for me. The PLL settings are intentionally set to a lowest common value for all boards. If PLL and DDR settings are board-specific then it is my understanding that entire reset-init script should be removed from the target script. ___ 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] OpenOCD + beagle
On Monday 31 August 2009, Dirk Behme wrote:
Is anything like
if(omap3) {
/*
* Add a bunch of clocks after TLR entry to force SWD reset (newer
* ARM cores; just in case, ~50 cycles), switch on ICEpick power
* domains (for some TI parts, ~100 cycles), etc
*/
jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
}
possible? Or, probably better, enable/configure this by an external
configuration (TCL?) variable/parameter?
We need some more general mechanism. OpenOCD shouldn't
litter it's lower layers w/target specific hacks.
Any proposal how to do this that it can be applied?
When I came up with that I was mostly after a quick fix to
get a Beagle talking ... my thoughts on how to generalize
it were to just always issue 100 extra TCK cycles before
exiting the Test-Logic-Reset (TLR) state.
But as Øyvind noted, that quick fix doesn't quite work that
way ... the 100 cycles are not in TLR.
Two steps seem needed:
- come up with code adding N TCK cycles in TLR;
- make sure *all* TLR exit paths use that code
The latter is a bit tricky since the state management is a
bit scattered.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Use jtag_rclk instead of jtag_speed for BeagleBoard
David Brownell wrote: On Monday 31 August 2009, Dirk Behme wrote: David Brownell wrote: On Monday 31 August 2009, Dirk Behme wrote: +jtag_rclk + needs digits .. Hmm, really? Then, jtag_rclk seems to be broken: I think you're right... ;) What's about applying a patch without digits until jtag_rclk is fixed? Dirk jtag_rclk: -- cut -- RCLK - adaptive ... Info : clock speed 6000 kHz -- cut -- jtag_rclk 3000: -- cut -- RCLK - adaptive ... Info : RCLK (adaptive clock speed) not supported - fallback to 3000 kHz -- cut -- It seems to me, this is not what we want. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Use jtag_khz i nstead of jtag_speed for Flyswatter
On Monday 31 August 2009, Jonas Horberg wrote: I think than the board config file is the right place to put speed settings. It will benefit the end users if we provide good clock speed settings in the scripts that is shipped with OpenOCD. That's probably the best place to have defaults, or (if you will) upper limits. Yes. The maximum JTAG clock speed is mostly dependent of board specific things. Some examples: * The devices in the JTAG chain of the board. * The CPU clock source/speed. * Different source/speed before and after reset init. Some board files have scripts that change the clock source/speed at specific events. Necessary if adaptive clocking is not supported. An example would be the AT91 chips that come up with a 32 KHz system clock after they reset ... and need either boot code, or reset-init scripts, to set up oscillators and PLLs before fast clocks can be used, and JTAG can be used at multi-mbit data rates. * The routing of the JTAG wires. * Board support of RTCK. The interface driver should only set the speed to the requested or the closest lower supported speed. I do not think there is any problem running with a lower speed than the requested. All true. I suspect the thing I was thinking of when I said openocd.cfg is that it also depends on how the board boots ... and with JTAG you may well be debugging boot code. Or recovering a bricked board; in both cases, the board defaults likely won't help. The type and length of the cable that connects the interface to the board and also the interface driver strength have some influence. I think it is minor, but it is possible that we should be a bit conservative when we select the clock speed for the board scripts. If the board support RTCK (its MCU support it and it is routed to the JTAG connector, please consider to use the jtag_rclk instead of jtag_khz. It will fall back to a fixed clock speed if the interface do not support RTCK. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Use jtag_rclk instead of jtag_speed for BeagleBoard
On Monday 31 August 2009, Dirk Behme wrote: David Brownell wrote: On Monday 31 August 2009, Dirk Behme wrote: +jtag_rclk + needs digits .. Hmm, really? Then, jtag_rclk seems to be broken: I think you're right... jtag_rclk: -- cut -- RCLK - adaptive ... Info : clock speed 6000 kHz -- cut -- jtag_rclk 3000: -- cut -- RCLK - adaptive ... Info : RCLK (adaptive clock speed) not supported - fallback to 3000 kHz -- cut -- It seems to me, this is not what we want. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
On Thursday 03 September 2009, David Claffey wrote: David Brownell wrote: Committed less init + reset init which does not belong in target configuration script. I think the reset-init handler likely belongs in a board init script too ... :) Specifics of DDR and clock setup vary between boards. Also, having the reset init script recurse into the reset halt logic can't be correct... The reset-halt was added because the pll configuration requires a processor reset for the PLL register settings to latch. The write to 0xb8050008 resets the processor. Reset to latch PLL settings? Odd. One would expect a reset to re-initialize the PLL configuration too! That's how it's done on every other core I've had occasion to look at. Such odd requirements rate a comment. :) Is that software-triggered reset different from SRST? If so, how? What do boot loaders normally do with PLL setup then? Sounds like they look at the settings, and if they're not appropriate they'll fix them and reset. Wouldn't OpenOCD do the same? If reset_halt is not there the processor is not halted after this new reset. Perhaps there is another way to do this, but it's working for me. The reset sequence is a bit quirky IMO, and not yet up to some things that it needs to handle. There are a lot of flavors of reset, many ways to trigger them, and special cases everywhere. There are event hooks for reset-assert-pre and reset-deassert-post logic ... the reset-init is *way* late. Are you sure reset-init is the right hook to use for PLL setup on this core? (src/helper/startup.tcl has an ocd_process_reset script which you might not have come across ... showing the current set of reset events and their invocation sequence.) The PLL settings are intentionally set to a lowest common value for all boards. If PLL and DDR settings are board-specific I think you just said there that they wouldn't normally be the same ... but that there could be a least-common-denominator applied in some cases. Does this core do the usual, and (a) require PLL to get clocks fast enough to run DDR, (b) include some SRAM for boot code to use before DDR is available? If so, it seems reset-assert-pre might benefit from knowing it's prepping for reset-init (and thus should setup the PLL if it's not already done, before one of the resets) vs not (leaving that for the boot loader). then it is my understanding that entire reset-init script should be removed from the target script. That's my general assumption, yes. There could be reusable code that provides hooks for board-specific behavior ... but the reset-init script is doing a lot of what first stage of a boot loader does, and that's *extremely* board-specific. These chips have pin/ball configuration, yes? And have clock trees to set up? And other stuff that varies based on how the chip is wired into a particular board? - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Improved handling of Thumb state for Cortex_A8
Hello all Cortex_A8 fans !
Please test the following patch that hopefully corrects some insane
errors in Thumb state handling.
(Yes I wrote it myself, but it seems UBoot for BeagleBoard does not use
Thumb Mode)
Best regards
Magnus
Index: src/target/cortex_a8.c
===
--- src/target/cortex_a8.c (revision 2663)
+++ src/target/cortex_a8.c (working copy)
@@ -451,7 +458,6 @@
/* get pointers to arch-specific information */
armv4_5_common_t *armv4_5 = target-arch_info;
armv7a_common_t *armv7a = armv4_5-arch_info;
- cortex_a8_common_t *cortex_a8 = armv7a-arch_info;
swjdp_common_t *swjdp = armv7a-swjdp_info;
// breakpoint_t *breakpoint = NULL;
@@ -499,7 +505,7 @@
/* Make sure that the Armv7 gdb thumb fixups does not
* kill the return address
*/
- if (!(cortex_a8-cpudbg_dscr (1 5)))
+ if (armv7a-core_state == ARMV7A_STATE_ARM)
{
resume_pc = 0xFFFC;
}
@@ -631,7 +636,8 @@
dap_ap_select(swjdp, swjdp_debugap);
LOG_DEBUG(cpsr: %8.8 PRIx32, cpsr);
- armv4_5-core_mode = cpsr 0x3F;
+ armv4_5-core_mode = cpsr 0x1F;
+ armv7a-core_state = (cpsr 0x20)?ARMV7A_STATE_THUMB:ARMV7A_STATE_ARM;
for (i = 0; i = ARM_PC; i++)
{
@@ -650,8 +656,7 @@
ARMV7A_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 16).dirty = 0;
/* Fixup PC Resume Address */
- /* TODO Her we should use arch-core_state */
- if (cortex_a8-cpudbg_dscr (1 5))
+ if (armv7a-core_state == ARMV7A_STATE_THUMB)
{
// T bit set for Thumb or ThumbEE state
regfile[ARM_PC] -= 4;
@@ -736,7 +741,6 @@
/* get pointers to arch-specific information */
armv4_5_common_t *armv4_5 = target-arch_info;
armv7a_common_t *armv7a = armv4_5-arch_info;
- cortex_a8_common_t *cortex_a8 = armv7a-arch_info;
breakpoint_t *breakpoint = NULL;
breakpoint_t stepbreakpoint;
@@ -778,7 +782,7 @@
/* Setup single step breakpoint */
stepbreakpoint.address = address;
- stepbreakpoint.length = (cortex_a8-cpudbg_dscr (1 5)) ? 2 : 4;
+ stepbreakpoint.length = (armv7a-core_state == ARMV7A_STATE_THUMB) ? 2 : 4;
stepbreakpoint.type = BKPT_HARD;
stepbreakpoint.set = 0;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
Reset to latch PLL settings? Odd. One would expect a reset to
re-initialize the PLL configuration too! That's how it's done
on every other core I've had occasion to look at. Such odd
requirements rate a comment. :)
yes, it's odd. The plls are only reset by power-on reset, not SRST. They come
up with all the multipliers and dividers set to 1. Changes to the PLL registers
are only latched when the reset-switch is set in software, which causes
Is that software-triggered reset different from SRST? If so, how?
a full CPU reset says the data sheet.
What do boot loaders normally do with PLL setup then? Sounds
like they look at the settings, and if they're not appropriate
they'll fix them and reset. Wouldn't OpenOCD do the same?
The boot loader checks to see if the PLL is in the appropriate state. If so, it
skips the initialization. The appropriate value is either a user-specific value
or defaults to a value selected by a speed-step register in the core.
The reset sequence is a bit quirky IMO, and not yet up to some
things that it needs to handle. There are a lot of flavors of
reset, many ways to trigger them, and special cases everywhere.
There are event hooks for reset-assert-pre and reset-deassert-post
logic ... the reset-init is *way* late. Are you sure reset-init
is the right hook to use for PLL setup on this core?
(src/helper/startup.tcl has an ocd_process_reset script which
you might not have come across ... showing the current set of
reset events and their invocation sequence.)
I see your point. The config script was calling into reset recursively through
the event handler. I tried a few variations on the idea that the sequence is in
two steps: first program the pll registers is some event before reset-init, then
complete the rest in reset-init.
I kept getting target not halted errors until I put the pll setup in a
reset-halt-post handler. I'm guessing the target needs to be halted to send the
commands.
The PLL settings are intentionally set to a lowest common value for all
boards.
If PLL and DDR settings are board-specific
I think you just said there that they wouldn't normally be the
same ... but that there could be a least-common-denominator
applied in some cases.
Does this core do the usual, and (a) require PLL to get clocks
fast enough to run DDR, (b) include some SRAM for boot code to
use before DDR is available? If so, it seems reset-assert-pre
might benefit from knowing it's prepping for reset-init (and
thus should setup the PLL if it's not already done, before
one of the resets) vs not (leaving that for the boot loader).
There is no SRAM. Boot code sets up the PLL and DDR in assembly before any RAM
is used (no stack access).
then it is my understanding that
entire reset-init script should be removed from the target script.
That's my general assumption, yes. There could be reusable
code that provides hooks for board-specific behavior ... but
the reset-init script is doing a lot of what first stage of
a boot loader does, and that's *extremely* board-specific.
These chips have pin/ball configuration, yes? And have
clock trees to set up? And other stuff that varies based
on how the chip is wired into a particular board?
For this SoC most of the board is in the silicon except for one x16 DDR chip,
one SPI flash and the PCI bus. It's highly integrated. The DDR may have a
different density/speed. Maybe that can be a hook, along with the PLL setting
possibly.
- David
Index: tcl/target/ar71xx.cfg
===
--- tcl/target/ar71xx.cfg (revision 2663)
+++ tcl/target/ar71xx.cfg (working copy)
@@ -13,16 +13,17 @@
set TARGETNAME [format %s.cpu $CHIPNAME]
target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
-$TARGETNAME configure -event reset-init {
+$TARGETNAME configure -event reset-halt-post {
#setup PLL to lowest common denominator 300/300/150 setting
mww 0xb805 0x000f40a3 # reset val + CPU:3 DDR:3 AHB:0
mww 0xb805 0x800f40a3 # send to PLL
#next command will reset for PLL changes to take effect
mww 0xb8050008 3# set reset_switch and clock_switch
(resets SoC)
- reset halt # let openocd know that it is in the
reset state
+}
- #initialize_pll
+$TARGETNAME configure -event reset-init {
+ #complete pll initialization
mww 0xb805 0x800f0080 # set sw_update bit
mww 0xb8050008 0# clear reset_switch bit
mww 0xb805 0x800f00e8 # clr pwrdwn bypass
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Need help: nothing works
Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped working :( When I start openocd (0.2, Linux, FTD2232) I get: Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release [...] 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : device: 4 Info : deviceID: 67354056 Info : SerialNumber: TLRYVQOW A Info : Description: Turtelizer JTAG/RS232 Adapter A Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched = I checked and the device code is exactly the same for both chips! Using telnet, if I display memory I get: mdw 0 8 0x: 2010 0021 000d 0029 0045 0045 0045 mdw 2000 8 AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0x1312d04 AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0x1312d04 Block read error address 0x1312d00, count 0x8 Runtime error, file command.c, line 469: Thanks for any help, Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need help: nothing works
Alain Mouette wrote: Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped working :( When I start openocd (0.2, Linux, FTD2232) I get: Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release [...] 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : device: 4 Info : deviceID: 67354056 Info : SerialNumber: TLRYVQOW A Info : Description: Turtelizer JTAG/RS232 Adapter A Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched = I checked and the device code is exactly the same for both chips! Using telnet, if I display memory I get: mdw 0 8 0x: 2010 0021 000d 0029 0045 0045 0045 mdw 2000 8 Maybe it should be (hexadecimal) mdw 0x2000 8 Sticky errors is almost always trying to acces nonéxisting memory. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FASTDATA bulk write optimization for mips_m4k file transfers
On Thursday 03 September 2009, David Claffey wrote: Reset to latch PLL settings? Odd. One would expect a reset to re-initialize the PLL configuration too! That's how it's done on every other core I've had occasion to look at. Such odd requirements rate a comment. :) yes, it's odd. The plls are only reset by power-on reset, not SRST. They come up with all the multipliers and dividers set to 1. Changes to the PLL registers are only latched when the reset-switch is set in software, which causes Is that software-triggered reset different from SRST? If so, how? a full CPU reset says the data sheet. And not peripherals ... or does it say? Vendors seem not to make it easy to trigger a full SoC reset from software, short of maybe forcing a watchdog to fire. What do boot loaders normally do with PLL setup then? Sounds like they look at the settings, and if they're not appropriate they'll fix them and reset. Wouldn't OpenOCD do the same? The boot loader checks to see if the PLL is in the appropriate state. If so, it skips the initialization. The appropriate value is either a user-specific value or defaults to a value selected by a speed-step register in the core. So a better solution for OpenOCD might have your reset-halt-post script do the same thing: read that register, and update it only if the PLL settings are still at the default. That way you won't be pessimizing the timings each time you boot; the normal boot code can provide the right ones for the board. The reset sequence is a bit quirky IMO, and not yet up to some things that it needs to handle. There are a lot of flavors of reset, many ways to trigger them, and special cases everywhere. There are event hooks for reset-assert-pre and reset-deassert-post logic ... the reset-init is *way* late. Are you sure reset-init is the right hook to use for PLL setup on this core? (src/helper/startup.tcl has an ocd_process_reset script which you might not have come across ... showing the current set of reset events and their invocation sequence.) I see your point. The config script was calling into reset recursively through the event handler. I tried a few variations on the idea that the sequence is in two steps: first program the pll registers is some event before reset-init, then complete the rest in reset-init. I kept getting target not halted errors until I put the pll setup in a reset-halt-post handler. I'm guessing the target needs to be halted to send the commands. Or at least, it's coded that way. :) There are cores that work either way. Of course, if you write to memory or peripheral registers while the CPU is running, and the code running there isn't prepared for that ... there can be SMP-ish bugs. The PLL settings are intentionally set to a lowest common value for all boards. If PLL and DDR settings are board-specific I think you just said there that they wouldn't normally be the same ... but that there could be a least-common-denominator applied in some cases. Does this core do the usual, and (a) require PLL to get clocks fast enough to run DDR, (b) include some SRAM for boot code to use before DDR is available? If so, it seems reset-assert-pre might benefit from knowing it's prepping for reset-init (and thus should setup the PLL if it's not already done, before one of the resets) vs not (leaving that for the boot loader). There is no SRAM. Boot code sets up the PLL and DDR in assembly before any RAM is used (no stack access). So I'd guess it supports boot-from-ROM and boot-from-NOR, but not boot-from-NAND or from other peripherals. At least in terms of the very first stage of booting. Maybe OneNand works too. then it is my understanding that entire reset-init script should be removed from the target script. That's my general assumption, yes. There could be reusable code that provides hooks for board-specific behavior ... but the reset-init script is doing a lot of what first stage of a boot loader does, and that's *extremely* board-specific. These chips have pin/ball configuration, yes? And have clock trees to set up? And other stuff that varies based on how the chip is wired into a particular board? For this SoC most of the board is in the silicon except for one x16 DDR chip, one SPI flash and the PCI bus. It's highly integrated. The DDR may have a different density/speed. Maybe that can be a hook, along with the PLL setting possibly. Hmm, interesting. Your attached patch does look like a good improvement. Gets rid of that nasty recursion. :) A next step would probably be splitting out the PB44 ref board assumptions from the core AR71xx support. Also: the variable you should set is $_TARGETNAME, leading underscore. And don't use [format %s.cpu $CHIPNAME] to set it; just set _TARGETNAME $CHIPNAME.cpu suffices. The users's guide covers the interop guidelines. -
[Openocd-development] [patch] set _TARGETNAME ... cleanup
Cosmetic cleanup to config files: don't use
[format %s.cpu $_CHIPNAME]
since it's gratuitously complex; use $_CHIPNAME.cpu instead.
---
tcl/target/aduc702x.cfg |2 +-
tcl/target/at91eb40a.cfg |2 +-
tcl/target/at91r40008.cfg|3 ++-
tcl/target/at91sam3uXX.cfg |2 +-
tcl/target/at91sam7sx.cfg|2 +-
tcl/target/at91sam9260.cfg |2 +-
tcl/target/at91sam9260_ext_RAM_ext_flash.cfg |2 +-
tcl/target/c100.cfg |2 +-
tcl/target/cs351x.cfg|3 ++-
tcl/target/epc9301.cfg |2 +-
tcl/target/feroceon.cfg |3 ++-
tcl/target/imx21.cfg |2 +-
tcl/target/imx27.cfg |2 +-
tcl/target/imx31.cfg |2 +-
tcl/target/imx35.cfg |2 +-
tcl/target/is5114.cfg|2 +-
tcl/target/ixp42x.cfg|2 +-
tcl/target/lpc1768.cfg |2 +-
tcl/target/lpc2103.cfg |3 +--
tcl/target/lpc2124.cfg |2 +-
tcl/target/lpc2129.cfg |2 +-
tcl/target/lpc2148.cfg |3 +--
tcl/target/lpc2294.cfg |2 +-
tcl/target/lpc2378.cfg |2 +-
tcl/target/lpc2478.cfg |2 +-
tcl/target/mega128.cfg |2 +-
tcl/target/netx500.cfg |2 +-
tcl/target/pic32mx.cfg |2 +-
tcl/target/pxa270.cfg|2 +-
tcl/target/sam7se512.cfg |2 +-
tcl/target/sam7x256.cfg |4 ++--
tcl/target/samsung_s3c2410.cfg |2 +-
tcl/target/samsung_s3c2440.cfg |3 ++-
tcl/target/samsung_s3c2450.cfg |3 +--
tcl/target/samsung_s3c4510.cfg |2 +-
tcl/target/samsung_s3c6410.cfg |2 +-
tcl/target/sharp_lh79532.cfg |2 +-
tcl/target/smp8634.cfg |2 +-
tcl/target/stm32.cfg |2 +-
tcl/target/str710.cfg|3 ++-
tcl/target/str730.cfg|3 ++-
tcl/target/str750.cfg|2 +-
tcl/target/str912.cfg|2 +-
tcl/target/test_reset_syntax_error.cfg |2 +-
tcl/target/xba_revA3.cfg |3 ++-
45 files changed, 53 insertions(+), 49 deletions(-)
--- a/tcl/target/aduc702x.cfg
+++ b/tcl/target/aduc702x.cfg
@@ -36,7 +36,7 @@ jtag newtap $_CHIPNAME cpu -irlen 4 -irc
##
## Target configuration
##
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME
# allocate the entire SRAM as working area
--- a/tcl/target/at91eb40a.cfg
+++ b/tcl/target/at91eb40a.cfg
@@ -34,7 +34,7 @@ reset_config srst_only srst_pulls_trst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
#target configuration
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi-s_r4
# speed up memory downloads
--- a/tcl/target/at91r40008.cfg
+++ b/tcl/target/at91r40008.cfg
@@ -28,7 +28,8 @@ reset_config srst_only srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
+
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
--- a/tcl/target/at91sam3uXX.cfg
+++ b/tcl/target/at91sam3uXX.cfg
@@ -29,7 +29,7 @@ if { [info exists CPUTAPID ] } {
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME
# 16K is plenty, the smallest chip has this much
--- a/tcl/target/at91sam7sx.cfg
+++ b/tcl/target/at91sam7sx.cfg
@@ -21,7 +21,7 @@ if { [info exists CPUTAPID ] } {
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-set _TARGETNAME [format %s.cpu $_CHIPNAME]
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
$_TARGETNAME configure -event reset-init {
--- a/tcl/target/at91sam9260.cfg
+++ b/tcl/target/at91sam9260.cfg
@@ -35,7 +35,7 @@ jtag_rclk 3
# Target configuration
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
