Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread luca ellero
On 26/04/2011 23.08, Øyvind Harboe wrote: The problem is that the ft2232_init() fn will invoke jtag_xxx() fn's. However, until ft2232_init() returns, the interface is not set up and that part of the API is not "open for business", causing strange effects. ft2232_init() sets up a "default speed"

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Laurent Gauch
I've noticed strange behaviour in initialization with TI OMAP4430 and Freescale iMX53 using Amontec JTAGKEY. Even typing keys on OpenOCD shell was very very slow. I didn't investigate too much the causes. Anyway this patch fix it. Signed-off-by: Luca Ellero https://lists.berlios.de/mailman/listin

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Øyvind Harboe
> Hi Øyvind, > thanks for the explanation. > So, what is the suggested usage? Maybe using jtag_khz or adapter_khz in > configuration files? I'm thinking we should do a patch as follows: - add a call set jtag speed to 100khz after ->init() is invoked successfully. This means *all* interfaces behav

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Tomek CEDRO
On Wed, Apr 27, 2011 at 9:43 AM, Øyvind Harboe wrote: > Scripts would be encouraged by the default low speed to have > an adapter_khz command to set a more approperiate default > for that board. > > Further down the road, I was thinking about modifying OpenOCD > to have *no* default speed and have

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Michael Schwingen
Am 04/27/2011 11:50 AM, schrieb Tomek CEDRO: > Hello :-) I think default-low-speed is safer choice for unaware users > or developers simply reading out idcode.. also it can be easily > changed into something more device specific to gain better performance > :-) Hi, this brings us back to the quest

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Øyvind Harboe
On Wed, Apr 27, 2011 at 12:02 PM, Michael Schwingen wrote: > Am 04/27/2011 11:50 AM, schrieb Tomek CEDRO: >> Hello :-) I think default-low-speed is safer choice for unaware users >> or developers simply reading out idcode.. also it can be easily >> changed into something more device specific to ga

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Tomek CEDRO
On Wed, Apr 27, 2011 at 10:08 AM, Øyvind Harboe wrote: > (...) >> So I think having no default and forcing the user to specify a value >> might be the way to go. > > Agreed. If we could have that patch first and not go the detour of > a fixed default across all interfaces, then that would be > my

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Jonas Hoerberg
On Wed, Apr 27, 2011 at 10:08 AM, Øyvind Harboe wrote: > > On Wed, Apr 27, 2011 at 12:02 PM, Michael Schwingen > wrote: > > Am 04/27/2011 11:50 AM, schrieb Tomek CEDRO: > >> Hello :-) I think default-low-speed is safer choice for unaware users > >> or developers simply reading out idcode.. also

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Øyvind Harboe
> Hi, > > I created such a patch a while ago. > See > https://lists.berlios.de/pipermail/openocd-development/2010-December/017469.html I like it. It needs to invoke the call to set the speed on the driver after the interface is initialized and the jtag_get/set calls from driver _init() code sho

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Laurent Gauch
I'm not looking for something that works in all circumstances. I just want it to be the *same* across all interfaces. The correct long term solution would be to have *no* default speed and just put up an error message if the script doesn't specify it. IMHO. For me the correct is : 1. -init- fix

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Laurent Gauch
>/ I'm not looking for something that works in all circumstances. I just />/ want it to be the *same* across all interfaces. />/ />/ The correct long term solution would be to have *no* default speed />/ and just put up an error message if the script doesn't specify it. />/ IMHO. /For me the corr

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

2011-04-27 Thread Jonas Hoerberg
On Wednesday, April 27, 2011 12:58 PM, Øyvind Harboe [mailto:oyvind.har...@zylin.com] wrote: > > > Hi, > > > > I created such a patch a while ago. > > See > > https://lists.berlios.de/pipermail/openocd-development/2010- > December/0 > > 17469.html > > I like it. > > It needs to invoke the call t

Re: [Openocd-development] How to let the cortex a8 enter debug mode ? Ican't halt it

2011-04-27 Thread dswei
I use the debugger from ARM, it can find the cortex-a9 and halt it: info: AHB-AP at AP index 0 has no ROM table. info: Reading ROM table for APB-AP at AP index 1 :- info: ROM table base address = 0x8000 info: Reading device registers at address 0x80002000 info: Identified component CSCTI (id=

[Openocd-development] help with config for Seagate DockStar please

2011-04-27 Thread Eric Cooper
I'm a JTAG newbie and could use some help configuring openocd for use with a Seagate DockStar, a Marvell Kirkwood (feroceon) board similar to the Sheevaplug. The setup "mostly" works: I can halt, resume, and single-step the target reliably from the openocd telnet client. I can load images into RA

Re: [Openocd-development] help with config for Seagate DockStar please

2011-04-27 Thread Mike Dunn
On 04/27/2011 09:42 AM, Eric Cooper wrote: > I'm a JTAG newbie and could use some help configuring openocd for use > with a Seagate DockStar, a Marvell Kirkwood (feroceon) board similar > to the Sheevaplug. > > The setup "mostly" works: I can halt, resume, and single-step the > target reliably from

[Openocd-development] Fix crash / exit() in cfi

2011-04-27 Thread Øyvind Harboe
Any objections? -- Ø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 From 36d60ee6c8d3aa1865dac2378c481954ba402910 Mon Sep 17 00:

Re: [Openocd-development] help with config for Seagate DockStar please

2011-04-27 Thread Eric Cooper
On Wed, Apr 27, 2011 at 12:12:12PM -0700, Mike Dunn wrote: > On 04/27/2011 09:42 AM, Eric Cooper wrote: > > 1. In gdb, I can step and continue, but I can't halt. Once I've > > continued, typing ^C does nothing. (Typing it a second time just > > makes gdb offer to quit.) I can still halt from the

Re: [Openocd-development] help with config for Seagate DockStar please

2011-04-27 Thread Mike Dunn
On 04/27/2011 03:12 PM, Eric Cooper wrote: > > I'm using: > GNU gdb (Sourcery G++ Lite 2010q1-188) 7.0.50.20100218-cvs > >> BTW, be careful using openocd through telnet while gdb is connected. Openocd >> assumes exclusive use of one or the other, and does things like clear all >> existing brea