What, in your opinion, is the advantage of the SWI?
Does it have some genuine merit over JTAG or is it just different?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
The main motivation for choosing it over jtag is probably using less pins,
as simple as that. There's no gain in debug functionality. Well, if you're
not counting the serial wire viewer, which I'm not sure is a part of swd.
But I believe it's often using a pin otherwise allocated the jtag
There needs to be a discussion and decision on how to handle, i2c, spi, swi,
bdi, etc. Possibly this involves merging/using urjtag...
Hacking them in one at a time will become a giant mess...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash
andreas Sorry for all the removed whitespace at the end of lines,
courtesy of Eclipse.
According to the link below, this is an editor preference.
http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg17143.html
___
Openocd-development
oyvind are you keeping two lists? One list for active and one for all taps?
One list. With an p-enabled element.
Duane 2) There is a ghost variable (that holds the length of the list)
oyvind rick [ this is good for performance ]
Agh... Really? I suspect both of you have fallen into the
On Tue, Nov 25, 2008 at 3:07 PM, Duane Ellis [EMAIL PROTECTED] wrote:
oyvind are you keeping two lists? One list for active and one for all taps?
One list. With an p-enabled element.
How do you then handle reordering?
The nice thing about two lists is that one is the enabled tap controllers
Hello!
Seems I'm the only one crazy enough to try to run a uClibc based
distribution on x86. (I can see the response, What's the point?)
Anyway, it turns out uClibc is currently lacking support for x86.
I've added the folder openembedded/packages/uclibc/uclibc-0.9.30/x86
and created the file
Mikael Rosbacke wrote:
Hello!
Seems I'm the only one crazy enough to try to run a uClibc based
distribution on x86. (I can see the response, What's the point?)
?Wrong mailing list?
This is OpenOCD..
___
Openocd-development mailing list
we are not guessing, we are creating a release branch that will be as such
frozen except for major bug fixes.
if after testing (month or so) all is good then we tag a release 1.0.
Might I also suggest that 1.0 be available to download as a .tgz or
simliar file? Most of the automated package
On Nov 25, 2008, at 1:19 PM, Steve Franks wrote:
we are not guessing, we are creating a release branch that will be
as such
frozen except for major bug fixes.
if after testing (month or so) all is good then we tag a release 1.0.
Might I also suggest that 1.0 be available to download as a
What, in your opinion, is the advantage of the SWI?
Does it have some genuine merit over JTAG or is it just different?
The cortex_m3 has a itm (instruction trace, serial output) that on all
current devices is multiplexed with jtag TMS.
Because of this we need to use swi to access this
It is common practice for an open-source project to release a
version as a tar of the source code. I expect we will
release a source code tar, linux binaries, and win32 binaries.
That's my thinking.
Spen
___
Openocd-development mailing list
For 1.0, do we want to consider removing support for all the
old syntaxes? Being a major release (i.e. the first one),
such a change would be reasonable. The downsides are the
loss of immediate backwards compatibility with old config
files. The manual already contains an appendix for
The attached patch removes all of the deprecated commands that I could
find. I also added any previously unlisted deprecated commands to the
appendix. This does not update all of the documentation to move away
from the now obsolete commands. I plan a larger change to the
documentation
On Nov 25, 2008, at 2:55 AM, Øyvind Harboe wrote:
There needs to be a discussion and decision on how to handle, i2c,
spi, swi,
bdi, etc. Possibly this involves merging/using urjtag...
Hacking them in one at a time will become a giant mess...
--
Øyvind Harboe
I don't see any obvious reason for this. destroy_reg_param() frees
exactly one item in the passed structure. From working through the
code, the pointer being freed shouldn't be changed. Sadly, that means
this is likely to be much more difficult to track. Is it easily
reproducible? If
On Wed, Nov 26, 2008 at 6:05 AM, Rick Altherr [EMAIL PROTECTED] wrote:
The attached patch removes all of the deprecated commands that I could find.
I also added any previously unlisted deprecated commands to the appendix.
This does not update all of the documentation to move away from the now
17 matches
Mail list logo
