On Wed, Nov 26, 2008 at 6:12 AM, Rick Altherr <[EMAIL PROTECTED]> wrote:
> Is there a practical reason why the daemon cannot be started unless an
> interface has been specified? Frequently I find myself working on
> higher-level things such as syntax, online help, etc that do not really
> depend o
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
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 s
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
http://www.zylin.com/zy1000.
Is there a practical reason why the daemon cannot be started unless an
interface has been specified? Frequently I find myself working on
higher-level things such as syntax, online help, etc that do not
really depend on a target device. In fact, I'd like to be able to
fire up the daemon an
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 th
>
> 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 appendi
>
> Another thing about testing for 1.0.
>
> *Before* reporting bugs on 1.0, check that it works in SVN trunk.
>
> We aren't fixing bugs in 1.0, we're backporting fixes from
> SVN HEAD, maybe.
>
currently we have a 1.0 branch - until we finally tag a 1.0 release any
major bugs will be merged
>
> 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
> 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 th
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 .t
> 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
Oops...
Was meant for the openembedded list. So sorry for disturbing people
without a good reason.
--- Mikael R
tis 2008-11-25 klockan 10:32 -0500 skrev Duane Ellis:
> Mikael Rosbacke wrote:
> > Hello!
> >
> > Seems I'm the only one crazy enough to try to run a uClibc based
> > distribution on
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
Ope
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 uCl
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 contr
oyvind> How do you then handle reordering?
We do not reorder. We *DISABLE* a tap, which makes it skipped.
If later we actually need to "sort the list" - we can do that, but I
don't think Jtag Route Controllers do that.
-Duane.
___
Openocd-developmen
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 th
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 maili
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 pr
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 interface
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
___
Openocd-development
> For 1.0, do we want to consider removing support for all the old syntaxes?
Yes! :-)
Another thing about testing for 1.0.
*Before* reporting bugs on 1.0, check that it works in SVN trunk.
We aren't fixing bugs in 1.0, we're backporting fixes from SVN HEAD, maybe.
--
Øyvind Harboe
http://www.
23 matches
Mail list logo
