• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  General Category / General Discussion / Re: Faster in-memory compression on: November 03, 2009, 04:41:13 AM
I'm sorry. I read this page http://www.marvell.com/technologies/cpu_history/cpu_history.jsp and I thought that Sheeva included all the things named in the 2007 paragraphs. Now I see they are different things.

Well, according to http://www.arm.com/products/CPUs/architecture.html, the ARMv5te includes an 'advanced'  DSP (digital signal processing) instruction set.  http://www.arm.com/products/CPUs/cpu-arch-DSP.html

The question would be similar: does compiling with GCC on the Sheeva make use of that instruction set, or should it be used adding specific code? Are DSP instructions considered in the available compiler?

EDIT: In the gcc man page, I found:  -mdsp / -mno-dsp Use (do not use) the MIPS DSP ASE .  When I compile with -mdsp, however, I get  cc1plus: error: unrecognized command line option "-mdsp". Any clue?
2  General Category / General Discussion / Faster in-memory compression on: November 03, 2009, 01:11:35 AM
I'm facing the following problem. I have a TCP/IP client-server application where the Sheeva is used to feed images to a number of clients. That part is already done and I am able to receive what I'm sending with no problems. However, it's terribly slow when images are quite big (1024x768).

So I managed to use libjpeg to compress images in memory before sending them, and then I uncompress them on the client. That part works too.  But it's even slower! The transference is obviously much faster (just 1ms!), because I'm sending like ten times less data.

The problem is that in-memory jpeg compression in the Sheeva is terribly costly, taking 90ms (15ms for an Intel Xeon 3Ghz), and that's quite a lot for my needs.

Digging a little bit in the documentation, I see that Sheeva features Wireless MMX2, floating point support, and compliance with both the ARMv5 and Intel XScale architectures. So, my question is:  when I compile directly on the sheeva, is GCC taking advantage of those features? I see no performance differences when I use -mtune=iwmmxt -mcpu=xscale or -mcpu=iwmmxt

Thank you!
3  General Category / General Discussion / Re: Cross compilation best practices on: October 22, 2009, 06:57:39 AM
I was wondering...

Sheeva is powerful enough to compile small projects. The main problem is its limited read/write cycles, right? But I could simply configure the compiler to create temporary files in an external device (a hard drive, an SD card, whatever), right?

Does it make sense?
4  General Category / General Discussion / Cross compilation best practices on: October 22, 2009, 01:31:53 AM
Cross compiling small and self-contained programs is pretty straightforward, I have already done that. However, when projects grow and require more libraries, things get complicated. After cross-compiling two common libraries (libz, for instance) in order to have their ARM version on my x86 machine so I can link them to my bigger program, I started wondering if I was doing things properly...

Then I though that most of those libraries can be easily installed on the Sheeva with apt-get and, indeed,  I already had all the required libraries and includes in /usr/include and /user/lib. I wondered if I could simply copy those two directories on my x86 machine and use them to compile (I bet I'm missing something here, it can't be that easy)

And then I read about Scratchbox, which seems to be the Proper Way of Doing Things.

How do you cross compile? Is Scratbox the right solution?
5  General Category / General Discussion / Re: Cross compiling FFMPEG on: October 19, 2009, 06:57:17 AM
And I finally answer myself. This is the required configuration:

./configure --enable-cross-compile --cross-prefix=..../gcc/bin/arm-none-linux-gnueabi- --arch=arm --cc=..../gcc/bin/arm-none-linux-gnueabi-gcc --prefix=..../arm_build_ffmpg --enable-armv5te --disable-armv6 --disable-mmx --enable-shared --disable-optimizations

The cross-prefix was needed in order to use the correct strip Smiley
6  General Category / General Discussion / Re: Cross compiling FFMPEG on: October 19, 2009, 06:47:58 AM
I managed to get rid of the 'internal consistency failure' disabling optimizations. But then I get

strip ffmpeg
strip: Unable to recognise the format of the input file `ffmpeg'

which I simply do not understand.

EDIT: It seems that I should be using arm-none-linux-gnueabi-strip, instead of my laptop's strip. I'll check that.

This is a one man thread! Cheesy
7  General Category / General Discussion / Cross compiling FFMPEG on: October 19, 2009, 06:04:08 AM
I need to cross compile ffmpeg because my main application requires it to be cross compiled too.

After some Googling, I managed to get this configuration  line:

 ./configure --enable-cross-compile --cc=..../gcc/bin/arm-none-linux-gnueabi-gcc --prefix=..../arm_build_ffmpg --enable-armv5te --disable-armv6

where ...... are my required paths. I disabled armv6 just in case, and I chosed armv5te because it was everywhere in these forums if I looked for armv Smiley

Then, when I run make, it starts compiling until I get this error:

libavformat/aviobuf.c: In function 'dyn_packet_buf_write':
./libavutil/x86/bswap.h:44: error: invalid 'asm': invalid operand for code 'w'
./libavutil/x86/bswap.h:44: error: invalid 'asm': invalid operand for code 'w'

Has anyone cross-compiled ffmpeg?

EDIT: I just found this link which points to a possible explanation...

http://nerdland.net/unstumping-the-internet/invalid-operand-for-code-w/

EDIT: I get even further adding --arch=arm

./configure --enable-cross-compile --arch=arm --cc=..../gcc/bin/arm-none-linux-gnueabi-gcc --prefix=..../arm_build_ffmpg --enable-armv5te --disable-armv6

but then I get this error, which is even uglier

libavcodec/mpegaudiodec.c: In function 'huffman_decode':
libavcodec/mpegaudiodec.c:1598: internal compiler error: internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Still not working... Sad
8  General Category / General Discussion / Re: LibUSB, OpenUSB and Sheeva on: September 12, 2009, 06:12:26 AM
ptosh: It's just because we already have the program we need in OpenUSB. If OpenUSB does not work on the Sheeva, we will be forced to rewrite it for libUSB.

libUSB 0.1, the one on the repositories, does not admit callbacks. libUSB 1.0 does, so I guess we will install that one.

However, I just can't find a reason why OpenUSB would not work on Sheeva! Sad
9  General Category / General Discussion / Re: LibUSB, OpenUSB and Sheeva on: September 11, 2009, 03:30:18 AM
No one?

I'm attaching both files, if anyone is interested in trying them.

lsusb.c is the libUSB example which, once libusb-dev are installed on Sheeva, compiles and runs. It lists all connected USB devices, with their configurations and interfaces

testopenusb.c is basically the same example, using OpenUSB. However, although it compiles and runs, it freezes when looking for USB devices.

Any help would be appreciated.
10  General Category / General Discussion / LibUSB, OpenUSB and Sheeva on: September 09, 2009, 08:55:55 AM
This is my first post, so first of all, hello everyone!

We have recently adquired and successfully configured a Sheeva Plug. We have also successfully cross-compiled and executed a simple libusb example that queries and lists all usb devices connected to the Sheeva Plug.

Then, we tried to cross-compile and execute a program that used OpenUSB instead of libUSB for the same task (it's the testopenusb.c program that comes with OpenUSB, which works perfectly on my laptop with Ubuntu). While it did compile and run on the Sheeva, it freezes when it calls openusb_get_busid_list (even when openusb is correctly initialized with openusb_init, callsbacks are set with openusb_set_event_callback and the default timeout is defined with openusb_set_default_timeout).

We have also tried a program that uses OpenUSB for connecting to a given usb device, knowing its vendor and product ID, which we know for certain that it works (we have previously used it on 'normal' computers under Ubuntu). OpenUSB on Sheeva, however, does not find the device, even when it's perfectly visible with the libusb example and lsusb.

What could be wrong with OpenUSB and Sheeva? Something related to threads? Does anyone have experience working with USB devices on Sheeva?

Thank you!
Pages: [1]