On Friday 12 June 2009, Zach Welch wrote:
>
> > I say "most" issues since (a) there's no interlock between a polling
> > context and anything else, which may eventually trigger SMP issues;
> > and (b) this is one of several areas where the jtag and target layers
> > could stand to interact more cl
OpenOCD doesn't actually *need* to be keeping all TCP ports
active ... creating security issues in some network configs.
Instead, let config file specify e.g. "tcl_port 0" (or gdb_port,
telnet_port) to disable that particular remote access method.
---
doc/openocd.texi | 10 ++
On Fri, 2009-06-12 at 21:34 -0700, David Brownell wrote:
> Fix most of the polling issues relating to disabled targets:
>
> - Disable polling while running TAP event handlers ... the handlers
>rely on state machine transitions which polling will break.
>
> - Don't background-poll disabled T
On Monday 08 June 2009, Øyvind Harboe wrote:
> What I believe is required to get OMAP up and running is:
... a superset of what's needed to get JRCs working on DaVinci.
Hence my poking at the simple sub-problem. ;)
> - clean up & support the ir/drscan commands + add pathmove/statemove
> command
On Friday 12 June 2009, David Brownell wrote:
> On Monday 08 June 2009, Dirk Behme wrote:
> > - Tell exactly what is broken (from a technical point of view, maybe
> > on a level a not so experienced OpenOCD engineer could understand...
>
> Here's a start. Maybe other folk can add more. ...
Bri
Doc update: say "jtag newtap ... -disable" records the
state after exiting the RESET state, matching the only
implementation we're working with so far (TI ICEpick-C).
Matching code updates, including a few minor cleanups
mostly related to the JTAG event callback mechanism:
- a memory leak in jt
Address some issues that ICEpick JRC support turned up:
- If the target is already enabled, don't re-enable it.
(Likewise, don't re-disable if it's disabled.)
- Targets need to be examined after they are enabled, in the
not-unusual case that they weren't yet examined. Else you
can't f
It's still not *quite* working as expected, since talking to
the EmbeddedICE module on the ARM is giving nonsense, but at
least I seem to be able to do things without explosions.
Following are three patches that improve handling of disabled
targets, and the process of enabling them:
- Don't let
Fix most of the polling issues relating to disabled targets:
- Disable polling while running TAP event handlers ... the handlers
rely on state machine transitions which polling will break.
- Don't background-poll disabled TAPs ... this was just a bug waiting
to happen. (And then it happe
On Friday 12 June 2009, Alain Mouette wrote:
> And on the wike there are samples, but not for
> Luminary-Cortex-M3
You mean "Texas Instruments" yes? :)
In svn:
tcl/interface/luminary*
tcl/target/lm3s*cfg
They might need a bit of work yet. If so,
please send patches!
_
I got it compiled, but not working :(
I am missing the sample config and scripts. Some page I googled said it
should have been in doc/configs/ but I didn't get it
I supose they moved, but could not find them, nor in the wiki there is
no refference to it. And on the wike there are samples, but n
On Fri, 2009-06-12 at 15:15 -0700, David Brownell wrote:
> On Friday 12 June 2009, Zach Welch wrote:
> > Since you have looked at this code closely, can you tell us how hard
> > would it be to support up to 64 bit IR lengths? My gut tells me that
> > would require more systemic work, but perhaps I
On Friday 12 June 2009, Zach Welch wrote:
> Since you have looked at this code closely, can you tell us how hard
> would it be to support up to 64 bit IR lengths? My gut tells me that
> would require more systemic work, but perhaps I am wrong.
I don't know how "closely" I looked, but one issue se
On Fri, 2009-06-12 at 12:45 -0700, David Brownell wrote:
> Currently the "debug_level 3" command tracing ignores commands
> that could return values to TCL scripts (by plugging in to a
> slightly lower level of the interpreter stack).
>
> Fix that by abstracting the tracing command and starting to
On Fri, 2009-06-12 at 12:50 -0700, David Brownell wrote:
> Move the discussion of the "scan_chain" command up to go with
> the presentation of that topic in the TAP declaration chapter.
>
> This makes the presentation of the TAP and target lists be
> parallel, which will be something of an aid to
On Fri, 2009-06-12 at 12:53 -0700, David Brownell wrote:
> Partial fix to the "long IR length" problems.
>
> - Current code could handle up to 32 bit IR lengths with
>full functionality, if it didn't just reject may of them
>out of hand. So only reject clear errors, where the IR
>mas
On Monday 08 June 2009, Dirk Behme wrote:
> - Tell exactly what is broken (from a technical point of view, maybe
> on a level a not so experienced OpenOCD engineer could understand...
Here's a start. Maybe other folk can add more. From the docs
I have, I don't think Beagle actually needed stand
On Fri, 2009-06-12 at 17:16 -0300, Alain Mouette wrote:
> Unfortunately there is more...
>
> I got a message about makeinfo, and solved installing texinfo. Now I
> have this and no clue about it:
>
> Npte that I am using a freshly instlled machine, so I don't have much
> installed. (Kubuntu 8.0
Unfortunately there is more...
I got a message about makeinfo, and solved installing texinfo. Now I
have this and no clue about it:
Npte that I am using a freshly instlled machine, so I don't have much
installed. (Kubuntu 8.04)
Making all in doc
make[2]: Entering diretory `/home/alain/projetos
Currently the "debug_level 3" command tracing ignores commands
that could return values to TCL scripts (by plugging in to a
slightly lower level of the interpreter stack).
Fix that by abstracting the tracing command and starting to
make some of those previously-untraced commands use this new
mecha
Move the discussion of the "scan_chain" command up to go with
the presentation of that topic in the TAP declaration chapter.
This makes the presentation of the TAP and target lists be
parallel, which will be something of an aid to understanding
that they are different (and how).
---
doc/openocd.t
Partial fix to the "long IR length" problems.
- Current code could handle up to 32 bit IR lengths with
full functionality, if it didn't just reject may of them
out of hand. So only reject clear errors, where the IR
mask (or capture instruction) needs more than IrLen bits.
- Longer IR
Solved... see bolow
Rick Altherr escreveu:
>
> On Jun 11, 2009, at 9:24 PM, Alain Mouette wrote:
>
>> I updated OpenOCD and got ut to this point:
>>
>> installed libftd2xx0.4.16 in /usr/lib/
>> svn checkout svn://svn.berlios.de/openocd/trunk openocd
>> ./bootstrap
>> ./configure --enable-ft2232-
Nico,
You are correct, target.c modifies for endianness. This is helpful when I set
openocd to -endian big; it sets the word order for mw and md commands to the
same endianness as the binary files I want to load. The problem is the
mips_m4k
target does not adjust for endianness like the xsca
> -Original Message-
> From: Zach Welch [mailto:z...@superlucidity.net]
> Sent: vrijdag 12 juni 2009 10:39
> To: Nico Coesel
> Cc: David Claffey; openocd-development
> Subject: Re: [Openocd-development] mips32 big endian fix
>
> On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote:
> > > -
On Fri, 2009-06-12 at 09:55 +0200, Nico Coesel wrote:
> > -Original Message-
> > From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> > development-boun...@lists.berlios.de] On Behalf Of David Claffey
> > Sent: donderdag 11 juni 2009 23:18
> > To: openocd-development
> > Su
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of David Claffey
> Sent: donderdag 11 juni 2009 23:18
> To: openocd-development
> Subject: [Openocd-development] mips32 big endian fix
>
> A patch is
27 matches
Mail list logo
