Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.
Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.
Add entry to NEWS as well.
Signed
On Sun, Nov 22, 2009 at 2:05 AM, Zach Welch wrote:
> On Sun, 2009-11-22 at 01:56 +0100, Andreas Fritiofson wrote:
>> On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch wrote:
>> > Checkout your branch and run 'git rebase master'. That will update your
>> > branch against the current master. Then, do t
On Sun, 2009-11-22 at 01:56 +0100, Andreas Fritiofson wrote:
> On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch wrote:
> > Checkout your branch and run 'git rebase master'. That will update your
> > branch against the current master. Then, do the same thing with '-i'.
> > Select the patches to change
On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch wrote:
> Checkout your branch and run 'git rebase master'. That will update your
> branch against the current master. Then, do the same thing with '-i'.
> Select the patches to change and mark them with 'e', change the files,
> add them and --amend the
Hi,
Øyvind Harboe wrote:
>
> Could you include a debug_level 3 trace?
>
> The conclusion seems a bit premature based on the limited information
> above.
>
>
Maybe the following example (output is pasted below) can illustrate the issue a
bit better. First I try to flash a 20KB block, then a
On Saturday 21 November 2009, Zach Welch wrote:
>
> > Could we get one less level of indent throughout?
>
> There a couple of arguments for using this style at the top-level:
> - It's consistent with the other indenting. The statement has not been
> completed, so the code should not return to th
On Sun, 2009-11-22 at 00:52 +0100, Andreas Fritiofson wrote:
> On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe
> wrote:
> > On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch wrote:
> >>
> >> PATH_MAX should be defined and available (in ). Use it.
> >
> > Why not just allocate dynamically and avoid the
On Sat, 2009-11-21 at 16:24 -0700, David Brownell wrote:
> On Saturday 21 November 2009, Zachary T Welch wrote:
> > +static const struct command_registration at91rm9200_command_handlers[] = {
> > + {
> > + .name = "at91rm9200_device",
> > +
On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe wrote:
> On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch wrote:
>>
>> PATH_MAX should be defined and available (in ). Use it.
>
> Why not just allocate dynamically and avoid the problem at the root?
>
That sounds like the best solution, I'll prepare an
On Saturday 21 November 2009, Zachary T Welch wrote:
> +static const struct command_registration at91rm9200_command_handlers[] = {
> + {
> + .name = "at91rm9200_device",
> + .handler = &at91rm9200_handle_device_command,
> +
On Thu, Nov 19, 2009 at 11:46 PM, Johnny Halfmoon
wrote:
> Hiya,
>
> I've found a few issues in OpenOCD and thought that I'd share before hacking
> a solution together. The following revision is used:
>
> commit 8f446fcf676e9cd13cf53d9946f0cae5d29a10ec
> Date: Thu Nov 19 13:23:49 2009 -0800
>
>
Stash a pointer to the CPSR in the "struct arm", to help get rid
of the (common) references to its index in the register cache.
This removes almost all references to CPSR offsets outside of the
toplevel ARM code ... except a pair related to the current ARM11
"simulator" logic (which should be remo
Start using the arm_reg_current() call. This shrinks and speeds
the affected code. It can also prevent some coredumps coming from
invalid CPSR values ... the ARMV4_5_CORE_REG_MODE() macro returns
bogus registers if e.g. "Secure Monitor" mode isn't supported by
the current CPU.
---
Not fully tweak
Have arm_set_cpsr() handle the two core state flags, updating
the CPU state. This eliminates code in various debug_entry()
paths, and marginally improves handling of the J bit.
Catch and comment a few holes in the handling of the J bit on
ARM926ejs cores ... it's unlikely our users will care abou
Define arm_reg_current() ... returning handle to a given register,
and encapsulating the current mode's register shadowing. It's got
one current use, for reporting the current register set to GDB.
This will let later patches clean up much ARMV4_5_CORE_REG_MODE()
nastiness, saving a bit of code.
D
Minor cleanup of ARM11 register handling: remove disabled
register hooks. This should all be handled by shared code,
and this stuff is just clutter.
---
src/target/arm11.c | 89 ---
src/target/arm11.h |7 +---
2 files changed, 3 insertions(+)
I'm trying to get rid of most "I know how the register cache
is laid out" knowledge, and eventually to make the ARM11 code
use the standard register framework. These are stepping stones
along that path.
- ARM11: remove useless #defines
- simplify CPSR access
- define set_cpsr() and a mapping u
On Sat, 2009-11-21 at 21:31 +0100, Øyvind Harboe wrote:
> Why is a table better than a fn call for registering commands?
It's harder to screw up with the new way of doing things, as the
registration parameters are more explicit. It also eliminates a lot of
redundant calls to register_command{,s}
Why is a table better than a fn call for registering commands?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.d
On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch wrote:
> On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
>> Add $HOME/.openocd as the first default script search directory, allowing
>> the user to override the standard scripts.
>
> Comments are in-line and at the end.
>
>> Signed-off-by:
Andreas Fritiofson wrote:
> This series improves the default script search path to include $HOME/.openocd.
>
Good idea.
I proposed that a long time ago, but it was rejected back then for
forgotten reasons - which is why I use a wrapper script now.
cu
Michael
___
On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch wrote:
> On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
>> Add $HOME/.openocd as the first default script search directory, allowing
>> the user to override the standard scripts.
>
> Comments are in-line and at the end.
>
>> Signed-off-by:
Use register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/presto.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/jtag/presto.c b/src/jtag/presto.c
index f22bd9e..6f5833a 100644
--- a/src/jtag/presto.c
+++ b
Changes the jtag_interface->register_callbacks field to a list of
commands to be registered. Changes callback to invocation of
register_commands() with that command registration list. Removes all
JTAG interface driver register_command callback functions, which the
previous commits had converted i
Use register commands with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 187
1 files changed, 120 insertions(+), 67 deletions(-)
diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index bd672b6..1c80245 10064
Use register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/vsllink.c | 56 +--
1 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/src/jtag/vsllink.c b/src/jtag/vsllink.c
index 538ae0b..d6a2e
Use register_commands() for top-level version and init command.
Signed-off-by: Zachary T Welch
---
src/openocd.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/openocd.c b/src/openocd.c
index 379373c..4d13611 100644
--- a/src/openocd.c
+++ b
Use register_commands() with a command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/parport.c | 58 ++--
1 files changed, 38 insertions(+), 20 deletions(-)
diff --git a/src/jtag/parport.c b/src/jtag/parport.c
index 4b4df09..cf
Use register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/jlink.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/src/jtag/jlink.c b/src/jtag/jlink.c
index 0f76c9f..200dfe4 100644
--- a/src/jtag/jlink.
Use register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/gw16012.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/jtag/gw16012.c b/src/jtag/gw16012.c
index bc0e472..5118562 100644
--- a/src/jtag/gw16012.c
Use register_commands() with command registration array.
---
This module was broken by previous changes, but no one has complained.
Are there still users for this modules?
Signed-off-by: Zachary T Welch
---
src/jtag/at91rm9200.c | 15 ---
1 files changed, 12 insertions(+), 3 deleti
Uses register_commands() with command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/arm-jtag-ew.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/jtag/arm-jtag-ew.c b/src/jtag/arm-jtag-ew.c
index 82ff2a0..5363ae8 100644
--- a/src/jta
Use register_commands() with a command registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/ft2232.c | 60 +---
1 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/src/jtag/ft2232.c b/src/jtag/ft2232.c
index e560b22..d2024
Hi all,
This series builds upon the last to cleanup the JTAG layer command
handler registration. First, each module gets converted to use
register_commands() with a command registration array. The final patch
converts the jtag_interface structure to contain the registration list
(and its size),
Use register_commands() with command_registration array.
Signed-off-by: Zachary T Welch
---
src/jtag/amt_jtagaccel.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/jtag/amt_jtagaccel.c b/src/jtag/amt_jtagaccel.c
index 0aabdc9..7729714 100
On Sat, 2009-11-21 at 09:36 -0700, David Brownell wrote:
> On Friday 20 November 2009, Zach Welch wrote:
> >
> > > > Also, any reason to hold off on this present series or the USB series?
> > >
> > > These command patches, didn't see a reason.
> >
> > Okay, I've made a few trivial changes to the
On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
> Add $HOME/.openocd as the first default script search directory, allowing
> the user to override the standard scripts.
Comments are in-line and at the end.
> Signed-off-by: Andreas Fritiofson
> ---
> src/helper/options.c | 16
On Saturday 21 November 2009, Andreas Fritiofson wrote:
> + LOG_DEBUG("adding %s", dir);
That one's a no-brainer ... merged. :)
No comment on the other two, except that they need thought
and I'll wait to see the followup (doc etc) especially on
the third one.
__
There are a raft of tricks than can be employed
to improve performance. The ZY1000 does 400kBytes/s
w/arm7/9 @ 16MHz btw, using OpenOCD. The advantage of ZY1000
is low latency, but it has a feeble host CPU. The history of optimizing
the ZY1000 showed significant improvement benefits for
USB dongles
On Saturday 21 November 2009, Duane Ellis wrote:
> It is just blindingly fast...
I suspect that many of those speed improvements can be
had even with a CPU-based solution ... if the CPU is
driving the JTAG interface directly, it can do things
like handshaking in microseconds, not the milliseconds
On Friday 20 November 2009, Zach Welch wrote:
>
> > > Also, any reason to hold off on this present series or the USB series?
> >
> > These command patches, didn't see a reason.
>
> Okay, I've made a few trivial changes to them after working on the
> changes to support proper usage function, but
On Wednesday 18 November 2009, Albert ARIBAUD wrote:
> >> Can someone on the list point me to instructions on how to create
> >> interface, target and board files for this board?
> >
> > Start with the User's Guide; there's a chapter on that stuff.
>
> Thanks. I'd gone through the manual already
Hello,
On Sat, Nov 21, 2009 at 4:42 PM, Duane Ellis wrote:
> Recently, I've been using quite a few commercial jtag tools from chip
> vendors.
>
> One thing I've noticed is that they all have implement the design with
> an small usb-controller + FPGA of some type (typically a xilinx
> spartan). I
How about using a dynamic allocation and not worrying about
max size at all?
These changes seem reasonably to me, but without documentation
to go with it, I fear nobody would use it. Could you add some?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger
Add this to ease debugging why the standard scripts aren't found on the
default script search path in some build/install enviroments. Especially on
Windows it's not straight forward where openocd actually looks for the
scripts.
Signed-off-by: Andreas Fritiofson
---
src/helper/configuration.c |
Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.
Signed-off-by: Andreas Fritiofson
---
src/helper/options.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/src/helper/options.c b/src/help
The default script search path on Windows seems to be out of date with the
current layout, causing the standard scripts not to be found after a
conventional './configure && make && make install' under msys/MinGW. The same
should hold true for cygwin native builds although not verified.
Update the
This series improves the default script search path to include $HOME/.openocd.
It also updates the search path on Windows to match what appears to be the
result of a standard 'configure && make && make install' in one particular
MSYS environment. Other environments have not been tested, but the cur
Øyvind Harboe wrote:
> The important point is that the queuing of JTAG commands
> can be done in hardware today, with no overhead.
>
> We want to keep the actual queue implementation something
> completely internal to the interface implementations.
>
Understood. I still do not see how the propos
Recently, I've been using quite a few commercial jtag tools from chip
vendors.
One thing I've noticed is that they all have implement the design with
an small usb-controller + FPGA of some type (typically a xilinx
spartan). I can see the real benefit, they download and flash the target
at an u
On Sat, Nov 21, 2009 at 2:09 PM, Michael Schwingen
wrote:
> Øyvind Harboe wrote:
>>> 3. Break up jtag_add_dr_scan etc.
>>>
>>> This works best in tandem with (2). The general idea is not to pass
>>> one array of scan fields but to pass them in separate function calls
>>> (which would mimic, but re
Øyvind Harboe wrote:
>> 3. Break up jtag_add_dr_scan etc.
>>
>> This works best in tandem with (2). The general idea is not to pass
>> one array of scan fields but to pass them in separate function calls
>> (which would mimic, but replace the ones in (1)). To output a 7 bit
>> field the caller just
On Fri, Nov 20, 2009 at 10:43 PM, Michael Bruck wrote:
> On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe wrote:
>>> Just to clarify the whole issue once more, my proposal was actually
>>> three different things:
>>>
>>> 1. Making the use of scan_field safer by providing standard handlers
>>> for the
53 matches
Mail list logo
