Hi Jose,
I also stuck at that point. I am sure that the error is due to the old
compiler version of the arm-gcc. What you can most easily do is using an
older version of opencv or
simply remove the contents of the function icvPyrSegmentation (of course
keeping a "return CV_OK"). Fortunately, this is the only function in the
compile process that doesnt work and most algorithms do not need it.
If you really want to solve the problem, I would recommend to
- get a new compiler toolchain, which involves compiling gcc and takes a
lot of time if one has never done it before (who knows, maybe its enough
to download the newest version from ti.com??) important: the davinci
architecture is not arm-linux but arm_v5t_le- !
- or write a patch for this opencv funtion (you never know, can be easy
or impossible)
Both takes some time so I have not tried so far, because my face
recognition algorithms do not need the function at all.
I am most interested in how you solve the problem - especially when you
get a new gcc working it would be great to hear how that is done!
By the way, I am still working on porting some opencv functions to the
DSP. I have integrated the bigphysarea patch into the montavista kernel
and rewritten CMEM to dynamically allocate physical memory. And, dsplink
messages are working now. But, of course, it will take some time to
implement it properly. Hopefully, matrix multiplication or at least
convolution on the real opencv matrix structures will work in a two or
three weeks.
-- Andre
[EMAIL PROTECTED] wrote:
Hi Andre,
I'm trying to complete the first step you mentioned, i.e. "make (i) Opencv
work on the ARM-montavista-linux (which I did quite quickly)".
When I try to compile the OpenCV sources, I get the following error
compiling cv/src/cvpyrsegmentation.cpp
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../.. -I. -I../../cv/include -I../../cxcore/include -I../..
-DNDEBUG -Wall -fno-rtti -pipe -O3 -fomit-frame-pointer -MT
cvpyrsegmentation.lo -MD -MP -MF ".deps/cvpyrsegmentation.Tpo" -c -o
cvpyrsegmentation.lo cvpyrsegmentation.cpp; \
then mv -f ".deps/cvpyrsegmentation.Tpo" ".deps/cvpyrsegmentation.Plo";
else rm -f ".deps/cvpyrsegmentation.Tpo"; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cv/include
-I../../cxcore/include -I../.. -DNDEBUG -Wall -fno-rtti -pipe -O3
-fomit-frame-pointer -MT cvpyrsegmentation.lo -MD -MP -MF
.deps/cvpyrsegmentation.Tpo -c cvpyrsegmentation.cpp -fPIC -DPIC -o
.libs/cvpyrsegmentation.o
cvpyrsegmentation.cpp: In function `CvStatus
icvPyrSegmentation8uC3R(uchar*, int, uchar*, int, CvSize, CvFilter,
CvSeq**, CvMemStorage*, int, int, int)':
cvpyrsegmentation.cpp:1021: internal compiler error: in
verify_local_live_at_start, at flow.c:546
Please submit a full bug report,
with preprocessed source if appropriate.
Send email to MontaVista Software, Inc. for instructions.
make[3]: *** [cvpyrsegmentation.lo] Error 1
make[3]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/opencv/tmp/opencv-1.0.0/cv'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
make[1]: Leaving directory `/home/opencv/tmp/opencv-1.0.0'
Do you know something about it?
Thanks in advance and regards.
Jose
-------- Original Message --------
Subject: Porting OpenCV to DM6446
Date: Fri, 09 May 2008 13:08:32 +0200
From: Andre Gaschler <[EMAIL PROTECTED]>
To: [email protected]
Hello,
in the previous weeks I have been working on porting OpenCV to the
DM6446. The main target is to make (i) Opencv work on the
ARM-montavista-linux (which I did quite quickly) (ii) Opencv use some
DSP power, namely for those very basic matrix operations. If anybody
does not know Opencv, its basically a computer vision C library
originally made for i86. It both provides basic math and matrix
operations and very newly researched computer vision algorithms.
For now, my main target is to allocate opencv matrix data in common
memory of the DM6446 and rewrite and encapsulate i.e. the matrix
multiplication function of opencv so it calls a procedure on DSP side
(pointers to the matrices by-reference). So, basically I only need (i)
remote procedure calls and (ii) nice access to common memory.
For the former, I am experimenting with DSPLINK that seems to serve nice
remote procedure calls. Do you think it is right not to use the Codec
Engine. What Ive heard CE is specialized on stream processind and
DSPLINK with its modules PROC and NOTIFY/MSGQ is more appropriate for
"normal" RPCs.
For the latter, I cannot really agree with the tools TI provides. I
tested DSPLINK POOL, that only serves fixed size pools that have to be
determines at boot/compile time. The same goes for CMEM (which DSPLINK
uses I think(?)). The memory pools are a good idea for DSP algorithms
with fixed worst-case memory requirements. But not for usual computer
vision algorithms that firstly use *lots* of structures you are not
going to allocate pools for and secondly, do not have fixed requirements
in general.
My most important questions are
- do think its a good idea in general to port opencv to the DM6446
- is there *anything* that can *dynamically* allocate memory (not in
pre-defined pools) so both ARM and DSP can work on it without copying???
Ive got the impression since the DSP does not have a memory management
unit it has got to work on (huge) chunks of continuous physical memory.
Because if there is no means for dynamically allocate continuous
physical memory I will write a linux kernel module for that (that
replaces CMEM).
Andre
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
