All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: ARM tunings was Re: [PATCH 3/7] conf/machine/include: Cleanup MIPS tunings to match README
Date: Mon, 9 Apr 2012 16:21:17 -0500	[thread overview]
Message-ID: <4F8352CD.7070500@windriver.com> (raw)
In-Reply-To: <1334005382.3382.10.camel@x121e.pbcl.net>

On 4/9/12 4:03 PM, Phil Blundell wrote:
> On Mon, 2012-04-09 at 15:25 -0500, Mark Hatle wrote:
>> And just to be extra clear, I consider it a defect if we can produce a package
>> with the same name for two different tune settings.. (the exception being the
>> hell that is ARM and thumb namings.)
>
> While you might consider that a defect (and it probably is a defensible
> position to do so), it hasn't historically been considered such in OE.
> The PACKAGE_ARCH value has, traditionally, been concerned purely with
> ISA and ABI (i.e. answering the question "can I execute this code?")
> rather than optimisations.
>
> For example, the tune-arm926ejs.inc and tune-xscale.inc files in current
> oe-core both end up setting PACKAGE_ARCH to "armv5tte" (sic).  But those
> are quite different processors and have different tuning requirements,
> so the binaries you get are unlikely to be the same.  If you were to
> take the view that the PACKAGE_ARCH must uniquely identify one set of
> binaries then obviously each of these tunings (and probably all the ARM
> cpu-specific tunings) would need to set PACKAGE_ARCH to some unique
> value.

I do, and thus the hell that is ARM.  I could not currently generate a single 
package feed that work would on a variety of devices (like a traditional 
workstaton/server Linux OS would.)  While this isn't a big issue in the embedded 
space where we should hopefully be aware of the tunings and configuration were 
are using, it is still a problem.  As the systems get larger, the requirement 
for common pages feeds increases, leading to the problem being, well a problem. 
  (ARM is starting to be considered for Carrier Grade systems, many of which 
have very common requirements to traditional server Linux.  A set of established 
binaries and the vendors just want to drop in optimized applications.)

On ARM what we currently have defined is:
(tune) - (package arch)

arm1136jfs - armv6-vfp
arm920t - armv4t
arm926ejs - armv5te
arm9tdmi - armv4t
armv4b - armv4b
armv4tb - armv4tb
armv4 - armv4
armv4t - armv4t
armv5b - armv5b
armv5b-vfp - armv5b-vfp
armv5eb - armv5eb
armv5eb-vfp - armv5eb-vfp
armv5ehfb-vfp - armv5ehfb-vfp
armv5ehf-vfp - armv5ehf-vfp
armv5e-vfp - armv5e-vfp
armv5hfb-vfp - armv5hfb-vfp
armv5hf-vfp - armv5hf-vfp
armv5tb - armv5tb
armv5tb-vfp - armv5b-vfp
armv5teb - armv5teb
armv5teb-vfp - armv5teb-vfp
armv5tehfb-vfp - armv5tehfb-vfp
armv5tehf-vfp - armv5tehf-vfp
armv5te - armv5te
armv5te-vfp - armv5te-vfp
armv5thfb-vfp - armv5hfb-vfp
armv5thf-vfp - armv5hf-vfp
armv5 - armv5
armv5t - armv5t
armv5t-vfp - armv5-vfp
armv5-vfp - armv5-vfp
armv6b - armv6b-vfp
armv6hfb - armv6hfb-vfp
armv6hf - armv6hf-vfp
armv6tb - armv6tb-vfp
armv6thfb - armv6thfb-vfp
armv6thf - armv6thf-vfp
armv6 - armv6-vfp
armv6t - armv6t-vfp
armv7ab-neon - armv7ab-vfp-neon
armv7ab - armv7ab-vfp
armv7ahfb-neon - armv7ahfb-vfp-neon
armv7ahfb - armv7ahfb-vfp
armv7ahf-neon - armv7ahf-vfp-neon
armv7ahf - armv7ahf-vfp
armv7a-neon - armv7a-vfp-neon
armv7atb-neon - armv7ab-vfp-neon
armv7atb - armv7ab-vfp
armv7athfb - armv7ahfb-vfp
armv7athf-neon - armv7ahf-vfp-neon
armv7athf - armv7ahf-vfp
armv7a - armv7a-vfp
armv7at-neon - armv7a-vfp-neon
armv7at - armv7a-vfp
cortexa8hf-neon - armv7ahf-vfp-neon
cortexa8hf - armv7ahf-vfp
cortexa8-neon - armv7a-vfp-neon
cortexa8thf - armv7ahf-vfp
cortexa8 - armv7a-vfp
cortexa8t - armv7a-vfp
cortexa9hf-neon - armv7ahf-vfp-neon
cortexa9hf - armv7ahf-vfp
cortexa9-neon - armv7a-vfp-neon
cortexa9thf - armv7ahf-vfp
cortexa9 - armv7a-vfp
cortexa9t - armv7a-vfp
cortexm1 - armv7a-vfp
cortexm3 - armv7m-vfp
cortexr4 - armv7r-vfp
ep9312 - ep9312
iwmmxt - iwmmxt
strongarm - armv4

Add in to that one of the tunings -- not indicated by the package arch of thumb 
enabled or not, and its difficult to know exactly what is in a package without 
extracting and examining it.  But I consider this to be a quirk of the ARM 
architecture as implemented in OE.

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




  reply	other threads:[~2012-04-09 21:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 19:47 [PATCH 0/7] Cleanup and document tuning files Mark Hatle
2012-04-03 19:47 ` [PATCH 1/7] conf/machine/include/README: Add readme to explain cpu tunings Mark Hatle
2012-04-04  0:40   ` Chris Larson
2012-04-04  1:58   ` Otavio Salvador
2012-04-03 19:47 ` [PATCH 2/7] conf/machine/include: Cleanup IA tunings to match README Mark Hatle
2012-04-03 19:47 ` [PATCH 3/7] conf/machine/include: Cleanup MIPS " Mark Hatle
2012-04-03 19:51   ` Phil Blundell
2012-04-03 19:57     ` Mark Hatle
2012-04-04 22:10   ` Andreas Oberritter
2012-04-05  4:17     ` Khem Raj
2012-04-06 17:33       ` Mark Hatle
2012-04-06 21:30         ` Khem Raj
2012-04-07  0:10           ` Mark Hatle
2012-04-08 21:34             ` Andreas Oberritter
2012-04-09 15:17               ` Mark Hatle
2012-04-09 15:56                 ` Koen Kooi
2012-04-09 16:03                   ` Mark Hatle
2012-04-09 20:06                 ` Andreas Oberritter
2012-04-09 20:25                   ` Mark Hatle
2012-04-09 20:51                     ` Andreas Oberritter
2012-04-09 21:00                     ` Mark Hatle
2012-04-09 21:03                     ` Phil Blundell
2012-04-09 21:21                       ` Mark Hatle [this message]
2012-04-09 21:30                         ` ARM tunings was " Phil Blundell
2012-04-09 21:44                           ` Mark Hatle
2012-04-10  9:23                             ` Phil Blundell
2012-04-10 17:39                               ` Mark Hatle
2012-04-10 19:33                                 ` Phil Blundell
2012-04-09 22:19                     ` Khem Raj
2012-04-03 19:47 ` [PATCH 4/7] conf/machine/include: Cleanup PowerPC " Mark Hatle
2012-04-04 18:02   ` Matthew McClintock
2012-04-04 19:57     ` Mark Hatle
2012-04-04 18:03   ` Matthew McClintock
2012-04-04 19:59     ` Mark Hatle
2012-04-03 19:47 ` [PATCH 5/7] conf/machine/include: Cleanup ARM " Mark Hatle
2012-04-03 19:47 ` [PATCH 6/7] conf/machine/include: Update SH " Mark Hatle
2012-04-03 19:47 ` [PATCH 7/7] binutils: Inform binutils that armv5e really is valid! Mark Hatle
2012-04-07  8:03   ` Khem Raj
2012-04-04 16:59 ` [PATCH 0/7 v2] Cleanup and document tuning files Saul Wold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8352CD.7070500@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.