> This is a dumb question (because I could answer it by looking at the
> code for a little while), but can the polling mechanism be separated and
> moved into a JTAG sub-layer? It seems that this kind of coordination
> implies that some part of it should already be there.
The callback is just a g
On Thu, Jun 11, 2009 at 8:23 AM, Øyvind Harboe wrote:
> I was thinking that pathmove, irscan and drscan commands should
> fail or at least give a warning if they are invoked while background
> polling is running.
>
> But isn't that a "layering violation"?
>
> Should target tell jtag when it is doin
On Thu, 2009-06-11 at 08:23 +0200, Øyvind Harboe wrote:
> I was thinking that pathmove, irscan and drscan commands should
> fail or at least give a warning if they are invoked while background
> polling is running.
Sounds reasonable.
> But isn't that a "layering violation"?
It looks like it, yes
With synchronous and asynchronous execution error handling
becomes a bit trickier...
I'm thinking that jtag_add_pathmove() and jtag_add_stavemove()
should be split into two: checking args and queing fns.
Performance sensitive code that *KNOWS* that the arguments
are correct can invoke the queue f
I was thinking that pathmove, irscan and drscan commands should
fail or at least give a warning if they are invoked while background
polling is running.
But isn't that a "layering violation"?
Should target tell jtag when it is doing background polling or
should jtag check when target is doing pol
Committed.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Øyvind Harboe wrote:
> On Wed, Jun 10, 2009 at 5:30 PM, Dirk Behme wrote:
>> Ųyvind Harboe wrote:
>>> Committed.
>>>
>>> Does OMAP/BeagleBoard need this?
>>>
>>> This "pathmove" command is ready for testing & feedback.
>> If someone with more OpenOCD and recent changes knowledge than me likes to
>>
?? >> on The List here. If I can afford to take the time, OpenOCD will be
?? >> fully decoupled from its various driver modules.
duane> Debugging these things become a *ROYAL* *P*I*T*A*
duane> Symbols don't work, etc, (ie: I've been debugging some SANE
drivers, ugh, and I've done quite a
duane>
On Wed, 2009-06-10 at 21:40 -0400, Duane Ellis wrote:
> >> I have developed loadable module support in the past, and it's already
> >> on The List here. If I can afford to take the time, OpenOCD will be
> >> fully decoupled from its various driver modules.
>
> Debugging these things become a *RO
> > Could there be something we could put in the "configure
> script" - that
> > tells CYGWIN - to behave?
> > ie: Perhaps something like the SHELLOPTS thing?
> >
> > For example - maybe in the "bootstrap" script?
> > And in the "CONFIGURE' script?
> > And in the Makefiles?
> >
> > FYI - with SV
From my experiments, it appears to be don't-care for TMS. They just
need 100 TCK pulses to flip the bit to enable the JTAG power domain.
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
On Jun 10, 2009, at
On Wednesday 10 June 2009, David Brownell wrote:
> http://tiexpressdsp.com/index.php/ICEPICK
>
> The "how to add devices to an ICEpick-C scan chain" highlights
> one point: the JRC commands to add the ARM (and, for DaVinci,
> the ETB) to the scan chain must be done each time the TAPs go
> to th
On Wed, 2009-06-10 at 21:30 +0200, Øyvind Harboe wrote:
> On Wed, Jun 10, 2009 at 8:52 PM, Zach Welch wrote:
> > On Wed, 2009-06-10 at 09:19 +0200, Øyvind Harboe wrote:
> >> Committed.
> >>
> >> Does OMAP/BeagleBoard need this?
> >>
> >> This "pathmove" command is ready for testing & feedback.
> >>
Hi,
I'm interested in PowerPC QUICC2 (e300c3 core) JTAG/COP protocol. I
know it is kept kinda secret, but maybe there are some reverse
engineering traces I can use to break the ice even more.
So far I have found this interesting conversation, rather old, but still true:
http://newsgroups.derkeile
On Wed, Jun 10, 2009 at 8:52 PM, Zach Welch wrote:
> On Wed, 2009-06-10 at 09:19 +0200, Øyvind Harboe wrote:
>> Committed.
>>
>> Does OMAP/BeagleBoard need this?
>>
>> This "pathmove" command is ready for testing & feedback.
>> I've done some quick smoketests and it reveals some interesting
>> poin
On Wed, 2009-06-10 at 09:19 +0200, Øyvind Harboe wrote:
> Committed.
>
> Does OMAP/BeagleBoard need this?
>
> This "pathmove" command is ready for testing & feedback.
> I've done some quick smoketests and it reveals some interesting
> points in terms of where error checking should go... Discussed
On Tue, 2009-06-09 at 22:17 -0700, David Brownell wrote:
> On Tuesday 09 June 2009, Rick Altherr wrote:
> > I'm proposing that we use encapsulation and possibly ADTs to define
> > clear boundaries for functionality in the code base. Rather than have
> > one massive code base, I'd like to see s
I believe that continous polling should be similarly disabled
during jtag_tap_handle_event().
Any objections?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-
On Wed, Jun 10, 2009 at 5:30 PM, Dirk Behme wrote:
> Ųyvind Harboe wrote:
>>
>> Committed.
>>
>> Does OMAP/BeagleBoard need this?
>>
>> This "pathmove" command is ready for testing & feedback.
>
> If someone with more OpenOCD and recent changes knowledge than me likes to
> convert
>
> http://svn.be
Øyvind Harboe wrote:
> Committed.
>
> Does OMAP/BeagleBoard need this?
>
> This "pathmove" command is ready for testing & feedback.
If someone with more OpenOCD and recent changes knowledge than me
likes to convert
http://svn.berlios.de/svnroot/repos/openocd/trunk/tcl/board/ti_beagleboard.cfg
On Wed, Jun 10, 2009 at 3:38 AM, Kees Jongenburger <
kees.jongenbur...@gmail.com> wrote:
> On Wed, Jun 10, 2009 at 4:13 AM, Brian Hutchinson
> wrote:
> >> > seeing was:
> >> >
> >> >
> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg05321.html
> >> >
> >> > I'm using custom .cf
On Tuesday 09 June 2009, Magnus Lundin wrote:
> The type of target/tap initialisation that needs dr/ir scans to setup
> the jtag chain and controller are run before the target can be
> examined. The type of target initialisations that sets memory mapped
> registers with mww are not affected by
I'm tinkering with a standalone GDB GUI (like Insight) based
on Eclipse.
http://mail.zylin.com/pipermail/zylin-discuss_zylin.com/2009-June/000614.html
Eventually it might make sense to add some sort
of integration against OpenOCD, though OpenOCD does a good
job of taking care of all the messy
Committed.
Does OMAP/BeagleBoard need this?
This "pathmove" command is ready for testing & feedback.
I've done some quick smoketests and it reveals some interesting
points in terms of where error checking should go... Discussed
yesterday.
No patch to openocd.texi, because I believe that text sho
24 matches
Mail list logo
