[oe] mtn disapprove

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:
| Thomas Kunze schrieb:
|> Have only things in zaurus-2.6.inc that are common to all zaurus.
|
| Hehe, have a look at 4989371c8e7cec943a964b459ec3e71c0f547204 which I
| committed yesterday. It already does exactly as you suggest.  My mail
| about it has not made it to the list, though.  There seems to be a few
| hours backlog with the OE ml.

I suspect spamassassin.

| From the commit message
|
| conf/machine/: fix configuration for Strongarm devices
| * replace erroneous TARGET_CC_ARCH line optimising for xscale instead of
|   strongarm
| * remove inclusion of tune-strongarm.inc from collie.conf and replace it
|   with the correct TARGET_CC_ARCH.  Collie is the only Strongarm 1110
|   device in OE and thus needs special treatment

Is it? Wikipedia[2] Tells a different story, and AFAIK simpad and
htcwallaby are sa1110 as well.

| * rename tune-strongarm.inc to tune-strongarm1100.inc and leave a short
|   note to make it clear the file only applies to Strongarm 1100 devices.
|
| collie is apparently Strongarm 1110, all other Zaurus are 1100.

~From the gcc 4.1.2 manual[1]:

- -->8------
- -mcpu=name
This specifies the name of the target ARM processor. GCC uses this name
to determine what kind of instructions it can emit when generating
assembly code. Permissible names are: `arm2', `arm250', `arm3', `arm6',
`arm60', `arm600', `arm610', `arm620', `arm7', `arm7m', `arm7d',
`arm7dm', `arm7di', `arm7dmi', `arm70', `arm700', `arm700i', `arm710',
`arm710c', `arm7100', `arm7500', `arm7500fe', `arm7tdmi', `arm7tdmi-s',
`arm8', `strongarm', `strongarm110', `strongarm1100', `arm8', `arm810',
`arm9', `arm9e', `arm920', `arm920t', `arm922t', `arm946e-s',
`arm966e-s', `arm968e-s', `arm926ej-s', `arm940t', `arm9tdmi',
`arm10tdmi', `arm1020t', `arm1026ej-s', `arm10e', `arm1020e',
`arm1022e', `arm1136j-s', `arm1136jf-s', `mpcore', `mpcorenovfp',
`arm1176jz-s', `arm1176jzf-s', `xscale', `iwmmxt', `ep9312'.

- -mtune=name
This option is very similar to the -mcpu= option, except that instead of
specifying the actual target processor type, and hence restricting which
instructions can be used, it specifies that GCC should tune the
performance of the code as if the target were of the type specified in
this option, but still choosing the instructions that it will generate
based on the cpu specified by a -mcpu= option. For some ARM
implementations better performance can be obtained by using this option.

- --8<------

There's no 'strongarm1110' (four digits of which 3 ones) entry only
strongarm (no digits) strongarm110 (three digits of which 2 ones) and
strongarm1100 (four digits of which 2 ones)

So I suggest using -mtune=strongarm for all strongarm devices, since
that's the safest *documented* gcc tune option for strongarm CPUs. As
for why OE was using -mtune=xscale:

~  In a past a long time ago where bitbake needed 1GB of memory and
multimachine wasn't around yet the distributions targeting strongarm
devices (openzaurus and familiar) wanted to have a single feed for all
devices (strongarm and pxa) without having a big speed penalty on xscale
devices with a bigger pipeline. So the binaries run on both strongarm
and xscale, but without the ~60% speedhit you would get without
- -mtune-xscale. The downside is that the binaries are slower on actual
strongarm cpus.

But AFAIK nowadays all strongarm targetting distros use multimachine, so
we can replace the xscale with strongarm and get a slight speed boost
since gcc will optimize for a 5 stage pipeline instead of a seven stage one.

Summary:
~ * don't use undocumented gcc options
~ * tune for the correct cpu family

regards,

Koen

[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/ARM-Options.html
[2] http://en.wikipedia.org/wiki/IPAQ
[3] http://gcc.gnu.org/ml/gcc/2002-02/msg00508.html

PS: there also is a sa1111, but that's a companion chip to the sa11x0
for things like usbhost.

- --
koen at dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi at student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHijynMkyGM64RGpERAi7/AJ4vqWIdoCb57PY14AfyXlsfRwr3ogCeKw3L
0nxgQT9yk0GcS6APZFzaPyo=
=jmYG
-----END PGP SIGNATURE-----