Re: mtn disapprove

Re: mtn disapprove

[QMan]

While we're on the subject of the collie machine stuff, we need to make sure
the tune-strongarm.inc that collie calls doesn't use the -mtune=xscale, as
is the current case, and instead use -mtune=strongarm1100 (not collie) or
-mtune=strongarm1110 (collie).  Also, the collie installkit script should
make "zImage" not "zImage.bin"

-John

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf
> Of Rolf Leggewie
> Sent: Friday, January 11, 2008 8:54 AM
> To: openembedded-devel@openembedded.org
> Subject: Re: [oe] mtn disapprove
>
> Koen Kooi schrieb:
> > It's the thing I had in mind, but never worked up the motivation of
> > doing :)
>
> OK, here it is: http://oz.leggewie.org/wip/machine-config.diff
>
> * drop unused poodle-2.6.inc
> * work contents of collie-2.6.inc into collie.conf
> * require zaurus-2.6.inc for collie.conf
> * deleted entries from collie.conf that seem superfluous
> * made some changes to zaurus-2.6.inc to make sure it applies
>   to all Zaurus models
> * define SERIAL_CONSOLE in zaurus-2.6.inc as ?=
>
> RP and hrw have given their OK.  I have locally committed it as
> 49cb87ce3fb4d9857d853d9e54f38fa88e9ccc85.  If there are no objections,
> I will eventually push it.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: mtn disapprove

[Rolf Leggewie]

John, thank you for being so observative.  I made the changes to
tune-strongarm.inc as you suggested.  zImage instead of zImage.bin has
already been committed a couple of days ago.  In fact it was the commit
that originally started this thread IIRC.  Thanks again.

I updated http://oz.leggewie.org/wip/machine-config.diff once more to
reflect the latest status.

Re: mtn disapprove

[Richard Purdie]

On Sat, 2008-01-12 at 11:42 +0100, Rolf Leggewie wrote: 
> John, thank you for being so observative.  I made the changes to
> tune-strongarm.inc as you suggested.  zImage instead of zImage.bin has
> already been committed a couple of days ago.  In fact it was the commit
> that originally started this thread IIRC.  Thanks again.
> 
> I updated http://oz.leggewie.org/wip/machine-config.diff once more to
> reflect the latest status.

Looks good and is fine with me, some really minor comments inline below:

> --- conf/machine/collie.conf	8ec2568fe9cb9c9b5580adf5e26eb873400e040c
> +++ conf/machine/collie.conf	b40e4db0893370c9b1145d8ad93ca1069a1f1002
> @@ -5,22 +5,18 @@ MACHINE_KERNEL_VERSION ?= "2.6"
[...]
> PREFERRED_PROVIDER_xserver = "xserver-kdrive"
>  
> -# This is needed for the ramdisk script to work
> -MACHINE_EXTRA_RDEPENDS += "e2fsprogs-mke2fs"
> -

What happened to this? It looks wrong, I just want to make sure the
underlying problem was fixed...

> --- conf/machine/include/tune-strongarm.inc	4bb1dc721e55061bb98b49bae4f57bd4ff088f02
> +++ conf/machine/include/tune-strongarm.inc	ffef523af56befe09f34efee482f2cb5677e4caf
> @@ -1,2 +1,3 @@
> -TARGET_CC_ARCH = "-march=armv4 -mtune=xscale"
> +TARGET_CC_ARCH ?= "-march=armv4 -mtune=strongarm1100"
> +TARGET_CC_ARCH_collie = "-march=armv4 -mtune=strongarm1110"

We should really have tune-strongarm1100.inc and
tune-strongarm1110.inc...
 
> --- conf/machine/include/zaurus-2.6.inc	7d4d7255328d5d3f3d61e09ec7b527085533b4d6
> +++ conf/machine/include/zaurus-2.6.inc	88f14d96b91bd44fabb62b5b7c9158ed161774be
> @@ -1,8 +1,9 @@
[...] 
>  TARGET_ARCH = "arm"
> -PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5e armv5te"
> +PACKAGE_EXTRA_ARCHS ?= "armv4 armv4t armv5e armv5te"
> +PACKAGE_EXTRA_ARCHS_collie = ""

No need for the ?= here...

> @@ -10,20 +11,14 @@ EXTRA_IMAGECMD_jffs2 = "--little-endian 
>  ERASEBLOCKSIZE_akita = "0x20000"
>  
>  EXTRA_IMAGECMD_jffs2 = "--little-endian --eraseblock=${ERASEBLOCKSIZE} --pad --faketime -n" 
> -
>  IMAGE_CMD_jffs2 = "mkfs.jffs2 -x lzo --root=${IMAGE_ROOTFS} --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
> -
>  EXTRA_IMAGEDEPENDS += "zaurus-updater"
>  
> -# Use tune-xscale per default. Machine independent feeds should be built with tune-strongarm.
> -include conf/machine/include/tune-xscale.inc
> +SERIAL_CONSOLE ?= "115200 ttyS0"

or here...

Cheers,

Richard

Re: mtn disapprove

[QMan]

Comment inline down below.

-John

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On
> Behalf Of Koen Kooi
> Sent: Sunday, January 13, 2008 8:31 AM
> To: Using the OpenEmbedded metadata to build Distributions
> Subject: Re: [oe] mtn disapprove
>
> -----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)

It turns out a bunch of aliases were added for specific models that use the
same options as the generic family they belong to.  These aliases never made
it to the documentation.


> 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:

Agreed.  Also, looking at the gcc source, it's pretty obvious that the
compiler uses the same options for all of the strongarm* tune options
anyway:

ARM_CORE("strongarm",     strongarm,    4,                   FL_MODE26 |
FL_LDSCHED | FL_STRONG, fastmul)
ARM_CORE("strongarm110",  strongarm110, 4,                   FL_MODE26 |
FL_LDSCHED | FL_STRONG, fastmul)
ARM_CORE("strongarm1100", strongarm1100, 4,                  FL_MODE26 |
FL_LDSCHED | FL_STRONG, fastmul)
ARM_CORE("strongarm1110", strongarm1110, 4,                  FL_MODE26 |
FL_LDSCHED | FL_STRONG, fastmul)

>
> ~  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@dominion.kabel.utwente.nl will go go away in december
> 2007, please use k.kooi@student.utwente.nl instead.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFHijynMkyGM64RGpERAi7/AJ4vqWIdoCb57PY14AfyXlsfRwr3ogCeKw3L
> 0nxgQT9yk0GcS6APZFzaPyo=
> =jmYG
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: mtn disapprove

[Rolf Leggewie]

QMan schrieb:
>> Agreed.  Also, looking at the gcc source, it's pretty obvious that the
>> compiler uses the same options for all of the strongarm* tune options
>> anyway:

All strongarm devices are being treated equally again:
e5a4ea76d9c872b195ecd4a8b3cf6e2c49849d72

mtn disapprove

[Koen Kooi]

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

~From the commit messages:

- --
Zaurus machine config: fix code for creation of installkit for collie
* remove the code from collie config.  It is present in collie-2.6.inc
- --

That is factually correct, however instead of collie-2.6.inc you mean
zaurus-2.6.inc. Lets see:

koen@bitbake:~/OE/.dev/conf/machine$ grep require collie.conf
require conf/machine/include/collie-${MACHINE_KERNEL_VERSION}.inc
require conf/machine/include/tune-strongarm.inc
koen@bitbake:~/OE/.dev/conf/machine$ grep include collie.conf
require conf/machine/include/collie-${MACHINE_KERNEL_VERSION}.inc
require conf/machine/include/tune-strongarm.inc
koen@bitbake:~/OE/.dev/conf/machine$ grep require include/collie-2.*
koen@bitbake:~/OE/.dev/conf/machine$ grep include include/collie-2.*
koen@bitbake:~/OE/.dev/conf/machine$

Collie doesn't include zaurus-2.6.inc, which is why I added the code to
collie-2.6.inc a while ago so it would actually make an installkit,
which you broke now. Since I want an installkit (I wrote the installkit
code for that reason) I disapproved that commit.


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

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

iD8DBQFHhxxxMkyGM64RGpERAjMwAJ9hLuwaCm7LczNWhE6ZxfGuOTeP2wCfUlDB
QSKivkNms6TjC/7CFL2g43g=
=TAlG
-----END PGP SIGNATURE-----

Re: mtn disapprove

[Rolf Leggewie]

Koen Kooi schrieb:
> however instead of collie-2.6.inc you mean zaurus-2.6.inc.

of course.  Sorry about the glitch.  I believe I have made the correct
change in 6794aa0dd1ca646be71cc57651a883ac99f55985, now.  Thanks for
spotting it.

While we are at it, let's try and clean the situation up a bit.

* Is there any reason not to let zaurus-2.6.inc do what it suggests to
  be doing and delegate all clamshell stuff to zaurus-clamshell.inc?
  poodle.conf already requires zaurus-2.6.inc despite not being a
  clamshell model.  Let's make the changes necessary so that collie
  can require it as well and then delete the double entry for the
  installkit code from collie-2.6.inc.
* I am pretty sure the poodle line in collie.conf is incorrect.
* poodle-2.6.inc seems to be unused, can it be dropped?

Koen, are these basically sane proposals?  If so, I would prepare an mtn
diff for inspection before committing.

Regards

Rolf

Re: mtn disapprove

[Koen Kooi]

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

Rolf Leggewie schreef:
| Koen Kooi schrieb:
|> however instead of collie-2.6.inc you mean zaurus-2.6.inc.
|
| of course.  Sorry about the glitch.  I believe I have made the correct
| change in 6794aa0dd1ca646be71cc57651a883ac99f55985, now.  Thanks for
| spotting it.
|
| While we are at it, let's try and clean the situation up a bit.
|
| * Is there any reason not to let zaurus-2.6.inc do what it suggests to
|   be doing and delegate all clamshell stuff to zaurus-clamshell.inc?
|   poodle.conf already requires zaurus-2.6.inc despite not being a
|   clamshell model.  Let's make the changes necessary so that collie
|   can require it as well and then delete the double entry for the
|   installkit code from collie-2.6.inc.
| * I am pretty sure the poodle line in collie.conf is incorrect.
| * poodle-2.6.inc seems to be unused, can it be dropped?
|
| Koen, are these basically sane proposals?

It's the thing I had in mind, but never worked up the motivation of
doing :) Copy/pasting it into collie-2.6.conf was never meant as a
long-term solution.

| If so, I would prepare an mtn diff for inspection before committing.

Yeah, since Richard and Marcin need to see it first.

regards

Koen

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

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

iD8DBQFHhysaMkyGM64RGpERAk+CAJ0byZDw9/ChfIX8ix0rIgiOMYsO/wCgksb1
se8EgVkLjsnEppGQbCa7rzI=
=BeZ2
-----END PGP SIGNATURE-----

Re: mtn disapprove

[Rolf Leggewie]

Koen Kooi schrieb:
> It's the thing I had in mind, but never worked up the motivation of
> doing :)

OK, here it is: http://oz.leggewie.org/wip/machine-config.diff

* drop unused poodle-2.6.inc
* work contents of collie-2.6.inc into collie.conf
* require zaurus-2.6.inc for collie.conf
* deleted entries from collie.conf that seem superfluous
* made some changes to zaurus-2.6.inc to make sure it applies
  to all Zaurus models
* define SERIAL_CONSOLE in zaurus-2.6.inc as ?=

RP and hrw have given their OK.  I have locally committed it as
49cb87ce3fb4d9857d853d9e54f38fa88e9ccc85.  If there are no objections, I
will eventually push it.

Re: mtn disapprove

[Rolf Leggewie]

It seems this solution is not yet perfect.  All of the sudden, bitbake
cooks up an armv5te version of libogg for the collie.  My suspicion is
that this has to do with PACKAGE_EXTRA_ARCHS.

What does PACKAGE_EXTRA_ARCHS do?  If set to "armv4 armv4t armv5e
armv5te", can that provide problems for a device like the collie which
is arm-only, not armv5te?  How about the poodle?  Is that device and all
other Zaurus safe with "armv4 armv4t armv5e armv5te"?

If my suspicion is true, my suggestion for Zaurus-2.6.inc is

-PACKAGE_EXTRA_ARCHS = "armv4 armv4t armv5e armv5te"
+PACKAGE_EXTRA_ARCHS ?= "armv4 armv4t armv5e armv5te"
+PACKAGE_EXTRA_ARCHS_collie = ""

Re: mtn disapprove

[Koen Kooi]

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

[I can't type, so resending]

Rolf Leggewie schreef:
| It seems this solution is not yet perfect.  All of the sudden, bitbake
| cooks up an armv5te version of libogg for the collie.  My suspicion is
| that this has to do with PACKAGE_EXTRA_ARCHS.
|
| What does PACKAGE_EXTRA_ARCHS do?

It telss ipkg(-collateral) which architectures the device can use (IOW:
what to put in /etc/ipkg/arch.conf).

| If set to "armv4 armv4t armv5e
| armv5te", can that provide problems for a device like the collie which
| is arm-only, not armv5te?

Yes, since it will allow users (and do_rootfs) to install binaries that
won't work.

|  How about the poodle?

poodle is armv5te (pxa25x xscale), collie is armv4 (sa1100 strongarm)

| Is that device and all
| other Zaurus safe with "armv4 armv4t armv5e armv5te"?
|
| If my suspicion is true, my suggestion for Zaurus-2.6.inc is

It isn't, the culprit is:

zaurus-2.6.inc:include conf/machine/include/tune-xscale.inc

regards,

Koen

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

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

iD8DBQFHh8GUMkyGM64RGpERAl3CAJsG3qi/IKbGdoqWGYpWmyD4uteKfQCeJ7b6
S80GSWd6Ls+nKfDfODxzQiM=
=kt3d
-----END PGP SIGNATURE-----

Re: mtn disapprove

[Rolf Leggewie]

Koen Kooi schrieb:
> | If my suspicion is true, my suggestion for Zaurus-2.6.inc is
> 
> It isn't, the culprit is:
> 
> zaurus-2.6.inc:include conf/machine/include/tune-xscale.inc

Thanks for the quick turnaround on this insightful comments.

I will then move above line out of zaurus-2.6.inc and into poodle.conf,
zaurus-clamshell.inc and tosa.conf and everything should be alright, or
did I forget an Xscale non-clamshell modell?

Re: mtn disapprove

[Thomas Kunze]

> I will then move above line out of zaurus-2.6.inc and into poodle.conf,
> zaurus-clamshell.inc and tosa.conf and everything should be alright, or
> did I forget an Xscale non-clamshell modell?

I would also move the PACKAGE_ARCH stuff.

Regards,
Thomas

Re: mtn disapprove

[Rolf Leggewie]

Thomas,

thank you for your suggestion.  Please correct me if I misunderstand you.

Thomas Kunze schrieb:
> I would also move the PACKAGE_ARCH stuff.

You suggest to move the PACKAGE_ARCH stuff out of the inc file and into
the individual config files?  For what benefit?  They are common for all
machines except for the collie, so I believe .inc is the best place for
that.

Regards

Rolf

Re: mtn disapprove

[Thomas Kunze]

On Sat, 2008-01-12 at 11:39 +0100, Rolf Leggewie wrote:
> Thomas,
> 
> thank you for your suggestion.  Please correct me if I misunderstand you.
> 
> Thomas Kunze schrieb:
> > I would also move the PACKAGE_ARCH stuff.
> 
> You suggest to move the PACKAGE_ARCH stuff out of the inc file and into
> the individual config files?  For what benefit?  They are common for all
> machines except for the collie, so I believe .inc is the best place for
> that.
The same is true for "include tune-xscale.inc". So one could use
include_collie (if this is possible). But the other way is IMO cleaner.
Have only things in zaurus-2.6.inc that are common to all zaurus. OTOH
it may make sense to separate collie from the other zaurus because
collie doesn't have much in common with them.

> 
> Regards
> 
> Rolf
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: mtn disapprove

[Rolf Leggewie]

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.

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
* 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.

Re: 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@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

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

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

Re: mtn disapprove

[Florian Boor]

Hi,

Koen Kooi schrieb:

> I suspect spamassassin.

I don't think so. It is installed on the box but is not hooked up into the mail
system.

> | 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.

Yes right, same for all iPAQ h36xx, h37xx and h38xx and some Jornada models.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: mtn disapprove

[Rolf Leggewie]

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

Thank you for your continued helpful comments.  I shall continue to look
into this further.

Re: mtn disapprove

[Rolf Leggewie]

Rolf Leggewie schrieb:
> OK, here it is: http://oz.leggewie.org/wip/machine-config.diff

updated

Re: mtn disapprove

[ohviey1]

The server at xorg.freedesktop.org is taking too long to respond.

I try a lot this morning i don't have firewall or proxy in my lan 
possible the server change the repository to download sameone could try 
to download 
http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.3.tar.bz2 
this package plz and tell me if it' ok or is only my problem?
 
i try to go in http://freedesktop.org and it's ok but the download don't 
start

tnx Stefano