[Gumstix-users] Error trying to exec 'cc1'

[Jason C. M. <jas...@am...>]

I get the following error when I trying to compile the kernel (outside of bitbake)

arm-angstrom-linux-gnueabi-gcc: error trying to exec 'cc1' : execvp: No such file or directory

This error came as a complete surprise because everything was working fine a month or so ago when I left it. In fact I even created a nice VMware snapshot of everything working. All I had to do was enter in

export PATH=${PATH}:/home/gumstix/oe/tmp/cross/armv7a/bin
export PATH=${PATH}:/home/gumstix/oe/tmp/staging/i686-linux/usr/bin

For the path for the cross compiler, and the utility to create the uimage

Then I'd enter in

make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

It is entirely possible that some linux update got applied before I saved the snapshot, but after I did the last successful kernel build.

It's also possible that I'm forgetting some step.

the cc1 is in /usr/lib/gcc (under i486-linux-gnu).

Hopefully by sending this email I'll remember the second after I send it.




On Sep 3, 2009, at 10:51 AM, RJ wrote:

> At 11:50 PM 8/27/2009 +0800, S°ren  wrote:
> > >I assume you are talking about the Overo? If so, then a data rate of
> >300kHz x 10 bits + overhead is not possible. The ADC is read via the
> >dedicated PMIC I2C bus, which has a top speed of around 3.3Mbits/s.
> >
> > Yes, that's unfortunate; we'll have to look at another ARM for the
> > real-time process implementation needed.
> > Thanks.
>
> Hold on. In case it's OK to use an external ADC the OMAP has absolutely no
> problem handling the task.
>
> I'm currently working on a project where we are transferring ~100kHz 16-bit
> data from an external ADC using McBSP. Transferring of this to main memory
> using DMA is requiring as little as 1% of the ARM CPU power all included
> (measured using top).
>
> You therefore don't need another ARM - Just another ADC, which might require
> another board in case you don't plan to do any HW on your own - Agree :-)

Ahh, nice. That's what I'd hoped to hear.
I may pick you brain later for the nitty details on said DMA code. We'd like to use the Overo for a near-real-time data-feedback device, and so the DSP should then be free to do some 256N FFTs in its spare time as part of it. Adding an ADC is no problem; we might even be able to use 8 bits if we AGC appropriately - bandwidth and FFT performance usually go way up.

Any idea as to the max DMA rate for the Overo?
I have a personal project with 14 bit CCD data looking for a device to drive it, using http://www.analog.com/en/audiovideo-products/cameracamcorder-analog-front-ends/ad9990/products/product.html # that I got samples of. I'm currently pairing it with my Cypress FX2 http://www.acquiredevices.com/sermod100.jsp card, but being able to DMA direct to memory or flash would be preferable.

Thank you,
Ray

<ATT00001.c><ATT00002.c>