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 ...
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 ARM
> 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, an
Keep up with Jim Tcl interpreter creation cleanup.
Signed-off-by: Øyvind Harboe
---
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 5588934..36e807e 100644
--- a
In embedded hosts, the Jim interpreter can come from the
existing context rather than be created by OpenOCD.
Signed-off-by: Øyvind Harboe
---
src/helper/command.c | 18 +++---
src/helper/command.h |6 --
src/openocd.c|6 +++---
3 files changed, 18 insertions(+),
On Tue, 2009-12-01 at 08:08 +0100, Øyvind Harboe wrote:
> On Mon, Nov 30, 2009 at 10:19 PM, Zach Welch 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.
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 pa
On Mon, Nov 30, 2009 at 10:19 PM, Zach Welch 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 fight the tools fro
On Tue, Dec 1, 2009 at 7:55 AM, Øyvind Harboe wrote:
> On Tue, Dec 1, 2009 at 3:59 AM, David Brownell 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.
>
On Tue, Dec 1, 2009 at 3:59 AM, David Brownell 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 *never* need the mr
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 in
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 .
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
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 f
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 |
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"
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 E
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 u
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 th
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.
---
src/target/xsc
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
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
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 whate
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-develo
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
Openocd-developmen
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' comm
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
>
Argh, the following patch doesn't have a stupid formating iss
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
From 9c99c68059b213db828bcba73b512a980dc782d4 Mon Sep 17 00:00:00 2001
From: Marek Vasut
Date: Tue, 1 Dec 2009 01:15:21 +0100
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 manua
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
On Mon, Nov 30, 2009 at 6:04 PM, David Brownell 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 some
> aspects o
On Mon, Nov 30, 2009 at 11:23 AM, Zach Welch 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 user can't
On Mon, Nov 30, 2009 at 6:08 PM, David Brownell wrote:
> 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 t
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
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 n
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
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, an
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 aspe
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 KH
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
---
doc/openocd.texi | 15 ++-
src/target/arm7_
On Mon, Nov 30, 2009 at 11:28 AM, Zach Welch 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 is more recent than
m
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 blurb
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 Welc
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
---
src/helper/Makefile.am |2 +
src/
The -rdynamic flag provides the information required to produce
more meaningful stack traces.
Signed-off-by: Zachary T Welch
---
configure.in |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 81e4326..224e1b3 100644
--- a/configure.in
+++
Adds a fully-documented API for dynamically loading libraries and
looking up symbols or addresses in them.
Signed-off-by: Zachary T Welch
---
src/helper/Makefile.am |2 +
src/helper/module.c| 96
src/helper/module.h| 73 +++
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.
The 'module' API provides the ability to perform dynamic library
loading and symbol lookup therein.
The 'stack' API provides the ability to obtain backtraces
Rather, send them a patch to fix it what was I thinking. :)
In any event, don't break OpenOCD's perfectly acceptable code.
On Mon, 2009-11-30 at 02:28 -0800, Zach Welch wrote:
> The proper solution: tell the maintainers of your vsnprintf to improve
> their implementation! ;) --Z
>
> On Mon,
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
>
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
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 1
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, part
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
JT
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 +++
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
---
src/openocd.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/sr
55 matches
Mail list logo
