Is this the expected behaviour now, as previous versions
would fail silently
if no id was given.
I changed that when I changed it to make sure it didn't
drop messages in various cases. I think it's better to
get the config files updated, so startup verification
can do a better
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Best regards,
Magnus
===
.
.
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the patch in attachment? It
Below is the error output(SVN top, 2768):
etm.c:189:1: OUT redefined
In file included from
C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../inclu
de/rpc.h:40,
from
C:/msys/1.0/bin/../lib/gcc/mingw32/3.4.5/../../../../inclu
de/windows.h:82,
from
Hi list,
I've used openocd for burning bootloader several months and I woks well. But
recently I got a very strange problem I cannot solved.
My operations as following:
1. power on the board
2. run openocd
It show CPU matches successful.
3. telnet localhost $port
then I type halt to
Magnus Lundin wrote:
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the
At the end of the reset handling we reinitialise the tap and the
debug interface with omap3_dbginit
omap3_reset is really reset+reinit+halt and you call it if you want
to debug the loading of u-boot by the X-Loader
Do you mean omap3_reset should be called 'manually' if needed, same
Magnus Lundin wrote:
At the end of the reset handling we reinitialise the tap and the
debug interface with omap3_dbginit
omap3_reset is really reset+reinit+halt and you call it if you want
to debug the loading of u-boot by the X-Loader
Do you mean omap3_reset should be called
On Tuesday 29 September 2009, jie zeng wrote:
timeout halted
Error run command.c line XXX
What hardware?
I've seen such issues with the OMAP5912, which has
what seems to be an early ARM926 core. The most
strange thing is that the EmbeddedICE unit seems to
misbehave ... as in, the debug_status
On Tuesday 29 September 2009, simon qian wrote:
In etm.c, OUT is defined to initialize struct etm_outputs.
In rpcdce.h, OUT is also defined:
#ifndef _NO_W32_PSEUDO_MODIFIERS
#define IN
#define OUT
#ifndef OPTIONAL
#define OPTIONAL
#endif
#endif
I recommend to change OUT in etm.c to
On Monday 28 September 2009, Øyvind Harboe wrote:
Is this the expected behaviour now, as previous versions would fail
silently
if no id was given.
I changed that when I changed it to make sure it didn't
drop messages in various cases. I think it's better to
get the config files
On Tuesday 29 September 2009, Spencer Oliver wrote:
I tend to agree that we need to handle the case of no id - as per previous
versions.
How do we *not* do so now?
And which previous versions? Repository history shows
diagnostics came from some...
On Tue, Sep 29, 2009 at 11:14 PM, David Brownell davi...@pacbell.net wrote:
What hardware?
Board is vsc7501(vitesse) which used ARM926ejs core.
I've seen such issues with the OMAP5912, which has
what seems to be an early ARM926 core. The most
strange thing is that the EmbeddedICE unit seems
On Tue, Sep 29, 2009 at 5:57 PM, David Brownell davi...@pacbell.net wrote:
On Monday 28 September 2009, Ųyvind Harboe wrote:
Is this the expected behaviour now, as previous versions would fail
silently
if no id was given.
I changed that when I changed it to make sure it didn't
drop
I once argued that it should be possible to write a piece of
tcl code that decides what to do with the IDCODE(if any).
One of the things that such a script could do is to fail.
Obviously such a script should be able to do nothing, silent
success in all cases..
--
Øyvind Harboe
Hi,
OUTPUT doesn't conflict with system header files.
But I recommend to use MODULE_X to define a macro,
so it will never conflict with anything.
After all, IN, OUT, OUTPUT, INPUT and COUNTER are
commonly used.
2009/9/29 David Brownell davi...@pacbell.net
On Tuesday 29 September 2009, simon
On Tuesday 29 September 2009, Øyvind Harboe wrote:
I loathe macros as much as the next guy, a nasty feature of C
if there ever was one that I wanted to pick on...
Macros can be fine ... if you've ever used syntax macros in LISP,
you should know what I mean.
C macros ... have issues. But
On Tuesday 29 September 2009, Øyvind Harboe wrote:
Would handling -expected-id 0 as a match anything wildcard
suit, as an explicit stifle warnings option for (2a) or, in
fact, any branch of (2)?
Don't override the meaning of integers, use a separate keyword :-)
There's long been special
On Saturday 26 September 2009, David Brownell wrote:
Fix glitches in ARM11 command handling: commands were supposed
to have been arm11 memwrite ... not memwrite
Get rid of obfuscatory macros. Re-alphabetize.
Add docs for arm11 vcr.
---
Someone with an ARM11 based board, please
On Tuesday 29 September 2009, David Brownell wrote:
There's long been special handling for -expected-id 0;
I'm aiming for a minimal patch.
... which is now checked in. Only -expected-id nonzero causes
checks, matchin the existing docs.
___
commit 07c86fdf5eaa3439d48e03fc0a4850bc0b7d0a7e
Author: dbrownell dbrown...@b42882b7-edfa-0310-969c-e2dbd0fdcd60
Date: Tue Sep 29 18:20:30 2009 +
Doc updates: add section on target software changes, minor fixes
git-svn-id: svn://svn.berlios.de/openocd/tr...@2774
On Tuesday 29 September 2009, simon qian wrote:
OUTPUT doesn't conflict with system header files.
I checked in a fix.
But I recommend to use MODULE_X to define a macro,
so it will never conflict with anything.
After all, IN, OUT, OUTPUT, INPUT and COUNTER are
commonly used.
The real
On Tue, Sep 29, 2009 at 7:52 PM, David Brownell davi...@pacbell.net wrote:
On Tuesday 29 September 2009, Ųyvind Harboe wrote:
Would handling -expected-id 0 as a match anything wildcard
suit, as an explicit stifle warnings option for (2a) or, in
fact, any branch of (2)?
Don't override the
On Tuesday 29 September 2009, Øyvind Harboe wrote:
Overloading meaning of integers rarely leads to anything good.
Even if it was done this way before, doesn't make it good design...
Well enough; but that'd be a lot bigger change.
I'd rather see that with *no* -exepected-id's listed, no check
After all, there *does* need to be a way to say that such
a TAP is expected in the scan chain, and to report errors
when such a tap is missing ... or is unexpectedly present.
I think open source truly shines here in that we can
wait until we do encounter real world problems before
we implement
Committed.
Thanks!
--
Ø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.de
I didn't strip a gdb_breakpoint_override hard I found in mini2440.cfg
as I can see configuration of breakpoints to be legitimate to have in
a board config script.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
### Eclipse
If no -expected-id's listed then do not check ID's.
The code has not been tested, just posting for comments.
No 0 is wildcard ref. my do not override the meaning
of integers hobbyhorse.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash
28 matches
Mail list logo
