summaryrefslogtreecommitdiffstats
path: root/meta/conf/machine/include/arm/arch-arm.inc
Commit message (Collapse)AuthorAgeFilesLines
* conf/machine/include: Cleanup ARM tunings to match READMEMark Hatle2012-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | Cleanup the ARM tunings to match the new tunings README file. The ARM tunings define TUNE_PKGARCH in a way that only one main arm architecture, i.e. armv6, may be defined at the same time. We may have to revise these settings in the future, as well as figure out a way to better differentiate various optimize tunings in the package arch. (This was not done, to preserve existing behavior!) Fix a number of minor issues w/ the armv5 tunings where DSP variants were referenced but not defined. Fix incorrect armv7 entries in armv7a. Fix PACKAGE_EXTRA_ARCHS definitions inside of tune-cortexm3 and tune-cortexr4. (From OE-Core rev: 0e71abea5458122188d5eddef2c17147f61ff895) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add ARM tune file overhaul based largely on work from Mark HatleRichard Purdie2011-07-271-1/+15
| | | | | | (From OE-Core rev: 789dcb8e68a2ab9784ac10ab36815010c61af2fc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Move architecture specific TARGET_OS mangling into tune filesRichard Purdie2011-07-251-0/+2
| | | | | | (From OE-Core rev: f10a3457cdfbb4a94978da998d178d4254632fa7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* conf/machine/include: Start to fill out architecture specific tune include ↵Richard Purdie2011-07-251-0/+1
files and tune features These changes revolve around the idea of tune features. These are represented by 'flag' strings that are included in the TUNE_FEATURES variable. Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so we can know which flags are available in TUNE_FEATURES and have documentation about what the flags do. We will add sanity code to error if flags are listed in TUNE_FEATURES but are not documented in TUNEVALID. A given tune configuration will want to define one or more predetermined sets of _FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>. For defined tune configuation, <name> should be added to the AVAILTUNE list so that we can determine what tune configurations are available. Flags cannot be used in this case as with TUNEVALID since its useful to be able to build up tune lists from other TUNE_FEATURES_tune-yyy options. A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and BASE_LIB_tune-<name> to control the multilib location. All options can be overridden by the distro or local user configuration. (From OE-Core rev: 5f9d56bd64997b93ed7e46c117851002a0556654) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>