~/Projects $ size openocd.gcc
textdata bss dec hex filename
915920 11600 90668 1018188 f894c openocd.gcc
~/Projects $ size openocd.clang
textdata bss dec hex filename
902754 10684 90572 1004010 f51ea openocd.clang
> -Original Message-
>
On Thursday 28 January 2010, Austin, Alex wrote:
> +#ifndef true
> +#define true -1
ANSI-C defines true as "1" not "-1" ... best
to use that for compatibility.
I suspect I'll merge this portability patch with that change...
> +#define false 0
> +#endif
By the way, were those object sizes "size
So, just for curiosity, I decided to try llvm-clang to build openocd.
I haven't actually run the build yet, but it's just over half the
size of the gcc build, and compiled just a touch faster, too. Any
comments? The time output is from "make -j3" calls.
openocd-via-gcc:
real0m25.669s
user0
On Thursday 28 January 2010, Dean Glazeski wrote:
> > The only significant "anti-" sentiment I have is that the Trac git plug-in
> > hasn't had an update since 28th of August of 2009. I'm going to play with
> > this a little bit with my sourceforge project that's hooked up to git and
> > I'll get
>
> The only significant "anti-" sentiment I have is that the Trac git plug-in
> hasn't had an update since 28th of August of 2009. I'm going to play with
> this a little bit with my sourceforge project that's hooked up to git and
> I'll get back to you.
>
Alright, it's impossible to do it, for n
On Thu, Jan 28, 2010 at 7:45 PM, David Brownell wrote:
> On Thursday 28 January 2010, Dean Glazeski wrote:
> > You know, I'm sort of in love with Trac. I love the way their code is
> > designed and I love their system. I've been using for quite some time.
>
> Hmm, so you're ahead of most of us!
On Thursday 28 January 2010, Dean Glazeski wrote:
> You know, I'm sort of in love with Trac. I love the way their code is
> designed and I love their system. I've been using for quite some time.
Hmm, so you're ahead of most of us! Might you then be interested
in helping this project at least st
On Thu, Jan 28, 2010 at 5:49 PM, David Brownell wrote:
> On Thursday 28 January 2010, Edgar Grimberg wrote:
> > How about we try using a bug database of sorts? Mantis is the first
> > that comes to mind. It can be read-only for the general public and
> > only the maintainers (and "official tester
On Thursday 28 January 2010, Edgar Grimberg wrote:
> How about we try using a bug database of sorts? Mantis is the first
> that comes to mind. It can be read-only for the general public and
> only the maintainers (and "official testers", if you like) can add
> bugs into it. It's a way to gather all
> Whoops, sorry -- that one isn't listed as "regression"[1],
> nobody has confirmed that it was working in 0.3.1 code.
How about we try using a bug database of sorts? Mantis is the first
that comes to mind. It can be read-only for the general public and
only the maintainers (and "official testers"
On Thursday 28 January 2010, David Brownell wrote:
> On Thursday 28 January 2010, Edgar Grimberg wrote:
> > The information presented by flash info about the protection status
> > points to something faulty.
>
> This is on my list of regressions. Someone with an STR7
> should come up with a fix .
On Wednesday 27 January 2010, Thomas Kindler wrote:
> There's a quirk (bug?) in OpenOCD that requires you to give the -f
> option explicitly when using -c commands.
>
> So "openocd -f openocd.cfg -c erasemem" should work.
>
> Also, you have to call "init"-function first -- either on the command
On Thursday 28 January 2010, Matthew Fletcher wrote:
> There appears to be a certain amount of rot in the amt_jtagaccel driver,
That was my conclusion when I noticed, not long ago, that
it wouldn't even *build* with PPDEV enabled ... an issue
that's been around for quite some time.
Those unexpec
On Thursday 28 January 2010, Edgar Grimberg wrote:
> The information presented by flash info about the protection status
> points to something faulty.
This is on my list of regressions. Someone with an STR7
should come up with a fix ...
___
Openocd-dev
Hi,
The information presented by flash info about the protection status
points to something faulty. My target is a HITEX STR710 evalboard.
I am using v0.4.0-rc1-154-g3172be8 . The configuration script is the
default one from target/str710.cfg
This is the test case:
> flash protect_check 0
success
> Can anyone verify that this interface is still functional in
> 0.4 ? Out of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the
> old rev.131 fetch works to a certain extent. In all cases the
> openocd was built from source on cygwin with only
> amt_jtagaccell and parport_give_io enabled in co
If I disable the write burst mode, I get a different error on reset:
Disableing the burst mode:
(gdb) moni arm11 memwrite burst disable
memory write burst mode is disabled
with the log:
Debug: 1109 1770274 gdb_server.c:2147 gdb_input_inner(): received
packet: 'qRcmd,61726d3131206d656d7772697465
And the debug_level 3 log of the reset command:
>> reset
> JTAG tap: imx31.etb tap/device found: 0x2b900f0f (mfg: 0x787, part:
> 0xb900, ver: 0x2)
> JTAG tap: imx31.cpu tap/device found: 0x07b3601d (mfg: 0x00e, part:
> 0x7b36, ver: 0x0)
> TAP imx31.whatchacallit does not have IDCODE
> JTAG tap: im
Hi,
Can anyone verify that this interface is still functional in 0.4 ? Out of
0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch works to a
certain extent. In all cases the openocd was built from source on cygwin with
only amt_jtagaccell and parport_give_io enabled in configure.
On Wed, Jan 27, 2010 at 7:44 PM, David Brownell wrote:
> On Wednesday 27 January 2010, Edgar Grimberg wrote:
>> On Tue, Jan 26, 2010 at 10:08 PM, David Brownell wrote:
>> > On Tuesday 26 January 2010, David Brownell wrote:
>> >> > No, I haven't checked the buffer. Do you suspect GDB to have a pro
Nicolas Pitre wrote:
> On Wed, 27 Jan 2010, Spencer Oliver wrote:
>
>> Cygwin would fail to reopen a previously written file if the mode is
>> not given.
>
> What do you mean?
>
If we use a open on the target the first time cygwin host opens a new
file all is well. If we reset micro and try to
Hello Thomas!
Thomas wrote:
> There's a quirk (bug?) in OpenOCD that requires you to give the -f
> option explicitly when using -c commands.
>
>So "openocd -f openocd.cfg -c erasemem" should work.
>
>Also, you have to call "init"-function first -- either on the command
>line, or in your openocd.cf
22 matches
Mail list logo
