Create a patch that reverts the change to ft2232_add_pathmove()?
As a first step you should make as *few* changes as possible, including
not messing with formatting.
From there the community could submit incremental patches that tinker
with formatting, precise implementation, etc.
That's my
On Tue, Sep 15, 2009 at 10:48 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 15 September 2009, Ųyvind Harboe wrote:
Can we strip away the memory from reset_config?
I.e that it just *sets* the flags, ignoring any previous state.
It just sets what you tell it to set ... ignoring
This patch needs work.
OpenOCD lacks the exception concept of a try-catch. There
are other cases where we *do* want error messages.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development
Hi,
This turns a warning into a debug message. It is printed if there is not
as much working area as requested. Many callers try iteratively until a
working area of suitable size is found. The current warnings are
irritating.
It should be up to the caller to decide if this is worth a
I think this is OK, it does not change the return value, it is still
reported as an error/exception condition, not ERROR_OK. So for the
codebase nothing is changed. In the calling functions we do fall back to
smaller buffers or alternative implementations. So the error warning
should be
The proposed patch does not try to solve the general problem of
errorhandling in OpenOCD. It simply wants to change the debug level at
which this exception is reported to the user.
Whats the problem ??
The attached patch *breaks* error reporting in other places.
--
Ãyvind Harboe
Hi, all!
First, I need to report that PXA debugging works with current trunk,
with a few minor issues (like ones in TODO list).
So I debug some prototype device, which is quite buggy itself, I have
managed to set up more or less stable
configuration, was able to flash file, etc. But what I can't
On Wednesday 16 September 2009, Øyvind Harboe wrote:
Should we cut 0.3 soon?
Not yet
Any significant work that could be completed in the near future?
I've got a bunch of patches; the new TAP-reset event isn't
quite right etc
___
Dirk Behme wrote:
Magnus Lundin wrote:
For comments:
This patch changes cortex_a8 to use a variable armv7a-debug_base
instead of hardedcoded OMAP3530_DEBUG_BASE .
This prepares for looking of debug_base from ROM Table scan (or from
config file)
At the moment no known functional changes.
Take #2
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2714)
+++ src/jtag/jtag.h
As far as I know there are two parts of OpenOCD that makes significant use
of path_move's and that is ARM11 and the XSVF/SVF player code. So I think
changes/patches should be tested against them.
Are there any core developers left here that know these things ??
the xsvf svf code is
Hi Øyvind,
--- Øyvind Harboe oyvind.har...@zylin.com schrieb am Mi, 16.9.2009:
This patch needs work.
OpenOCD lacks the exception concept of a try-catch.
There
are other cases where we *do* want error messages.
I agree that we need a message when it *finally* fails. However, when a
Thank you for a *much* better analysis of the problem.
(I checked a few sites and you missed a case where cfi.c is broken
if you remove the warning, i.e. no error/warning is logged if you
run out of working area, but otherwise a very productive post)
I'm still convinced that the warning in
For comments and testing:
Add actual code to the previously empty :
cortex_a8_init_debug_access()
Remove details of common cortex8a debug initalisations from
omap3_dbginit and replace with call to externally eposed
cortex_a8 dbginit function.
Best regards,
Magnus
Øyvind Harboe wrote:
Thank you for a *much* better analysis of the problem.
(I checked a few sites and you missed a case where cfi.c is broken
if you remove the warning, i.e. no error/warning is logged if you
run out of working area, but otherwise a very productive post)
I'm still
Have a bit of faith patience here.
What I just suggested to Rolf was an approach where we
net will *delete* quite a bit of code.
Rolf posted a patch to remove something annoying. We're
all agreed the superfluous warnings are annoying. That patch
made one thing better and another thing worse.
I'm about to commit a patch that *may* break at91arm9260.
Does anyone have a board to donate that I can test on?
Any testers out there on the list?
Patch:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010602.html
at91arm9260 may need a srst_gates_jtag added to
17 matches
Mail list logo
