Øyvind Harboe a écrit :
The zy1000 has infinite ram w.r.t. small allocations(32 or
64mBytes depending on revision), so not checking small
allocations is *highly unlikely * to cause problems for any
embedded host with oodles of ram(megabytes).
To be completely honest, it depends. If there's a
Carsten Breuer a écrit :
Nonetheless: Malloc can fail and we have to take care of that.
Well, yes for the first part, and maybe or even no for the second.
Yes, malloc can fail.
But when it fails, what *can* you do apart from trying to fail as
gracefully as possible? And failing gracefully is
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer
carstenbreueropen...@textwork.de wrote:
Hi all,
treat warning as errors (-wall) is a fine thing but sometimes breaks
the build..
This is a good thing to have as a default behavior, we want warning
fixes fed back.
Øyvind Harboe a écrit :
-Wall is the minimum that should be applied to source code. Running it
through Splint (or some other verification tool) would not hurt either.
Is there an open source lint tool that's worthwhile to use?
Did you try splint on OpenOCD?
Apart from Splint, I haven't
Øyvind Harboe a écrit :
On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD albert.arib...@free.fr
wrote:
Øyvind Harboe a écrit :
-Wall is the minimum that should be applied to source code. Running it
through Splint (or some other verification tool) would not hurt either.
Is there an open
Albert ARIBAUD a écrit :
Also note splint has not been updated for a long time, as I discovered
when going to its home site.
There are some alternatives mentioned on Wikipedia:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C
I like clang's way of reporting errors
Freddie Chopin a écrit :
The overhead of C++ is also doubtful - when you know how to do it
the overhead will be 0. BTW you also need to know how to do it to
write C++-in-C, so...
... and this overhead is 0 when you know how to do it, isn't it? :)
More seriously: I don't favor C over C++ or
Hi,
While at it, the OpenOCD configure.in should use pgk-config or
libftdi-config to find out the current LIBFTDI libs and CFLAGS,
especially the include path.
Regards,
Albert.
David Brownell a écrit :
Reason for OpenOCD folk to care is that previously failed...
below.
Y'all are
there, I'll re-email it through git send-email to make
sure.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
configure.in | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/configure.in b/configure.in
index 81e4326..755f762 100644
David Brownell a écrit :
On Tuesday 01 December 2009, Zach Welch wrote:
The use of angle brackets intends to distinguish parameter names from
literal arguments. Thus [foo] means an optional thing which
semantically will be used as a foo, whereas [foo|bar] means you can
optionally provide
Øyvind Harboe a écrit :
Finally, would it be logical to create the dynamic flash banks commands
as subcommands of their relevant target?
foo.cpu flash bank bank0 . # but no target arg anymore
foo.cpu bank0 info # presently, it's 'flash info bank0'
First of all: although
Albert ARIBAUD a écrit :
David Brownell a écrit :
On Wednesday 25 November 2009, Albert ARIBAUD wrote:
Dean Glazeski a écrit :
This patch shouldn't be necessary. I have the libftdi version working
fine with current head. I think this might be an issue with mixing
libraries
David Brownell a écrit :
On Wednesday 25 November 2009, Albert ARIBAUD wrote:
http://packages.debian.org/squeeze/amd64/libftdi-dev/filelist
Maybe they treat this /usr/include/ftdi thing as a bug and
work around it ... :)
Hmm... Checking the versions, Debian is talking about 0.16. I'm using
loody a écrit :
Hi:
thanks for your kind help ^^
it works find right now.
2009/11/26 Dean Glazeski dngl...@gmail.com:
You appear to mixing the two FTDI libraries in that configure command. If
you want to use the FTD2XX libraries, you need to use --enable-ft2232_ftd2xx
instead of
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
configure.in |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure.in b/configure.in
index 8ba8951..0adf014 100644
--- a/configure.in
+++ b/configure.in
@@ -932,6 +932,7 @@ if test $build_ft2232_libftdi = yes
loody a écrit :
dear all:
I use configure --help, but I cannot see where I can tell openocd
where the library of ft2232.
I use following configure even I don't use cygwin and I use lib
instead of device driver to compile it.
./configure --enable-ft2232_libftdi --prefix=`pwd`/build
Dean Glazeski a écrit :
This patch shouldn't be necessary. I have the libftdi version working
fine with current head. I think this might be an issue with mixing
libraries in the configure command. I've responded to the next email
with more information.
// Dean Glazeski
Well it
David Brownell a écrit :
On Wednesday 25 November 2009, Albert ARIBAUD wrote:
Dean Glazeski a écrit :
This patch shouldn't be necessary. I have the libftdi version working
fine with current head. I think this might be an issue with mixing
libraries in the configure command. I've
Hi,
I am trying to bring-up an ED Mini V2, a feroceon-based board with no
tRST/sRST signals available, only TCLK/TMS/TDI/TDO, and an Olimex
ARM-USB-OCD.
This ED-Mini has a working U-boot flashed already (I am aiming at
replacing this U-boot with a newer version).
To begin with, I've made a
David Brownell a écrit :
On Tuesday 24 November 2009, Albert ARIBAUD wrote:
Error: feroceon.cpu: IR capture error; saw 0x09 not 0x01
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
^^^
Does
David Brownell a écrit :
On Tuesday 24 November 2009, Albert ARIBAUD wrote:
I did investigate by fixing 0x3 directly in feroceon.cfg, and it does
not improve:
Error: IR capture error at bit 4, saw 0x09 not 0x...3
Are you sure you didn't make the ircapture be 0x3,
instead of the irmask
Albert ARIBAUD a écrit :
David Brownell a écrit :
On Tuesday 24 November 2009, Albert ARIBAUD wrote:
I did investigate by fixing 0x3 directly in feroceon.cfg, and it does
not improve:
Error: IR capture error at bit 4, saw 0x09 not 0x...3
Are you sure you didn't make the ircapture be 0x3
Hi all,
I would like to help add support in OpenOCD for a new board, found in
the LaCie ED Mini V2. This board is based on a Marvell Orion5x SoC,
which contains a Feroceon similar to that of a kirkwood.
This board has a minimal JTAG, with no rRST or tRST line, only TCKK,
TMS, DI and DI. This
David Brownell a écrit :
On Wednesday 18 November 2009, Albert ARIBAUD wrote:
This board has a minimal JTAG, with no rRST or tRST line, only TCKK,
TMS, DI and DI. This is different from the OpenRD or Sheevaplug configs
(which also have a feroceon).
Can someone on the list point me
Hi,
I have compiled and installed libftdi from GIT, forcing the prefix to
/usr. The lib header files are then installed into /usr/include/libftdi.
However, the current configure.in for OpenOCD expects file ftdi.h to be
in ${prefix}/include, not ${prefix}/include/libftdi, thus ./configure
Zach Welch a écrit :
On Mon, 2009-11-16 at 13:57 +0100, Albert ARIBAUD wrote:
Hi,
I have compiled and installed libftdi from GIT, forcing the prefix to
/usr. The lib header files are then installed into /usr/include/libftdi.
However, the current configure.in for OpenOCD expects file ftdi.h
26 matches
Mail list logo
