[Openocd-development] [PATCH] main: invoke jtag_interface_quit() explicitly

2009-11-30 Thread Øyvind Harboe
There is no particular reason to invoke jtag_interface_quit() on the atexit() handler, it just makes the code more obtuse and stops other legitimate usage of atexit(). Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- src/openocd.c |7 +-- 1 files changed, 1 insertions(+), 6

[Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread Øyvind Harboe
Whether or not vsnprintf() allows NULL as pointer to destination string to calculate length depends on the implementation. Revert more efficient, but non-portable implementation. This reverts commit 338a674faa96ae321560efa3f1b1e8122d61aac4. --- src/helper/log.c | 43

[Openocd-development] startup.tcl should be shipped as plaintext

2009-11-30 Thread Øyvind Harboe
The error messages in embedded:startup.tcl refer to line numbers. It would be good to distribute startup.tcl for reference, even if it is not required. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex

Re: [Openocd-development] arm11 srst behavior

2009-11-30 Thread Øyvind Harboe
imx31pdk.cfg test results... I believe the problem with iMX31 is that it misbehaves after receiving a TAP reset... Without patch: reset halt JTAG tap: imx31.etb tap/device found: 0x2b900f0f (mfg: 0x787, part: 0xb900, ver: 0x2) JTAG tap: imx31.cpu tap/device found: 0x07b3601d (mfg: 0x00e,

Re: [Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread Zach Welch
Do not apply. The old implementation was total crap, and your vsnprintf implementation must be too. That's not our problem, and it can be worked around without destroying the improvements for others. Use a single 'char' on the stack. One character should be enough. --Z On Mon, 2009-11-30 at

Re: [Openocd-development] startup.tcl should be shipped as plaintext

2009-11-30 Thread Zach Welch
On Mon, 2009-11-30 at 10:21 +0100, Øyvind Harboe wrote: The error messages in embedded:startup.tcl refer to line numbers. It would be good to distribute startup.tcl for reference, even if it is not required. If the user can't look in the source code, then they need to report the bug to

Re: [Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread Zach Welch
The proper solution: tell the maintainers of your vsnprintf to improve their implementation! ;) --Z On Mon, 2009-11-30 at 02:20 -0800, Zach Welch wrote: Do not apply. The old implementation was total crap, and your vsnprintf implementation must be too. That's not our problem, and it can be

[Openocd-development] [PATCH 1/4] add 'module' helper module

2009-11-30 Thread Zachary T Welch
Adds a fully-documented API for dynamically loading libraries and looking up symbols or addresses in them. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/helper/Makefile.am |2 + src/helper/module.c| 96

[Openocd-development] [PATCH 3/4] add -rdynamic to CFLAGS

2009-11-30 Thread Zachary T Welch
The -rdynamic flag provides the information required to produce more meaningful stack traces. Signed-off-by: Zachary T Welch z...@superlucidity.net --- configure.in |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.in b/configure.in index 81e4326..224e1b3 100644

[Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-11-30 Thread Zachary T Welch
Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Adds the 'stack' helper module with generic stack trace routines that can be used to implement better debugging messages. Signed-off-by: Zachary T Welch z...@superlucidity.net ---

[Openocd-development] [PATCH 4/4] add 'stack' command handler

2009-11-30 Thread Zachary T Welch
The new 'stack' command displays the openocd C stack from TCL as a debugging aid. Takes an optional parameter: the depth of the stack or 'fault' (which creates an immediate segfault by dereferencing a bad pointer). This demonstrates the new segfault handling nicely. Signed-off-by: Zachary T

Re: [Openocd-development] [PATCH 0/4] add stack backtracing

2009-11-30 Thread Zach Welch
On Mon, 2009-11-30 at 03:04 -0800, Zachary T Welch wrote: Hi all, This series creates two new helper APIs: 'module' and 'stack'. It applies on top of my outstanding patches; pull from repo.or.cz. FWIW, I have pushed a revised version of these to my mirror to include proper copyright blurbs

Re: [Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread Øyvind Harboe
On Mon, Nov 30, 2009 at 11:28 AM, Zach Welch z...@superlucidity.net wrote: The proper solution: tell the maintainers of your vsnprintf to improve their implementation! ;) --Z Actually it turns out eCos does offer a C99 compliant vsnprintf now, it just isn't enabled by default. This fix in eCos

[Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Øyvind Harboe
Those few targets that have problems with fast_memory_access or dcc_downloads must add event handlers to the reset sequence to deal with this. The typical example are CPUs that run at kHz clocks. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- doc/openocd.texi | 15

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Øyvind Harboe wrote:  doc/openocd.texi           |   15 ++- You should also update the chapter on config files to include a @quotation Warning ... @quotation that these (may?) need to be disabled during slow clock operations, like early boot with a 32

Re: [Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Øyvind Harboe wrote: eCos does not have C99 support, which is kinda annoying, but not totally unexpected for deeply embedded systems. Could you elaborate on what's missing? I'm guessing some aspects of the runtime support. Clearly not all the language parsing

Re: [Openocd-development] startup.tcl should be shipped as plaintext

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Øyvind Harboe wrote: The error messages in embedded:startup.tcl refer to line numbers. It would be good to distribute startup.tcl for reference, even if it is not required. And install it where? And then how to cope with complaints of the I changed this, and it

[Openocd-development] Flashing DM355 bootloader

2009-11-30 Thread Raúl Sánchez Siles
Hello All: I'm playing with a DM355 based board, and I'm trying to flash the bootloader into its NAND flash. NAND flash is a 256MB with 2048 blocks, each block 64 pages and each page 2048+64bytes. Those chips provide an internal ROM bootloader which, among other things, should start the

Re: [Openocd-development] Flashing DM355 bootloader

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Raúl Sánchez Siles wrote:   My question is which one of those should be used to flash the first bootloader on that cards?   · Use hwecc4_infix driver mode for davinci   · Use oob_softecc flag when writing to nand   · Use oob_softecc_kw flag when writing to nand  

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Zach Welch
I think David has explained why this is not a good idea for a default. It is not always safe and presents an option that would need to be disabled when bringing up new boards. Bring-up is hard enough without having to fight the tools from trying to be smarter than they are. On Mon, 2009-11-30 at

Re: [Openocd-development] startup.tcl should be shipped as plaintext

2009-11-30 Thread Øyvind Harboe
On Mon, Nov 30, 2009 at 11:23 AM, Zach Welch z...@superlucidity.net wrote: On Mon, 2009-11-30 at 10:21 +0100, Øyvind Harboe wrote: The error messages in embedded:startup.tcl refer to line numbers. It would be good to distribute startup.tcl for reference, even if it is not required. If the

Re: [Openocd-development] [PATCH] Revert improve alloc_vprintf

2009-11-30 Thread Øyvind Harboe
On Mon, Nov 30, 2009 at 6:04 PM, David Brownell davi...@pacbell.net wrote: On Monday 30 November 2009, Ųyvind Harboe wrote: eCos does not have C99 support, which is kinda annoying, but not totally unexpected for deeply embedded systems. Could you elaborate on what's missing?  I'm guessing

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Øyvind Harboe
How about a different attack on this problem: add a defualt post reset handler that checks that all the good options are enabled and prints out a warning otherwise. This could serve as a todo list for things missing from a well formed reset init script. If DCC fast_memory_access is not enabled

[Openocd-development] FT4232H support

2009-11-30 Thread Austin, Alex
Hello, I've built a JTAG adapter (Very similar to oocdlink-h) using the FT4232H instead of the FT2232H. Due to the lack of ACBUS on the 4232, I've routed the reset lines to the same pins on BDBUS. CDBUS and DDBUS both go to serial ports. What would be the best way to support that? Should I

[Openocd-development] [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

2009-11-30 Thread Marek Vasut
Hi, patch is attached, please consider applying. The pxa3xx uses different BYPASS instruction (0x7ff) than pxa2xx and ixp4xx, which use 0x7f. Signed-off-by: Marek Vasut marek.va...@gmail.com From 9c99c68059b213db828bcba73b512a980dc782d4 Mon Sep 17 00:00:00 2001 From: Marek Vasut

Re: [Openocd-development] [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

2009-11-30 Thread Marek Vasut
Dne Út 1. prosince 2009 01:17:57 Marek Vasut napsal(a): Hi, patch is attached, please consider applying. The pxa3xx uses different BYPASS instruction (0x7ff) than pxa2xx and ixp4xx, which use 0x7f. Signed-off-by: Marek Vasut marek.va...@gmail.com Argh, the following patch doesn't have a

Re: [Openocd-development] [PATCH 0/3] deferred 'init' and leaner 'help'

2009-11-30 Thread Zach Welch
On Sun, 2009-11-29 at 14:33 -0800, Zachary T Welch wrote: Hi all, These patches clean up the server and system startup. The first patch factors the GDB server setup to be more conducive to deferred initialization of targets (in a later series). The second provides the 'noinit' command

Re: [Openocd-development] [PUSHED 0/4] minor cleaning and audit

2009-11-30 Thread Zach Welch
On Sun, 2009-11-29 at 19:00 -0800, Zachary T Welch wrote: Hi all, This series includes only minor changes. Applies on top of the last series to allow deferred 'init'. Share and Enjoy, --Z ___ Openocd-development mailing list

Re: [Openocd-development] [PUSHED 0/5] remove interp global variable

2009-11-30 Thread Zach Welch
On Sun, 2009-11-29 at 19:03 -0800, Zachary T Welch wrote: Hi all, This series removes the 'interp' global variable from the system, bringing us a step closer to supporting several active command contexts. Share and Enjoy, --Z ___

[Openocd-development] [patch 1/2] XScale: context restore, cleanup/bugfix

2009-11-30 Thread David Brownell
This loop over all registers routine shared the same mess as full_context() in terms of dozens of needless number_to_mode() calls. Fix that, and comments, with related cleanup. The misnamed xscale_restore_context() had a related bug. It was restoring the *WRONG REGISTERS* ... always from

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Zachary T Welch wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather just expect folk to run inside GDB. Either they're running natively and should never see SEGV

Re: [Openocd-development] [PATCH 1/4] add 'module' helper module

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Zachary T Welch wrote: Adds a fully-documented API for dynamically loading libraries and looking up symbols or addresses in them. Seems to me I've seen one or two or three or four of these before ... must there be another?? I know that portability of such things to

[Openocd-development] [patch 2/2] XScale: restore_context() cleanup

2009-11-30 Thread David Brownell
Clean up two aspects to this routine: bad naming, since it doesn't restore the context, just the banked registers; and excess indentation for the bulk of the code. Also make some of its call sites stash the function's return code; someday they should use it for error checking. ---

Re: [Openocd-development] [PATCH] Supply 11-bit BYPASS instruction for PXA3xx

2009-11-30 Thread David Brownell
On Monday 30 November 2009, Marek Vasut wrote: Hi, patch is attached, please consider applying. The pxa3xx uses different BYPASS instruction (0x7ff) than pxa2xx and ixp4xx, which use 0x7f. Can you try a simpler patch, and just pass ~0 (all ones) instead of the constant 0x7f? I'd expect that

[Openocd-development] [patch 0/5] arm11/cortex-a8 coprocessor cleanup

2009-11-30 Thread David Brownell
Now that we have this DPM component, it can (and IMO should!) handle more of the cases where the ARMv6 and ARMv7 code have needlessly unique implementations. This patch addresses coprocessor stuff: - stop using read_cp15/write_cp15 methods in * armv7a.c * cortex_a8.c - add and

[Openocd-development] [patch 4/5] ARM11: remove previous mcr()/mrc() methods

2009-11-30 Thread David Brownell
We don't need this code, now that the DPM code handles it. --- src/target/arm11.c | 68 --- 1 file changed, 68 deletions(-) --- a/src/target/arm11.c +++ b/src/target/arm11.c @@ -1510,71 +1510,6 @@ COMMAND_HANDLER(arm11_handle_vcr) return

[Openocd-development] [patch 3/5] ARM: implement mrc()/mcr() as DPM ops

2009-11-30 Thread David Brownell
Instead of having separate ARM11 and Cortex-A8 implementations of this code, have one shared implementation which just builds on the existing run instruction via R0 support. This enables followup patches to remove that now-unused code from those two drivers. (Patches to move the mrc and mcr code

[Openocd-development] [patch 2/5] ARMv7-A: stop using CP15 ops

2009-11-30 Thread David Brownell
The ARMv7-A code uses read_cp15() to access fault registers. Instead, use DPM operations directly, passing in the relevant MRC instructions. This eliminates some per-operation overhead (though it'll be hard to observe, this is uncommon) and helps eliminate read_cp15(). --- src/target/armv7a.c |

[Openocd-development] [patch 5/5] Cortex-A8: remove previous mcr()/mrc() methods

2009-11-30 Thread David Brownell
We don't need this code, now that the DPM code handles it. Neither do we need the ARMv7-A CP15 operations; remove their remnants too. And disable a mostly-needless diagnostic. --- src/target/armv7a.h|7 --- src/target/cortex_a8.c | 97 --- 2

[Openocd-development] [patch 1/5] Cortex-A8: stop using CP15 ops

2009-11-30 Thread David Brownell
There were two chunks of Cortex-A8 code which called the ARMv7-A CP15 operations; get rid of them, helping prepare to remove those methods completely: - post_debug_entry() can use the mrc() method to read its two registers. - write_memory() can use dpm-instr_write_data_r0() to flush the

Re: [Openocd-development] [PATCH 1/4] add 'module' helper module

2009-11-30 Thread Zach Welch
On Mon, 2009-11-30 at 14:38 -0800, David Brownell wrote: On Monday 30 November 2009, Zachary T Welch wrote: Adds a fully-documented API for dynamically loading libraries and looking up symbols or addresses in them. Seems to me I've seen one or two or three or four of these before ... must

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-11-30 Thread Zach Welch
On Mon, 2009-11-30 at 14:42 -0800, David Brownell wrote: On Monday 30 November 2009, Zachary T Welch wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather just expect folk to run inside

Re: [Openocd-development] [patch 5/5] Cortex-A8: remove previous mcr()/mrc() methods

2009-11-30 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 3:59 AM, David Brownell davi...@pacbell.net wrote: We don't need this code, now that the DPM code handles it. Neither do we need the ARMv7-A CP15 operations; remove their remnants too.  And disable a mostly-needless diagnostic. What about reset init scripts. Will they

Re: [Openocd-development] [patch 5/5] Cortex-A8: remove previous mcr()/mrc() methods

2009-11-30 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 7:55 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Tue, Dec 1, 2009 at 3:59 AM, David Brownell davi...@pacbell.net wrote: We don't need this code, now that the DPM code handles it. Neither do we need the ARMv7-A CP15 operations; remove their remnants too.  And

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Øyvind Harboe
On Mon, Nov 30, 2009 at 10:19 PM, Zach Welch z...@superlucidity.net wrote: I think David has explained why this is not a good idea for a default. It is not always safe and presents an option that would need to be disabled when bringing up new boards.  Bring-up is hard enough without having to

Re: [Openocd-development] [patch 3/5] ARM: implement mrc()/mcr() as DPM ops

2009-11-30 Thread David Brownell
On Monday 30 November 2009, David Brownell wrote:  (Patches to move the mrc and mcr code into struct arm are due too ... MIPS and other cores do not support those ARM-specific concepts.) Needed for testing, even ... here it is. Goes before slightly tweaked versions of the last few patches.

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Zach Welch
On Tue, 2009-12-01 at 08:08 +0100, Øyvind Harboe wrote: On Mon, Nov 30, 2009 at 10:19 PM, Zach Welch z...@superlucidity.net wrote: I think David has explained why this is not a good idea for a default. It is not always safe and presents an option that would need to be disabled when bringing

[Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-11-30 Thread Øyvind Harboe
In embedded hosts, the Jim interpreter can come from the existing context rather than be created by OpenOCD. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- src/helper/command.c | 18 +++--- src/helper/command.h |6 -- src/openocd.c|6 +++--- 3 files

[Openocd-development] [PATCH 2/3] zy1000: keep up with latest changes to command handling

2009-11-30 Thread Øyvind Harboe
Keep up with Jim Tcl interpreter creation cleanup. Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com --- src/ecosboard.c | 10 -- src/jtag/zy1000/zy1000.c |2 +- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/src/ecosboard.c b/src/ecosboard.c index

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-11-30 Thread Øyvind Harboe
How about a warning when it's _not_ explicitly enabled or disabled by the user?  Specifically, tell the users to try enabling those features or to add explicit commands to stop the warnings.  Scripts for boards where that feature will be safe by default could add the required commands, and

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-11-30 Thread Øyvind Harboe
There is no third patch for this series, I just left out an unsuitable patch and I guess I should have used different args to git format patch to make it a series of two patches. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7

Re: [Openocd-development] [patch 3/5] ARM: implement mrc()/mcr() as DPM ops

2009-11-30 Thread Zach Welch
On Mon, 2009-11-30 at 23:42 -0800, David Brownell wrote: On Monday 30 November 2009, David Brownell wrote: (Patches to move the mrc and mcr code into struct arm are due too ... MIPS and other cores do not support those ARM-specific concepts.) Needed for testing, even ... here it is.