openembedded-core.git/meta/conf/machine/include/tune-core2.inc, branch fido

tune: Make 32b or 64b explicit in tune name for core2

2014-01-28T00:48:22+00:00

Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume "corei7" meant 64 bit.

Rather than carrying forward an implicit 32b mode and rather than
changing the naming scheme part way through the architecture hiearchy,
make the 32b and 64b variant explicit in the tune name by changing core2
to core2-32. This patch also standardises on using '-' in the names.

Signed-off-by: Darren Hart 
Cc: Richard Purdie 
Cc: Paul Eggleton 
Cc: Tom Zanussi 
Cc: Nitin Kamble 
Cc: Mark Hatle 
Cc: Bruce Ashfield 
Cc: Martin Jansa 
Signed-off-by: Richard Purdie

tune-core2: Only add the current ARCH to PACKAGE_EXTRA_ARCHS

2014-01-28T00:48:22+00:00

Inherit the PACKAGE_EXTRA_ARCHS from i586 and only explicitly add core2
here.

Signed-off-by: Darren Hart 
Cc: Richard Purdie 
Cc: Paul Eggleton 
Cc: Tom Zanussi 
Cc: Nitin Kamble 
Cc: Mark Hatle 
Cc: Bruce Ashfield 
Cc: Martin Jansa 
Signed-off-by: Richard Purdie

tune-core2: Replace -mtune=generic with -mtune=core2

2014-01-28T00:48:22+00:00

-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type specific ISA, but order the instructions
generically. While the -mtune is implied by -march, gcc does not verify
it is using -mtune=core2 with:

    gcc -Q -march=core2 --help=target

Explicitly specify -mtune=core2 to be sure.

Add a comment header describing the CPUs targeted by this tune file.

Signed-off-by: Darren Hart 
Cc: Richard Purdie 
Cc: Paul Eggleton 
Cc: Tom Zanussi 
Cc: Nitin Kamble 
Cc: Mark Hatle 
Cc: Bruce Ashfield 
Cc: Martin Jansa 
Signed-off-by: Richard Purdie

conf/machine: use .= instead of += in TUNE_CCARGS

2013-04-29T13:43:50+00:00

* number of TUNE_CCARGS conditionals is important if we add
  extra space with each one in "else" branch

  I'm building for 2 MACHINEs one is cortexa9, second is cortexa8

  few months ago we added TUNE_CCARGS[vardepvalue] in bitbake.conf
  http://git.openembedded.org/openembedded-core/commit/?id=03f1e34ea3ce80931e9c3cd2ab22824f28a7233b

  which fixed some cases (like mentioned tune-xscale and tune-arm926ejs)
  where both had unused TUNE_CCARGS when common DEFAULTTUNE was used.

  with cortexa[89] it's different, because cortexa9 has one extra TUNE_CCARGS
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex-a9", "", d)}"
  which adds extra *space* even when not used because of '+=' and as result:

  $ bitbake-diffsigs tmp-eglibc/sstate-diff/1366797730/*/armv7*/adapterbase/*do_configure*
  basehash changed from f986789fb8fb3579ed6a3492cc8a8d10 to c851b5f838d945ee13072e9ad6725dca
  Variable TUNE_CCARGS value changed from
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon '
  to
  ' -march=armv7-a     -mthumb-interwork -mfloat-abi=softfp -mfpu=neon  '
  Hash for dependent task gcc-runtime_4.7.bb.do_populate_sysroot changed from bdeabf7a86958b9110b566344b7916de to 2be5618e6bc8c57ec9db5659bf217915
  Hash for dependent task eglibc_2.17.bb.do_populate_sysroot changed from b4f40fc62dde684acd0a574532a55360 to 97fcb426603d4a1c1099c0504d2ebf7d
  Hash for dependent task glib-2.0_2.34.3.bb.do_populate_sysroot changed from fd2f90b83098c34e88d649d70f6ea4f5 to ebd740bb94ea3eb0a914efda6fc82c4a

Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold

conf/machine/include: Cleanup IA tunings to match README

2012-04-04T16:01:30+00:00

We perform a basic cleanup of the IA32 architecture and related
tunings in order to match the rules and descriptions within the
new tuning README file.

A number of small issues were corrected in the "c3" tuning to
bring it inline with the README.

Signed-off-by: Mark Hatle

x86 tune: fix TUNE_PKGARCH definition for proper PACKAGE_ARCH

2011-12-12T21:50:09+00:00

rpmbuild can not handle the PACKAGE_ARCH of these kinds:
	x86_64-x32, core2-64, core2-64-x32

With these kinds of PACKAGE_ARCH the --target parameter of rpmbuild
becomes like: core2-64-x32-poky-linux-gnux32 ; And rpmbuild extracts
%_target (arch) wrongly as core2 generating these kinds of rpms with
incorrect filenames: zip-3.0-r0.core2.rpm

So this commit fixes the issue by making PACKAGE_ARCH like this:
	x86_64_x32, core2_64, core2_64_x32
Now --target parameter of rpmbuild becomes like:
core2_64_x32-poky-linux-gnux32 ; And rpmbuild extracts %_target (arch)
correctly as core2_64_x32 generating these kinds of rpms with correct
filenames: zip-3.0-r0.core2_64_x32.rpm

Signed-off-by: Nitin A Kamble

x86 tune files: set baselib for x32 tune as libx32

2011-10-20T12:06:39+00:00

This ensures that on a multilib system the two executable formats
don't conflict.

Signed-off-by: Nitin A Kamble

x86 tune inc files: add x32 abi tune parameters

2011-08-08T17:05:02+00:00

Signed-off-by: Nitin A Kamble

tune-core2.inc: Drop X86ARCH32 usage

2011-07-27T09:34:35+00:00

Using i686 doesn't work well with locale generation and doesn't gain anything
so revert to the i586 default.

Signed-off-by: Richard Purdie

arch-ia32.inc: Fix up TUNE_ARCH variable conflicts

2011-07-26T21:39:49+00:00

The current approach causes duplicate values to appear in the TUNE_ARCH
field and this patch addresses that.

Signed-off-by: Richard Purdie