[gentoo-embedded] pxa270 cflags?

[gentoo-embedded] pxa270 cflags?

[Christopher Friedt]

Hi everyone,

I'm just in the middle of compiling some applications in the
media-video category for a pxa270 device, and I'm seeing a lot of
spots where potential iWMMXT hardware speedups are not being used
because I'm using CFLAGS="-march=armv5te -mtune=xscale". One person
said, there is only a difference between -mcpu=xscale and -mcpu=iwmmxt
when using OABI [1]. However, the -mtune=xscale flag does not properly
process iwmmxt instructions [2].  Is -mcpu=xscale only for pre-iwmmxt
pxa chips?

Does anyone know exactly which CFLAGS should be used for a pxa270 chip?

A binary compiled with -mcpu=iwmmxt still shows that it has version 4
EABI, which is fine for me. I just find it odd that XScale ISA is
supposedly identical to armv5te aside from FP instructions [3], while
gcc fails saying that "-march=armv5te -mtune=iwmmxt" is not kosher
[4].

Chris

[1] http://gcc.gnu.org/ml/gcc-help/2006-09/msg00061.html
[2] int main(void) { __asm__ volatile ("wunpckelub wr6, wr4"); return 0; }
[3] http://en.wikipedia.org/wiki/XScale
[4] arm-softfloat-linux-gnueabi-gcc -pipe -march=armv5te -mtune=xscale
-o test test.c
{standard input}: Assembler messages:
{standard input}:13: Error: selected processor does not support
`wunpckelub wr6,wr4'

Re: [gentoo-embedded] pxa270 cflags?

[Martin Guy]

Strictly speaking, iWMMXt is a coprocessor of the ARM, not a CPU, so
technically it is like an FPU except that it does not do floating
point, so it is modelled as a cpu in GCC, with an instruction set that
is a superset of the armv5te set. It's a bit like the difference
between pentium and pentium MMX. It only exists in silicon as a
coprocessor for armv5te cores as far as I know, hence "iwmmxt is
armv5te with extra stuff".
  Yes, it has its own old-ABI, which requires 8-byte alignment of
double words. EABI (v4) has this anyway so it may work.
  Furthermore, it hijacks the same coprocessor interface as the old
FPA floating point accelerator, or in other words, the bit patterns of
its instructions overlap with the FPA instruction set, so you must use
soft float and cannot use kernel emulation of FPA instructions. That's
not really a problem since no silicon exists with both iwmmxt coproc
and a real FPU of any kind, so you would want to use softfloat anyway.
  The main instructions that iwmmxt adds to the armv5te set are real
64-bit integer operations and a slew of vector instructions for those
tight inner loops. Whether it works, of course... have you tried
building gcc for it and running the testsuite on iwmmxt hardware? Prod
me if you need runes to do this.

>  gcc fails saying that "-march=armv5te -mtune=iwmmxt" is not kosher

Indeed. iwmmxt is modeled as both a cpu and an ISA, but unless there
are iwmmxt insns included, the tuning would be a no-op. It would be
like cpu=armv4 arch=armv4t - the armv4 can't run all armv4t
instructions.

Did you run into problems with cpu=iwmmxt?

   M

Re: [gentoo-embedded] pxa270 cflags?

[Christopher Friedt]

Hi Martin,

Thanks for your reply

On Wed, Aug 12, 2009 at 5:33 PM, Martin Guy<martinwguy@gmail.com> wrote:
> Did you run into problems with cpu=iwmmxt?

cpu=iwmmxt works fine, aside from an oddity with one of the later
mplayer builds from gentoo - compiling by hand with
CFLAGS="-mcpu=iwmmxt" generates an mplayer with iwmmxt, but running
the ebuild makes the mplayer configure script somehow fail the iwmmxt
tests, even with the same cflags. It's no biggie though.

Incidentally, did you ever get into the OpenMoko hardware? It's
turning out to be a bit of a disappointment. KoolU really hasn't been
maintaining their Android port. I've tried OM2008,9, and SHR, and they
all seem to fall short of the potential of the device. IMHO it really
boils down to the Glamo nastiness. I'd really like to get involved
with designing a _good_ handset from the ground up, if only there was
some sort of monetary incentive.

I really think OM needs to buckle down if they're going to be
releasing a new model based on Samsung's  6410, and I mean including a
UI that makes a statement relative to the market. Really, having a 3G
modem is almost standard these days. I would suggest just using the
same chip 'everyone' else is using, which is the msm7200a, but it's
not very open in spite of the good linux driver support and being
packed with so many goodies on the inside. Aside from that, there's
good ol' omap, but TI got rid of all of the baseband silicon from
their chips a while ago.

C

Re: [gentoo-embedded] pxa270 cflags?

[wireless]

Christopher Friedt wrote:

>  I'd really like to get involved
> with designing a _good_ handset from the ground up, if only there was
> some sort of monetary incentive.
> 
> I really think OM needs to buckle down if they're going to be
> releasing a new model based on Samsung's  6410, and I mean including a
> UI that makes a statement relative to the market. Really, having a 3G
> modem is almost standard these days. I would suggest just using the
> same chip 'everyone' else is using, which is the msm7200a, but it's
> not very open in spite of the good linux driver support and being
> packed with so many goodies on the inside. Aside from that, there's
> good ol' omap, but TI got rid of all of the baseband silicon from
> their chips a while ago.


Reading between the lines, it sounds like you want to walk on the
Dark (Rf) side?

Take a look here, if you really want to get into controlling the
Rf side of things.....

http://www.ettus.com/

http://gnuradio.org/trac

PS, If you are going along this path, I'd stick with a mainstream uP
and add peripherals as needed, or a FPGA design. IC companies get
lots of unseen pressure from governments and corporations, when there
sexi little SOC become available in great detail to the masses,
particularly those of a linux persuasion, in my experiences....

caveat emptor!


hth,
James

Re: [gentoo-embedded] pxa270 cflags?

[Christopher Friedt]

Hehee...

On Tue, Aug 18, 2009 at 9:39 AM, wireless<wireless@tampabay.rr.com> wrote:
> Reading between the lines, it sounds like you want to walk on the
> Dark (Rf) side?
> http://gnuradio.org/trac

It's funny that you mentioned gnuradio - I'm actually currently
working on a bit of a rewrite for the usrp2 driver. That's probably
all I can say about it for now though.

For the purposes of building a handset, and aside from tuning the
antenna, or checking the signal 'strength' in softtware, there really
is no need to get into the 'dark side'. If one wanted to experiment
with radio digital modulation formats and protocols, then I would
definitely buy at least 2 usrp2's, if they weren't so damn expensive.

The way I see a handset is that it's just the same as any other board
- the baseband is usually just connected to a uart if it's not
integrated on chip, then there's an rf converter, etc... throw in a
bunch of useful gpio, program a few interrupts, add a couple of
external circuits, and you're ready for quality control.

Without being a massive multi-national corporation, it's kind of hard
to get a hold of any 3G chip documentation, although there are a
couple of smaller companies that have been a bit more willing
(checkout gta02-core).

C