OPTDEFAULTTUNE for arm tune files
cover OPTDEFAULTTUNE for arm tune files
This patchset is just RFC because I've modified and tested it only for tune-arm926ejs and tune-xscale (because I've tried to build qemuarm and same builddir).
Also I have no strong opinion about used TUNE as suffix (see 1. patch) or as ARMPKGARCH (see last patch, which reverts most of 1. patch).
And what's even bigger mess are PACKAGE_EXTRA_ARCHS, because to be correct we should repeat all tune-armv5te variations with xscale prefix/suffix too, while most people will have only
armv5te and (armv5te-xscale or xscale-te)
current tune files allow also armv4t-xscale etc...
But FWIW with this patchset I can build openssl for qemuarm and qemuarmx, everything except openssl is shared and built just once and also just once in feed.
qemuarmx is the same like qemuarm but using tune-xscale, see
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu-tests
If we decide this is right way to fix it then it should be extended to all arm tune files. And also somehow set default DEFAULTTUNE to OPTDEFAULTTUNE if PACKAGE_ARCH == MACHINE_ARCH (in this case we know we won't share the feed, so why use best mtune available).
This allows finer control of which DEFAULTTUNE to use
1) default: don't use mtune, optimize only for march (don't mix mtune in the same feed).
2) include optimized-tune.inc in distro.conf: use mtune only for some packages, but with separate package feed for them
3) DEFAULTTUNE = ${OPTDEFAULTTUNE} in distro.conf: always use best mtune available for MACHINE, but unlike current default, don't mix them in same package feed
More info in thread:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029414.html
The following changes since commit 5e03d1e83d0536a2fc69a88d3e5407108836203f:
gcc: Use 4.7.2 release tarball (2012-09-21 14:55:26 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/tune
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/tune
Martin Jansa (5):
arch-arm: add ARMPKGSFX_CPU to TUNE_PKGARCH because we're using
different TUNE_CCARGS
tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more
generic DEFAULTTUNE as default
optimized-tune.inc: add optional distro include bitbake.conf: add TUNE_CCARGS[vardepvalue]
tune-xscale, tune-arm926ejs: drop ARMPKGSFX_CPU, change ARMPKGARCH
instead
meta/conf/bitbake.conf | 2 ++ meta/conf/distro/include/optimized-tune.inc | 2 ++ meta/conf/machine/include/tune-arm926ejs.inc | 7 ++++--- meta/conf/machine/include/tune-xscale.inc | 8 +++++--- 4 files changed, 13 insertions(+), 6 deletions(-) create mode 100644 meta/conf/distro/include/optimized-tune.inc
Signature · 1 line
1.7.12
RFC 1/5 arch-arm: add ARMPKGSFX_CPU to TUNE_PKGARCH because we're using different TUNE_CCARGS
* without this tune-xscale and tune-arm926ejs were both creating packages in armv5te feed, but each with different -mtune, with OEBasicHash enabled it was causing each package to rebuild with new -mtune after MACHINE switch, but that doesn't make sense with output stored in the same armv5te feed
* this makes different feed for each -mtune/ARMPKGSFX_CPU
--- meta/conf/machine/include/arm/README | 5 ++++- meta/conf/machine/include/arm/arch-arm.inc | 4 +++- meta/conf/machine/include/tune-arm926ejs.inc | 4 ++-- meta/conf/machine/include/tune-xscale.inc | 5 +++-- 4 files changed, 12 insertions(+), 6 deletions(-)
meta/conf/machine/include/arm/README +4 -1
@@ -16,7 +16,7 @@ default. The format must be of the form: <armversion>[t][e][hf][b][-vfp][-neon] TUNE_PKGARCH is defined as: -${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU} +${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU} ARMPKGARCH - This is the core package arch component specified by each tuning. This is the primary identifier of a tuning. Usual values are:
@@ -38,3 +38,6 @@ the core arch-arm.inc file. ARMPKGSFX_FPU - This is the FPU specific suffix. The suffix indicates specific FPU optimizations. 'vfp' and 'neon' are both defined. + +ARMPKGSFX_CPU - This is the CPU specific suffix. The suffix indicates +that specific CPU optimizations were used.
meta/conf/machine/include/arm/arch-arm.inc +3 -1
@@ -4,12 +4,14 @@ TUNEVALID[bigendian] = "Enable big-endian mode." ARMPKGARCH ??= "arm" ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}" ARMPKGSFX_FPU ??= "" +ARMPKGSFX_CPU ??= "" +ARMPKGSFX_CPU[vardepvalue] = "${ARMPKGSFX_CPU}" ARMPKGSFX_DSP ??= "" ARMPKGSFX_EABI ??= "" ARMPKGSFX_THUMB ??= "" TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}" -TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" +TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}" ABIEXTENSION = "eabi"
meta/conf/machine/include/tune-arm926ejs.inc +2 -2
@@ -1,4 +1,5 @@ DEFAULTTUNE ?= "arm926ejs" +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
@@ -7,5 +8,4 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm92 AVAILTUNES += "arm926ejs" TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" -PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" - +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-arm926ejs"
meta/conf/machine/include/tune-xscale.inc +3 -2
@@ -1,4 +1,5 @@ DEFAULTTUNE ?= "xscale" +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
@@ -7,11 +8,11 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", AVAILTUNES += "xscale" TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" -PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-xscale" AVAILTUNES += "xscale-be" TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian" -PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" +PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} armv5teb-xscale" # webkit-gtk has alignment issues with double instructions on armv5 so # disable them here
Signature · 1 line
1.7.12
RFC 2/5 tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
In reply to Martin Jansa* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).
--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +1 -0
@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = "" +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""
meta/conf/machine/include/tune-arm926ejs.inc +2 -1
@@ -1,4 +1,5 @@ -DEFAULTTUNE ?= "arm926ejs" +DEFAULTTUNE ?= "armv5te" +OPTDEFAULTTUNE ?= "arm926ejs" ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
meta/conf/machine/include/tune-xscale.inc +2 -1
@@ -1,4 +1,5 @@ -DEFAULTTUNE ?= "xscale" +DEFAULTTUNE ?= "armv5te" +OPTDEFAULTTUNE ?= "xscale" ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
Signature · 1 line
1.7.12
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 18 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 7 lines
meta/conf/bitbake.conf +1
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = "" +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""
As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Cheers,
Richard
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""
Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different TUNE_CCARGS?
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?
I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
The only concern I have with that is:
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right ARMPKGSFX_CPU will be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.
I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.
--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 46 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
Quoted 7 lines
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...
OK.
Quoted 3 lines
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale?
Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update would try to download many feeds but only a few does exist).
Quoted 25 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
Quoted 6 lines
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
Yes but first I have to say:DEFAULTTUNE_spitz = armv5teOPTDEFAULTTUNE_spitz = xscaleDEFAULTTUNE_qemuarm = armv5teOPTDEFAULTTUNE_qemuarm = arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5teOPTDEFAULTTUNE_tun_xscale = xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's not in defined tune-xscale/tune-arm926ejs.
And that's what I didn't want to include in my distro config (and then explaining to someone that when adding MACHINE foo he has to send patch for distro config).
Cheers,
Quoted 20 lines
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 63 lines · Martin Jansa
Quoted 46 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
Quoted 7 lines
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...OK.
Quoted 3 lines
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
Quoted 7 lines
But not sure what to do with all "lower"
PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale?Well whole
PACKAGE_EXTRA_ARCHShas too many entries already (opkg update would try to download many feeds but only a few does exist).
The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what the PACKAGE_EXTRA_ARCHS value should be.)
Quoted 43 lines
Quoted 25 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
Quoted 6 lines
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
Yes but first I have to say:
DEFAULTTUNE_spitz= armv5teOPTDEFAULTTUNE_spitz= xscaleDEFAULTTUNE_qemuarm= armv5teOPTDEFAULTTUNE_qemuarm= arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5teOPTDEFAULTTUNE_tun_xscale= xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
Quoted 2 lines
to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's not in defined tune-xscale/tune-arm926ejs.
I assume that a distribution will be (bb)appending, or defining their own BSPs.
And in that case it's pretty easy to add both the DEFAULTTUNE and
OPTDEFAULTTUNE line to the BSP configuration file. (And if someone uses a different distribution, then the DEFAULT is used as that is the standard method.)
Quoted 3 lines
And that's what I didn't want to include in my distro config (and then explaining to someone that when adding MACHINE foo he has to send patch for distro config).
Ya I understand. This is an odd situation for many embedded systems. You want to reuse packages that aren't optimally tuned -- but you still want a few tuned packages. It's certainly a usecase we need to support -- but I'm not sure in the end how people end up doing this.
I know most of my commercial customers just want everything to be tuned for the target BSP.. and they build new distributions for each product they implement.
--Mark
Quoted 23 lines
Cheers,
Quoted 20 lines
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 72 lines · Mark Hatle
Quoted 63 lines · Martin Jansa
Quoted 46 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
Quoted 7 lines
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...OK.
Quoted 3 lines
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
Quoted 7 lines
But not sure what to do with all "lower"
PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale?Well whole
PACKAGE_EXTRA_ARCHShas too many entries already (opkg update would try to download many feeds but only a few does exist).
Quoted 7 lines
The
PACKAGE_EXTRA_ARCHSshould contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what thePACKAGE_EXTRA_ARCHSvalue should be.)
Yes that's what I do now, but I'm not too happy about it :/ SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64 x86" SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon" SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"
Quoted 43 lines
Quoted 43 lines
Quoted 25 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
Quoted 6 lines
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
Yes but first I have to say:
DEFAULTTUNE_spitz= armv5teOPTDEFAULTTUNE_spitz= xscaleDEFAULTTUNE_qemuarm= armv5teOPTDEFAULTTUNE_qemuarm= arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5teOPTDEFAULTTUNE_tun_xscale= xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
Quoted 7 lines
Quoted 2 lines
to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's not in defined tune-xscale/tune-arm926ejs.
I assume that a distribution will be (bb)appending, or defining their own BSPs.
And in that case it's pretty easy to add both the DEFAULTTUNE and
OPTDEFAULTTUNE line to the BSP configuration file. (And if someone uses a different distribution, then the DEFAULT is used as that is the standard method.)
Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in oe-core?
Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE then everybody else (who is interested in my BSP but has own distro) needs to agree on name OPTDEFAULTTUNE.
That's why I wanted this defined in tune-* files which are shared in oe-core and used by everybody I guess.
Quoted 11 lines
Quoted 3 lines
And that's what I didn't want to include in my distro config (and then explaining to someone that when adding MACHINE foo he has to send patch for distro config).
Ya I understand. This is an odd situation for many embedded systems. You want to reuse packages that aren't optimally tuned -- but you still want a few tuned packages. It's certainly a usecase we need to support -- but I'm not sure in the end how people end up doing this.
I know most of my commercial customers just want everything to be tuned for the target BSP.. and they build new distributions for each product they implement.
Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both use cases to coexist without any complex configuration on distro side.
Thanks again for constructive comment.
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 132 lines · Martin Jansa
Quoted 72 lines · Mark Hatle
Quoted 63 lines · Martin Jansa
Quoted 46 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
Quoted 7 lines
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...OK.
Quoted 3 lines
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
Quoted 7 lines
But not sure what to do with all "lower"
PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale?Well whole
PACKAGE_EXTRA_ARCHShas too many entries already (opkg update would try to download many feeds but only a few does exist).Quoted 7 lines
The
PACKAGE_EXTRA_ARCHSshould contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what thePACKAGE_EXTRA_ARCHSvalue should be.)Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS?= "armv4t armv5te armv6-novfp armv7a-vfp-neonx86_64x86"SUPPORTED_EXTRA_ARCHS_armv7a?= "armv7a-vfp-neon"SUPPORTED_EXTRA_ARCHS_armv6?= "armv6-novfp"Quoted 46 lines
Quoted 45 lines
Quoted 25 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
Quoted 6 lines
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
Yes but first I have to say:
DEFAULTTUNE_spitz= armv5teOPTDEFAULTTUNE_spitz= xscaleDEFAULTTUNE_qemuarm= armv5teOPTDEFAULTTUNE_qemuarm= arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5teOPTDEFAULTTUNE_tun_xscale= xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejsto know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's not in defined tune-xscale/tune-arm926ejs.
Quoted 7 lines
Quoted 4 lines
I assume that a distribution will be (bb)appending, or defining their own BSPs.
And in that case it's pretty easy to add both the DEFAULTTUNE and
OPTDEFAULTTUNE line to the BSP configuration file. (And if someone uses a different distribution, then the DEFAULT is used as that is the standard method.)Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in oe-core?
Sorry, not bbappend in this case.. but you can do it in a distribution layer. (This is from memory so I might not be 100% correct.)
You should be able to have in your own layer a qemuarm.conf that looks like:
require conf/machine/qemuarm.conf
OPTDEFAULTTUNE = "something"
DEFAULTTUNE = "something_else"
It will know not to open itself in the requires.... and fall back to a previous layer.
(If that doesn't work, I know we did it somehow.. since we ran into a similar situation with our product.)
Quoted 6 lines
Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE then everybody else (who is interested in my BSP but has own distro) needs to agree on name OPTDEFAULTTUNE.
That's why I wanted this defined in tune-* files which are shared in oe-core and used by everybody I guess.
I agree completely, this is the downside of doing it int he distro files vs the tune files. But in the end it seems reasonable to make it a machine or distribution setting of some kind.
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
And that's what I didn't want to include in my distro config (and then explaining to someone that when adding MACHINE foo he has to send patch for distro config).
Ya I understand. This is an odd situation for many embedded systems. You want to reuse packages that aren't optimally tuned -- but you still want a few tuned packages. It's certainly a usecase we need to support -- but I'm not sure in the end how people end up doing this.
Quoted 5 lines
Quoted 2 lines
I know most of my commercial customers just want everything to be tuned for the target BSP.. and they build new distributions for each product they implement.
Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both use cases to coexist without any complex configuration on distro side.
Yup, no disagreement there.
--Mark
Quoted 4 lines
Thanks again for constructive comment.
Cheers,
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 150 lines · Mark Hatle
Quoted 132 lines · Martin Jansa
Quoted 72 lines · Mark Hatle
Quoted 63 lines · Martin Jansa
Quoted 46 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
Quoted 7 lines
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...OK.
Quoted 3 lines
I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
Quoted 7 lines
But not sure what to do with all "lower"
PACKAGE_EXTRA_ARCHS:
PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like armv4t-xscale?Well whole
PACKAGE_EXTRA_ARCHShas too many entries already (opkg update would try to download many feeds but only a few does exist).Quoted 7 lines
The
PACKAGE_EXTRA_ARCHSshould contain all of the 'compatible' arch names. Which of course feed into the list of feeds used by the various packaging systems. I think it's up to the distribution to modify or limit the feeds resolved, but I don't know if there is a clean way to do this. I always error on listing more then less, because I don't know how people are going to want to mix and match things. (And a BSP or end user can always just define what thePACKAGE_EXTRA_ARCHSvalue should be.)Yes that's what I do now, but I'm not too happy about it :/
SUPPORTED_EXTRA_ARCHS?= "armv4t armv5te armv6-novfp armv7a-vfp-neonx86_64x86"SUPPORTED_EXTRA_ARCHS_armv7a?= "armv7a-vfp-neon"SUPPORTED_EXTRA_ARCHS_armv6?= "armv6-novfp"Quoted 46 lines
Quoted 45 lines
Quoted 25 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
Quoted 6 lines
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
Yes but first I have to say:
DEFAULTTUNE_spitz= armv5teOPTDEFAULTTUNE_spitz= xscaleDEFAULTTUNE_qemuarm= armv5teOPTDEFAULTTUNE_qemuarm= arm926ejs
or
DEFAULTTUNE_tune-xscale = armv5teOPTDEFAULTTUNE_tun_xscale= xscale
DEFAULTTUNE_tune-arm926ejs = armv5te
OPTDEFAULTTUNE_tune-arm926ejs = arm926ejsto know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's not in defined tune-xscale/tune-arm926ejs.
Quoted 7 lines
Quoted 4 lines
I assume that a distribution will be (bb)appending, or defining their own BSPs.
And in that case it's pretty easy to add both the DEFAULTTUNE and
OPTDEFAULTTUNE line to the BSP configuration file. (And if someone uses a different distribution, then the DEFAULT is used as that is the standard method.)Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in oe-core?
Sorry, not bbappend in this case.. but you can do it in a distribution layer. (This is from memory so I might not be 100% correct.)
You should be able to have in your own layer a qemuarm.conf that looks like:
require
conf/machine/qemuarm.conf
OPTDEFAULTTUNE = "something"
DEFAULTTUNE = "something_else"
Quoted 5 lines
It will know not to open itself in the requires.... and fall back to a previous layer.
(If that doesn't work, I know we did it somehow.. since we ran into a similar situation with our product.)
yes but that's still at least 2 more lines (possibly in separate .conf file) for each MACHINE I could possibly support by my distro, I would like to keep it more universal (or ortogonal in distro/machine/image sense).
Quoted 20 lines
Quoted 6 lines
Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE then everybody else (who is interested in my BSP but has own distro) needs to agree on name OPTDEFAULTTUNE.
That's why I wanted this defined in tune-* files which are shared in oe-core and used by everybody I guess.
I agree completely, this is the downside of doing it int he distro files vs the tune files. But in the end it seems reasonable to make it a machine or distribution setting of some kind.
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
And that's what I didn't want to include in my distro config (and then explaining to someone that when adding MACHINE foo he has to send patch for distro config).
Ya I understand. This is an odd situation for many embedded systems. You want to reuse packages that aren't optimally tuned -- but you still want a few tuned packages. It's certainly a usecase we need to support -- but I'm not sure in the end how people end up doing this.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I know most of my commercial customers just want everything to be tuned for the target BSP.. and they build new distributions for each product they implement.
Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both use cases to coexist without any complex configuration on distro side.
Yup, no disagreement there.
Ok, lets see if this changes RP's view on OPTDEFAULTTUNE.
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
In reply to Mark HatleQuoted 4 lines · Mark Hatle
I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
I think we've discussed this before but, just to reiterate, this sort of thing is a matter of DISTRO policy. It is perfectly legitimate to want to build binaries with, say, -march=armv5te -mtune=arm926ej-s and have them end up with PACKAGE_ARCH="armv5te" or even just "arm".
It seems to me that we are in danger of adding a lot of complicated and hard-to-understand machinery to oe-core in an attempt to solve a problem that ought to be getting solved by the DISTRO, and that by doing so we might be making life harder rather than easier for DISTROs which happen to want a slightly different labelling model to the default.
p.
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 11 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.I think we've discussed this before but, just to reiterate, this sort of thing is a matter of DISTRO policy. It is perfectly legitimate to want to build binaries with, say, -march=armv5te -mtune=arm926ej-s and have them end up with PACKAGE_ARCH="armv5te" or even just "arm".
Quoted 5 lines
It seems to me that we are in danger of adding a lot of complicated and hard-to-understand machinery to oe-core in an attempt to solve a problem that ought to be getting solved by the DISTRO, and that by doing so we might be making life harder rather than easier for DISTROs which happen to want a slightly different labelling model to the default.
That's already there with DEFAULTUNE/AVAILTUNES machinery, isn't it?
Having that with better default values doesn't make things worse for such DISTROs.
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
In reply to Mark HatleQuoted 49 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
Quoted 8 lines
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test
While changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).).
This makes wholeTUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" a bit less usefull, maybe ARMPKGSFX_CPU was better approach..
Cheers,
Quoted 53 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 69 lines · Martin Jansa
Quoted 49 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
Quoted 8 lines
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-testWhile changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like thisTUNE_PKGARCH(${ARMPKGARCH_tune-armv5te}te).).
Quoted 3 lines
This makes whole
TUNE_PKGARCH= "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" a bit less usefull, maybeARMPKGSFX_CPUwas better approach..
I've clarified with RP on this. Tune values are not a 'true' override because of evaluation time of overrides. We want the DEFAULTTUNE to be changeable during the build process to allow multilibs, alternative configurations, etc.
So in the tunes to do override-like implementations, you will need:
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
and then in each tune fragment:
ARMPKGARCH_tune-foo = "bar"
--Mark
Quoted 56 lines
Cheers,
Quoted 53 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 78 lines · Mark Hatle
Quoted 69 lines · Martin Jansa
Quoted 49 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
Quoted 8 lines
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-testWhile changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like thisTUNE_PKGARCH(${ARMPKGARCH_tune-armv5te}te).).Quoted 3 lines
This makes whole
TUNE_PKGARCH= "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" a bit less usefull, maybeARMPKGSFX_CPUwas better approach..I've clarified with RP on this. Tune values are not a 'true' override because of evaluation time of overrides. We want the DEFAULTTUNE to be changeable during the build process to allow multilibs, alternative configurations, etc.
Quoted 7 lines
So in the tunes to do override-like implementations, you will need:
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
and then in each tune fragment:
ARMPKGARCH_tune-foo = "bar"
Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo
Quoted 60 lines
--Mark
Quoted 56 lines
Cheers,
Quoted 53 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [RFC 2/5] tune-xscale, tune-arm926ejs: add OPTDEFAULTTUNE variable and use more generic DEFAULTTUNE as default
Quoted 81 lines · Martin Jansa
Quoted 80 lines · Mark Hatle
Quoted 69 lines · Martin Jansa
Quoted 49 lines · Mark Hatle
Let me preface this by I have read the patch set.. Martin asked me to comment on the items below...
Quoted 32 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
Quoted 21 lines · Martin Jansa
* bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
* this way xscale or arm926ejs is not used by default when some machine includes its tune*.inc, but it's easy for DISTRO to say it wants OPTDEFAULTTUNE for some packages or always (if they don't want to share built packages between xscale and arm926ejs).Signed-off-by Martin Jansa <[email protected]>--- meta/conf/bitbake.conf | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0@@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}" HOST_AS_ARCH = "${TARGET_AS_ARCH}" HOST_EXEEXT = ""Quoted 8 lines
meta/conf/bitbake.conf HOST_LD_ARCH = "${TARGET_LD_ARCH}" · line 101
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" TUNE_LDARGS ??= ""As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage or in meaning and we need to find a better solution. I'm therefore not keen on this change.
Quoted 2 lines
OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use different PKGARCH for different
TUNE_CCARGS?I've been an advocate for a while that the processor optimization (CCARGS) does make it into the PKGARCH.
ARMPKGSFX_CPUseems like a reasonable approach to do this. It allows each tune to set something to tell people what that binary is really built for, and for the 'base' tunes (i.e. armv5) it can be left off.The only concern I have with that is:
+ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}"
Quoted 8 lines
That probably should be a .= instead of just '='. That way if the user loads multiple compatible tunes the right
ARMPKGSFX_CPUwill be used. (Alternatively using the overrides would work as well for this.. i.e. ARMPKGSFX_CPU_tune-arm926ejs instead...I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is fine as well, and it was designed to be overriden.. but again the .= or -tune_... syntax should be used...
I've updated contrib/jansa/tune-test with this.
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-testWhile changing that to use e.g.
ARMPKGARCH_tune-xscale
I've noticed that _tune-foo are not valid OVERRIDE, so I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported
arm tune (otherwise it's expanded like thisTUNE_PKGARCH(${ARMPKGARCH_tune-armv5te}te).).Quoted 3 lines
This makes whole
TUNE_PKGARCH= "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" a bit less usefull, maybeARMPKGSFX_CPUwas better approach..I've clarified with RP on this. Tune values are not a 'true' override because of evaluation time of overrides. We want the DEFAULTTUNE to be changeable during the build process to allow multilibs, alternative configurations, etc.
So in the tunes to do override-like implementations, you will need:
Quoted 7 lines
Quoted 5 lines
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
and then in each tune fragment:
ARMPKGARCH_tune-foo = "bar"
Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top in that repo
Ya, I agree a bit ugly.. but I do think it's reasonable in this case.
--Mark
Quoted 61 lines
Quoted 60 lines
--Mark
Quoted 56 lines
Cheers,
Quoted 53 lines
Anyway, my point in this is I like having the stuff unique, but we need to be sure that you can specify more then one tune file during a build w/o clashes.
Quoted 11 lines
Quoted 5 lines
I also still think this is a distro packaging issue and should be solved by the distro, even if that means more complexity there. That is the right place for this particular complexity IMO. I'm happy to support that from the core but not in something as user visible and confusing as this variable.
Agreed OPTDEFAULTTUNE is to help distro configs, because complexity there will be much worse then when it's defined in tune-* files, because now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
TUNE_FEATURE) it supports and it's less orthogonal (machine/distro config) then it could be.I really don't have a strong opinion on this either way. I know for the stuff I've done in the past (not oe-based) we've just manually configured (the equivalent of the distro conf) with the information on the handful of items that people wanted optimized the most... eglibc, openssl, mysql/posgresql... otherwise folks don't seem to care, and re-use works fine.
If the list is small (i.e. less then 10 packages) that specifying it via package specific overrides in the distro file should be fine.. if it's more then 10 (typically) then we need to start looking for another approach.
I'd almost suggest in the distro file you could do:
OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP (or elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
and then everything can be encapsulated into the distro file (and distro BSPs).
The downside of this approach is that it's not the 'standard' implementation.--Mark
Quoted 9 lines
Cheers,
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
RFC 3/5 optimized-tune.inc: add optional distro include
In reply to Martin Jansa* selects more optimized DEFAULTTUNE for some packages
* for some machines it could be de same as DEFAULTTUNE
--- meta/conf/distro/include/optimized-tune.inc | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 meta/conf/distro/include/optimized-tune.inc
meta/conf/distro/include/optimized-tune.inc new file +2 -0
@@ -0,0 +1,2 @@ +# list of packages where it's worth it using OPTDEFAULTTUNE with cost of separate package feed +DEFAULTTUNE_pn-openssl = "${OPTDEFAULTTUNE}"
Signature · 1 line
1.7.12
RFC 4/5 bitbake.conf: add TUNE_CCARGS[vardepvalue]
In reply to Martin Jansa* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html
--- meta/conf/bitbake.conf | 1 + 1 file changed, 1 insertion(+)
meta/conf/bitbake.conf +1 -0
@@ -98,6 +98,7 @@ HOST_EXEEXT = "" OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" +TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}" TUNE_LDARGS ??= "" TUNE_ASARGS ??= "" TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
Signature · 1 line
1.7.12
RFC 5/5 tune-xscale, tune-arm926ejs: drop ARMPKGSFX_CPU, change ARMPKGARCH instead
In reply to Martin Jansa* xscale will be prefix not suffix, but also we need to show other flags like thumb/dsp/fpu/eabi/endian
--- meta/conf/machine/include/arm/README | 5 +---- meta/conf/machine/include/arm/arch-arm.inc | 4 +--- meta/conf/machine/include/tune-arm926ejs.inc | 4 ++-- meta/conf/machine/include/tune-xscale.inc | 6 +++--- 4 files changed, 7 insertions(+), 12 deletions(-)
meta/conf/machine/include/arm/README +1 -4
@@ -16,7 +16,7 @@ default. The format must be of the form: <armversion>[t][e][hf][b][-vfp][-neon] TUNE_PKGARCH is defined as: -${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU} +${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU} ARMPKGARCH - This is the core package arch component specified by each tuning. This is the primary identifier of a tuning. Usual values are:
@@ -38,6 +38,3 @@ the core arch-arm.inc file. ARMPKGSFX_FPU - This is the FPU specific suffix. The suffix indicates specific FPU optimizations. 'vfp' and 'neon' are both defined. - -ARMPKGSFX_CPU - This is the CPU specific suffix. The suffix indicates -that specific CPU optimizations were used.
meta/conf/machine/include/arm/arch-arm.inc +1 -3
@@ -4,14 +4,12 @@ TUNEVALID[bigendian] = "Enable big-endian mode." ARMPKGARCH ??= "arm" ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}" ARMPKGSFX_FPU ??= "" -ARMPKGSFX_CPU ??= "" -ARMPKGSFX_CPU[vardepvalue] = "${ARMPKGSFX_CPU}" ARMPKGSFX_DSP ??= "" ARMPKGSFX_EABI ??= "" ARMPKGSFX_THUMB ??= "" TUNE_ARCH = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "armeb", "arm", d)}" -TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_CPU}" +TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" ABIEXTENSION = "eabi"
meta/conf/machine/include/tune-arm926ejs.inc +2 -2
@@ -1,6 +1,6 @@ DEFAULTTUNE ?= "armv5te" OPTDEFAULTTUNE ?= "arm926ejs" -ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-arm926ejs", "", d)}" +ARMPKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "arm926ejs-", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
@@ -9,4 +9,4 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm92 AVAILTUNES += "arm926ejs" TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" -PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-arm926ejs" +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejs-te"
meta/conf/machine/include/tune-xscale.inc +3 -3
@@ -1,6 +1,6 @@ DEFAULTTUNE ?= "armv5te" OPTDEFAULTTUNE ?= "xscale" -ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-xscale", "", d)}" +ARMPKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "xscale-", "", d)}" require conf/machine/include/arm/arch-armv5-dsp.inc
@@ -9,11 +9,11 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", AVAILTUNES += "xscale" TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" -PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} armv5te-xscale" +PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} xscale-te" AVAILTUNES += "xscale-be" TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian" -PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} armv5teb-xscale" +PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb} xscale-teb" # webkit-gtk has alignment issues with double instructions on armv5 so # disable them here
Signature · 1 line
1.7.12
cover conf/machine: fix arm tune files
In reply to Martin JansaTested with sstate-diff.sh script and fake machine configs added in this branch:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test
Fixes [YOCTO #3219]
The following changes since commit df2b756436b90f8f9ff229ba64d0af30d9d4f923:
common-licenses: Adding bzip (2012-10-04 14:09:06 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/tune2
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/tune2
Martin Jansa (7):
tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with
xscale in TUNE_FEATURES
bitbake.conf: add TUNE_CCARGS[vardepvalue]
tune-cortexr4: fix march value
arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes
arch-arm: define different ARMPKGARCH when different CCARGS are used tune-*: define more generic DEFAULTTUNE to share feed between
machines
scripts/sstate-diff.sh: add simple script to compare sstate checksums
between MACHINEs
meta/conf/bitbake.conf | 1 + meta/conf/machine/include/arm/arch-arm.inc | 2 +- meta/conf/machine/include/arm/arch-armv4.inc | 6 +++-- meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12 +++++++++ meta/conf/machine/include/arm/arch-armv5.inc | 14 +++++++++-- meta/conf/machine/include/arm/arch-armv6.inc | 10 ++++++-- meta/conf/machine/include/arm/arch-armv7a.inc | 18 +++++++++++-- meta/conf/machine/include/tune-arm1136jf-s.inc | 3 ++- meta/conf/machine/include/tune-arm920t.inc | 3 ++- meta/conf/machine/include/tune-arm926ejs.inc | 4 +-- meta/conf/machine/include/tune-arm9tdmi.inc | 3 ++- meta/conf/machine/include/tune-cortexa8.inc | 8 +++++- meta/conf/machine/include/tune-cortexa9.inc | 8 +++++- meta/conf/machine/include/tune-cortexm1.inc | 3 ++- meta/conf/machine/include/tune-cortexm3.inc | 2 +- meta/conf/machine/include/tune-cortexr4.inc | 4 +-- meta/conf/machine/include/tune-ep9312.inc | 4 +-- meta/conf/machine/include/tune-iwmmxt.inc | 4 +-- meta/conf/machine/include/tune-strongarm1100.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc | 8 +++--- scripts/sstate-diff.sh | 32 ++++++++++++++++++++++++ 21 files changed, 122 insertions(+), 30 deletions(-) create mode 100755 scripts/sstate-diff.sh
Signature · 1 line
1.7.12
PATCH 1/7 tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
* without this you'll get different sstate checksum for webkit-gtk and cairo even when you build them with DEFAULTTUNE == armv5te
* maybe this isn't needed at all anymore or if it is then it should be applied in arm-armv5.inc for all armv5te devices, not only xscale?
--- meta/conf/machine/include/tune-xscale.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
meta/conf/machine/include/tune-xscale.inc +2 -2
@@ -15,5 +15,5 @@ PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" # webkit-gtk has alignment issues with double instructions on armv5 so # disable them here -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t" -TUNE_CCARGS_pn-cairo = "-march=armv4t" +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}" +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
Signature · 1 line
1.7.12
Re: [PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
meta/conf/machine/include/tune-xscale.inc PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" · line 19
Quoted 5 lines · Martin Jansa
meta/conf/machine/include/tune-xscale.inc +2
-2-TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t" -TUNE_CCARGS_pn-cairo = "-march=armv4t" +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}" +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"
I would rather try to remove this option completely if possible. I wonder if we still need to target armv4t when building on xscale may be the reason it was added is no more relevant ?
Re: [PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
Quoted 10 lines · Khem Raj
meta/conf/machine/include/tune-xscale.inc PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}" · line 19
Quoted 5 lines · Martin Jansa
meta/conf/machine/include/tune-xscale.inc +2
-2-TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t" -TUNE_CCARGS_pn-cairo = "-march=armv4t" +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}" +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-march=armv4t", "", d)}"I would rather try to remove this option completely if possible. I wonder if we still need to target armv4t when building on xscale may be the reason it was added is no more relevant ?
I think the same (as written in commit message). Now it won't be used by default at least (only if someone asks for DEFAULTTUNE xscale for webkit-gtk or cairo).
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
PATCH 2/7 bitbake.conf: add TUNE_CCARGS[vardepvalue]
In reply to Martin Jansa* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html
--- meta/conf/bitbake.conf | 1 + 1 file changed, 1 insertion(+)
meta/conf/bitbake.conf +1 -0
@@ -98,6 +98,7 @@ HOST_EXEEXT = "" TUNE_ARCH ??= "INVALID" TUNE_CCARGS ??= "" +TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}" TUNE_LDARGS ??= "" TUNE_ASARGS ??= "" TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
Signature · 1 line
1.7.12
PATCH 3/7 tune-cortexr4: fix march value
In reply to Martin Jansa* probably copy&paste error from tune-cortexm3.conf commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc
Author: Richard Purdie <[email protected]>
Date: Mon Jul 25 19:03:24 2011 +0100
Add ARM tune file overhaul based largely on work from Mark Hatle
--- meta/conf/machine/include/tune-cortexr4.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/conf/machine/include/tune-cortexr4.inc +1 -1
@@ -7,7 +7,7 @@ TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4", "-mtune=cortex-r4", "", d)}" TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations" -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}" AVAILTUNES += "cortexr4" TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4"
Signature · 1 line
1.7.12
Re: [PATCH 3/7] tune-cortexr4: fix march value
meta/conf/machine/include/tune-cortexr4.inc TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor optimizations" · line 10
Quoted 3 lines · Martin Jansa
meta/conf/machine/include/tune-cortexr4.inc +1
-1-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-m", "", d)}" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}"
yeah this is ok
PATCH 4/7 arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes
In reply to Martin Jansa* tune-foo is not valid override, for it to work I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
but that doesn't work without value defined for every supported DEFAULTTUNE value, otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).
--- meta/conf/machine/include/arm/arch-arm.inc | 2 +- meta/conf/machine/include/arm/arch-armv4.inc | 6 ++++-- meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12 ++++++++++++ meta/conf/machine/include/arm/arch-armv5.inc | 14 ++++++++++++-- meta/conf/machine/include/arm/arch-armv6.inc | 10 ++++++++-- meta/conf/machine/include/arm/arch-armv7a.inc | 18 ++++++++++++++++-- 6 files changed, 53 insertions(+), 9 deletions(-)
meta/conf/machine/include/arm/arch-arm.inc +1 -1
@@ -1,7 +1,7 @@ TUNEVALID[bigendian] = "Enable big-endian mode." -ARMPKGARCH ??= "arm" +ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}" ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b", "", d)}" ARMPKGSFX_FPU ??= "" ARMPKGSFX_DSP ??= ""
meta/conf/machine/include/arm/arch-armv4.inc +4 -2
@@ -1,7 +1,5 @@ DEFAULTTUNE ?= "armv4" -ARMPKGARCH ?= "armv4" - TUNEVALID[armv4] = "Enable instructions for ARMv4" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}" TARGET_LD_KERNEL_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "--fix-v4bx", "", d)}"
@@ -12,6 +10,8 @@ require conf/machine/include/arm/feature-arm-thumb.inc # Little Endian AVAILTUNES += "armv4 armv4t" +ARMPKGARCH_tune-armv4 ?= "armv4" +ARMPKGARCH_tune-armv4t ?= "armv4" TUNE_FEATURES_tune-armv4 ?= "armv4" TUNE_FEATURES_tune-armv4t ?= "armv4 thumb" PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
@@ -19,6 +19,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv4t = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t" # Big Endian AVAILTUNES += "armv4b armv4tb" +ARMPKGARCH_tune-armv4b ?= "armv4" +ARMPKGARCH_tune-armv4tb ?= "armv4" TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian" TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian" PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
meta/conf/machine/include/arm/arch-armv5-dsp.inc +12 -0
@@ -5,6 +5,8 @@ require conf/machine/include/arm/arch-armv5.inc # Little Endian AVAILTUNES += "armv5e armv5te" +ARMPKGARCH_tune-armv5e ?= "armv5" +ARMPKGARCH_tune-armv5te ?= "armv5" TUNE_FEATURES_tune-armv5e ?= "armv5 dsp" TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb" PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
@@ -12,6 +14,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e ar # Little Endian + VFP/DSP AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp" +ARMPKGARCH_tune-armv5e-vfp ?= "armv5" +ARMPKGARCH_tune-armv5te-vfp ?= "armv5" +ARMPKGARCH_tune-armv5ehf-vfp ?= "armv5" +ARMPKGARCH_tune-armv5tehf-vfp ?= "armv5" TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp" TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb" TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} callconvention-hard"
@@ -23,6 +29,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf # Big Endian AVAILTUNES += "armv5eb armv5teb" +ARMPKGARCH_tune-armv5eb ?= "armv5" +ARMPKGARCH_tune-armv5teb ?= "armv5" TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian" TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian" PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5b} armv5eb"
@@ -30,6 +38,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5teb = "${PACKAGE_EXTRA_ARCHS_tune-armv5tb} armv5eb # Big Endian + VFP/DSP AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp" +ARMPKGARCH_tune-armv5eb-vfp ?= "armv5" +ARMPKGARCH_tune-armv5teb-vfp ?= "armv5" +ARMPKGARCH_tune-armv5ehfb-vfp ?= "armv5" +ARMPKGARCH_tune-armv5tehfb-vfp ?= "armv5" TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian" TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp} bigendian" TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp} callconvention-hard"
meta/conf/machine/include/arm/arch-armv5.inc +12 -2
@@ -1,7 +1,5 @@ DEFAULTTUNE ?= "armv5" -ARMPKGARCH ?= "armv5" - TUNEVALID[armv5] = "Enable instructions for ARMv5" TUNECONFLICTS[armv5] = "armv4" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
@@ -14,6 +12,8 @@ require conf/machine/include/arm/feature-arm-vfp.inc # Little Endian AVAILTUNES += "armv5 armv5t" +ARMPKGARCH_tune-armv5 ?= "armv5" +ARMPKGARCH_tune-armv5t ?= "armv5" TUNE_FEATURES_tune-armv5 ?= "armv5" TUNE_FEATURES_tune-armv5t ?= "armv5 thumb" PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
@@ -21,6 +21,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv # Little Endian + VFP/DSP AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp" +ARMPKGARCH_tune-armv5-vfp ?= "armv5" +ARMPKGARCH_tune-armv5t-vfp ?= "armv5" +ARMPKGARCH_tune-armv5hf-vfp ?= "armv5" +ARMPKGARCH_tune-armv5thf-vfp ?= "armv5" TUNE_FEATURES_tune-armv5-vfp ?= "armv5 vfp" TUNE_FEATURES_tune-armv5t-vfp ?= "armv5 vfp" TUNE_FEATURES_tune-armv5hf-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} callconvention-hard"
@@ -33,6 +37,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf # Big Endian AVAILTUNES += "armv5b armv5tb" +ARMPKGARCH_tune-armv5b ?= "armv5" +ARMPKGARCH_tune-armv5tb ?= "armv5" TUNE_FEATURES_tune-armv5b ?= "${TUNE_FEATURES_tune-armv5} bigendian" TUNE_FEATURES_tune-armv5tb ?= "${TUNE_FEATURES_tune-armv5t} bigendian" PACKAGE_EXTRA_ARCHS_tune-armv5b = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5b"
@@ -40,6 +46,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5b ar # Big Endian + VFP/DSP AVAILTUNES += "armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp" +ARMPKGARCH_tune-armv5b-vfp ?= "armv5" +ARMPKGARCH_tune-armv5tb-vfp ?= "armv5" +ARMPKGARCH_tune-armv5hfb-vfp ?= "armv5" +ARMPKGARCH_tune-armv5thfb-vfp ?= "armv5" TUNE_FEATURES_tune-armv5b-vfp ?= "${TUNE_FEATURES_tune-armv5-vfp} bigendian" TUNE_FEATURES_tune-armv5tb-vfp ?= "${TUNE_FEATURES_tune-armv5t-vfp} bigendian" TUNE_FEATURES_tune-armv5hfb-vfp ?= "${TUNE_FEATURES_tune-armv5b-vfp} callconvention-hard"
meta/conf/machine/include/arm/arch-armv6.inc +8 -2
@@ -1,7 +1,5 @@ DEFAULTTUNE ?= "armv6" -ARMPKGARCH ?= "armv6" - TUNEVALID[armv6] = "Enable instructions for ARMv6" TUNECONFLICTS[armv6] = "armv4 armv5" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
@@ -11,6 +9,10 @@ require conf/machine/include/arm/arch-armv5-dsp.inc # Little Endian AVAILTUNES += "armv6 armv6t armv6hf armv6thf" +ARMPKGARCH_tune-armv6 ?= "armv6" +ARMPKGARCH_tune-armv6t ?= "armv6" +ARMPKGARCH_tune-armv6hf ?= "armv6" +ARMPKGARCH_tune-armv6thf ?= "armv6" TUNE_FEATURES_tune-armv6 ?= "armv6 vfp" TUNE_FEATURES_tune-armv6t ?= "armv6 vfp thumb" TUNE_FEATURES_tune-armv6hf ?= "${TUNE_FEATURES_tune-armv6} callconvention-hard"
@@ -22,6 +24,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} a # Big Endian AVAILTUNES += "armv6b armv6tb armv6hfb armv6thfb" +ARMPKGARCH_tune-armv6b ?= "armv6" +ARMPKGARCH_tune-armv6tb ?= "armv6" +ARMPKGARCH_tune-armv6hfb ?= "armv6" +ARMPKGARCH_tune-armv6thfb ?= "armv6" TUNE_FEATURES_tune-armv6b ?= "${TUNE_FEATURES_tune-armv6} bigendian" TUNE_FEATURES_tune-armv6tb ?= "${TUNE_FEATURES_tune-armv6t} bigendian" TUNE_FEATURES_tune-armv6hfb ?= "${TUNE_FEATURES_tune-armv6b} callconvention-hard"
meta/conf/machine/include/arm/arch-armv7a.inc +16 -2
@@ -1,7 +1,5 @@ DEFAULTTUNE ?= "armv7a" -ARMPKGARCH ?= "armv7a" - TUNEVALID[armv7a] = "Enable instructions for ARMv7-a" TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a", "", d)}"
@@ -12,6 +10,10 @@ require conf/machine/include/arm/feature-arm-neon.inc # Little Endian base configs AVAILTUNES += "armv7a armv7at armv7a-neon armv7at-neon" +ARMPKGARCH_tune-armv7a ?= "armv7a" +ARMPKGARCH_tune-armv7at ?= "armv7a" +ARMPKGARCH_tune-armv7a-neon?= "armv7a" +ARMPKGARCH_tune-armv7at-neon ?= "armv7a" TUNE_FEATURES_tune-armv7a ?= "armv7a vfp" TUNE_FEATURES_tune-armv7at ?= "armv7a vfp thumb" TUNE_FEATURES_tune-armv7a-neon ?= "armv7a vfp neon"
@@ -23,6 +25,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} arm # VFP Tunes AVAILTUNES += "armv7ahf armv7athf armv7ahf-neon armv7athf-neon" +ARMPKGARCH_tune-armv7ahf ?= "armv7a" +ARMPKGARCH_tune-armv7athf ?= "armv7a" +ARMPKGARCH_tune-armv7ahf-neon?= "armv7a" +ARMPKGARCH_tune-armv7athf-neon ?= "armv7a" TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard" TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard" TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
@@ -34,6 +40,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7athf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf} # Big Endian AVAILTUNES += "armv7ab armv7atb armv7ab-neon armv7atb-neon" +ARMPKGARCH_tune-armv7ab ?= "armv7a" +ARMPKGARCH_tune-armv7atb ?= "armv7a" +ARMPKGARCH_tune-armv7ab-neon?= "armv7a" +ARMPKGARCH_tune-armv7atb-neon ?= "armv7a" TUNE_FEATURES_tune-armv7ab ?= "${TUNE_FEATURES_tune-armv7a} bigendian" TUNE_FEATURES_tune-armv7atb ?= "${TUNE_FEATURES_tune-armv7at} bigendian" TUNE_FEATURES_tune-armv7ab-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} bigendian"
@@ -45,6 +55,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} ar # Big Endian + VFP AVAILTUNES += "armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon" +ARMPKGARCH_tune-armv7ahfb ?= "armv7a" +ARMPKGARCH_tune-armv7athfb ?= "armv7a" +ARMPKGARCH_tune-armv7ahfb-neon?= "armv7a" +ARMPKGARCH_tune-armv7athfb-neon ?= "armv7a" TUNE_FEATURES_tune-armv7ahfb ?= "${TUNE_FEATURES_tune-armv7ab} callconvention-hard" TUNE_FEATURES_tune-armv7athfb ?= "${TUNE_FEATURES_tune-armv7atb} callconvention-hard" TUNE_FEATURES_tune-armv7ahfb-neon ?= "${TUNE_FEATURES_tune-armv7ab-neon} callconvention-hard"
Signature · 1 line
1.7.12
PATCH 5/7 arch-arm: define different ARMPKGARCH when different CCARGS are used
In reply to Martin Jansa* without this tune-xscale and tune-arm926ejs were both creating packages in armv5te feed, but each with different -mtune, with OEBasicHash enabled it was causing each package to rebuild with new -mtune after MACHINE switch, but that doesn't make sense with output stored in the same armv5te feed
* this makes different feed for each -mtune, but more generic one to be selected with DEFAULTTUNE
* tune-iwmmxt and tune-ep9312 were already using this, just move it bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax
* tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH because there isn't another tune to use the same -march
* Fixes [YOCTO #3219]
--- meta/conf/machine/include/tune-arm1136jf-s.inc | 1 + meta/conf/machine/include/tune-arm920t.inc | 1 + meta/conf/machine/include/tune-arm926ejs.inc | 2 +- meta/conf/machine/include/tune-arm9tdmi.inc | 1 + meta/conf/machine/include/tune-cortexa8.inc | 6 ++++++ meta/conf/machine/include/tune-cortexa9.inc | 6 ++++++ meta/conf/machine/include/tune-cortexm1.inc | 1 + meta/conf/machine/include/tune-cortexm3.inc | 2 +- meta/conf/machine/include/tune-cortexr4.inc | 2 +- meta/conf/machine/include/tune-ep9312.inc | 4 +--- meta/conf/machine/include/tune-iwmmxt.inc | 4 +--- meta/conf/machine/include/tune-strongarm1100.inc | 1 + meta/conf/machine/include/tune-xscale.inc | 2 ++ 13 files changed, 24 insertions(+), 9 deletions(-)
meta/conf/machine/include/tune-arm1136jf-s.inc +1 -0
@@ -6,5 +6,6 @@ TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}" AVAILTUNES += "arm1136jfs" +ARMPKGARCH_tune-arm1136jfs = "arm1136jfs" TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs" PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
meta/conf/machine/include/tune-arm920t.inc +1 -0
@@ -6,6 +6,7 @@ TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}" AVAILTUNES += "arm920t" +ARMPKGARCH_tune-arm920t = "arm920t" TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t" PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
meta/conf/machine/include/tune-arm926ejs.inc +1 -1
@@ -6,6 +6,6 @@ TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}" AVAILTUNES += "arm926ejs" +ARMPKGARCH_tune-arm926ejs = "arm926ejs" TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" -
meta/conf/machine/include/tune-arm9tdmi.inc +1 -0
@@ -6,6 +6,7 @@ TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}" AVAILTUNES += "arm9tdmi" +ARMPKGARCH_tune-arm9tdmi = "arm9tdmi" TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi" PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
meta/conf/machine/include/tune-cortexa8.inc +6 -0
@@ -7,6 +7,9 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex # Little Endian base configs AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon" +ARMPKGARCH_tune-cortexa8 = "cortexa8" +ARMPKGARCH_tune-cortexa8t = "cortexa8t" +ARMPKGARCH_tune-cortexa8-neon = "cortexa8-neon" TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8" TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8" TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-armv7a-neon} cortexa8"
@@ -16,6 +19,9 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon # VFP Tunes AVAILTUNES += "cortexa8hf cortexa8thf cortexa8hf-neon" +ARMPKGARCH_tune-cortexa8hf = "cortexa8hf" +ARMPKGARCH_tune-cortexa8thf = "cortexa8thf" +ARMPKGARCH_tune-cortexa8hf-neon = "cortexa8hf-neon" TUNE_FEATURES_tune-cortexa8hf ?= "${TUNE_FEATURES_tune-armv7ahf} cortexa8" TUNE_FEATURES_tune-cortexa8thf ?= "${TUNE_FEATURES_tune-armv7athf} cortexa8" TUNE_FEATURES_tune-cortexa8hf-neon ?= "${TUNE_FEATURES_tune-armv7ahf-neon} cortexa8"
meta/conf/machine/include/tune-cortexa9.inc +6 -0
@@ -7,6 +7,9 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex # Little Endian base configs AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon" +ARMPKGARCH_tune-cortexa9 = "cortexa9" +ARMPKGARCH_tune-cortexa9t = "cortexa9t" +ARMPKGARCH_tune-cortexa9-neon = "cortexa9-neon" TUNE_FEATURES_tune-cortexa9 = "${TUNE_FEATURES_tune-armv7a} cortexa9" TUNE_FEATURES_tune-cortexa9t = "${TUNE_FEATURES_tune-armv7at} cortexa9" TUNE_FEATURES_tune-cortexa9-neon = "${TUNE_FEATURES_tune-armv7a-neon} cortexa9"
@@ -16,6 +19,9 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa9-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon # VFP Tunes AVAILTUNES += "cortexa9hf cortexa9thf cortexa9hf-neon" +ARMPKGARCH_tune-cortexa9hf = "cortexa9hf" +ARMPKGARCH_tune-cortexa9thf = "cortexa9thf" +ARMPKGARCH_tune-cortexa9hf-neon = "cortexa9hf-neon" TUNE_FEATURES_tune-cortexa9hf ?= "${TUNE_FEATURES_tune-armv7ahf} cortexa9" TUNE_FEATURES_tune-cortexa9thf ?= "${TUNE_FEATURES_tune-armv7athf} cortexa9" TUNE_FEATURES_tune-cortexa9hf-neon ?= "${TUNE_FEATURES_tune-armv7ahf-neon} cortexa9"
meta/conf/machine/include/tune-cortexm1.inc +1 -0
@@ -6,6 +6,7 @@ TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}" AVAILTUNES += "cortexm1" +ARMPKGARCH_tune-cortexm1 = "cortexm1" TUNE_FEATURES_tune-cortexm1 = "${TUNE_FEATURES_tune-armv7a} cortexm1" PACKAGE_EXTRA_ARCHS_tune-cortexm1 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
meta/conf/machine/include/tune-cortexm3.inc +1 -1
@@ -1,5 +1,4 @@ DEFAULTTUNE ?= "cortexm3" -ARMPKGARCH ?= "armv7m" require conf/machine/include/arm/arch-armv7a.inc
@@ -10,6 +9,7 @@ TUNEVALID[armv7m] = "Enable Cortex-M3 specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7m", "-march=armv7-m", "", d)}" AVAILTUNES += "cortexm3" +ARMPKGARCH_tune-cortexm3 = "armv7m" TUNE_FEATURES_tune-cortexm3 = "armv7m vfp cortexm3" PACKAGE_EXTRA_ARCHS_tune-cortexm3 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7m-vfp"
meta/conf/machine/include/tune-cortexr4.inc +1 -1
@@ -1,5 +1,4 @@ DEFAULTTUNE ?= "cortexr4" -ARMPKGARCH ?= "armv7r" require conf/machine/include/arm/arch-armv7a.inc
@@ -10,5 +9,6 @@ TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r", "-march=armv7-r", "", d)}" AVAILTUNES += "cortexr4" +ARMPKGARCH_tune-cortexr4 = "armv7r" TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4" PACKAGE_EXTRA_ARCHS_tune-cortexr4 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7r-vfp"
meta/conf/machine/include/tune-ep9312.inc +1 -3
@@ -1,5 +1,4 @@ DEFAULTTUNE ?= "ep9312" -ARMPKGARCH ?= "ep9312" require conf/machine/include/arm/arch-armv4.inc
@@ -7,7 +6,6 @@ TUNEVALID[ep9312] = "Enable Intel PXA27x specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ep9312", "-march=ep9312 -mtune=ep9312", "", d)}" AVAILTUNES += "ep9312" +ARMPKGARCH_tune-ep9312 = "ep9312" TUNE_FEATURES_tune-ep9312 = "thumb ep9312" PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312" - -
meta/conf/machine/include/tune-iwmmxt.inc +1 -3
@@ -2,7 +2,6 @@ # Please use tune-xscale for PXA255/PXA26x based processors. DEFAULTTUNE ?= "iwmmxt" -ARMPKGARCH ?= "iwmmxt" require conf/machine/include/arm/arch-armv5-dsp.inc
@@ -10,7 +9,6 @@ TUNEVALID[iwmmxt] = "Enable Intel PXA27x specific processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "iwmmxt", "-march=iwmmxt -mtune=iwmmxt", "", d)}" AVAILTUNES += "iwmmxt" +ARMPKGARCH_tune-iwmmxt = "iwmmxt" TUNE_FEATURES_tune-iwmmxt = "thumb iwmmxt" PACKAGE_EXTRA_ARCHS_tune-iwmmxt = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} iwmmxt" - -
meta/conf/machine/include/tune-strongarm1100.inc +1 -0
@@ -6,6 +6,7 @@ TUNEVALID[strongarm] = "Enable Strongarm 1100 series processor optimizations" TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "strongarm", "-mtune=strongarm1100", "", d)}" AVAILTUNES += "strongarm" +ARMPKGARCH_tune-strongarm = "strongarm" TUNE_FEATURES_tune-strongarm = "${TUNE_FEATURES_tune-armv4} strongarm" PACKAGE_EXTRA_ARCHS_tune-strongarm = "${PACKAGE_EXTRA_ARCHS_tune-armv4}"
meta/conf/machine/include/tune-xscale.inc +2 -0
@@ -6,10 +6,12 @@ TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor optimization TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}" AVAILTUNES += "xscale" +ARMPKGARCH_tune-xscale = "xscale" TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" AVAILTUNES += "xscale-be" +ARMPKGARCH_tune-xscale-be = "xscale-be" TUNE_FEATURES_tune-xscale-be = "${TUNE_FEATURES_tune-armv5teb} xscale bigendian" PACKAGE_EXTRA_ARCHS_tune-xscale-be = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
Signature · 1 line
1.7.12
PATCH 6/7 tune-*: define more generic DEFAULTTUNE to share feed between machines
In reply to Martin Jansa* this is mostly for backwards compatibility and to share binary feed like it was before, but now without missing different -mtune in it
* if you want to build some package with -mtune add something like this to your distro config
DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs" DEFAULTTUNE_qemuarmx_pn-openssl = "xscale"
be aware that if you do this you should do it also for all packages which depends on openssl because if you dont and you build e.g. dhcp, then dhcp build for arm926ejs (even with DEFAULTTUNE armv5te) will depend on openssl with arm926ejs, so dhcp in armv5te feed will be rebuild after each MACHINE switch.
* cortexm3, cortexr4, iwmmx and ep9312 are using own DEFAULTTUNE because they define also different -march
* shared feeds are
armv4t: arm920t, arm9tdmi
armv5te: arm926ejs, xscale
armv7a-neon: cortexa8, cortexa9
--- meta/conf/machine/include/tune-arm1136jf-s.inc | 2 +- meta/conf/machine/include/tune-arm920t.inc | 2 +- meta/conf/machine/include/tune-arm926ejs.inc | 2 +- meta/conf/machine/include/tune-arm9tdmi.inc | 2 +- meta/conf/machine/include/tune-cortexa8.inc | 2 +- meta/conf/machine/include/tune-cortexa9.inc | 2 +- meta/conf/machine/include/tune-cortexm1.inc | 2 +- meta/conf/machine/include/tune-strongarm1100.inc | 2 +- meta/conf/machine/include/tune-xscale.inc | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-)
meta/conf/machine/include/tune-arm1136jf-s.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm1136jfs" +DEFAULTTUNE ?= "armv6" require conf/machine/include/arm/arch-armv6.inc
meta/conf/machine/include/tune-arm920t.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm920t" +DEFAULTTUNE ?= "armv4t" require conf/machine/include/arm/arch-armv4.inc
meta/conf/machine/include/tune-arm926ejs.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm926ejs" +DEFAULTTUNE ?= "armv5te" require conf/machine/include/arm/arch-armv5-dsp.inc
meta/conf/machine/include/tune-arm9tdmi.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm9tdmi" +DEFAULTTUNE ?= "armv4t" require conf/machine/include/arm/arch-armv4.inc
meta/conf/machine/include/tune-cortexa8.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexa8-neon" +DEFAULTTUNE ?= "armv7a-neon" require conf/machine/include/arm/arch-armv7a.inc
meta/conf/machine/include/tune-cortexa9.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexa9-neon" +DEFAULTTUNE ?= "armv7a-neon" require conf/machine/include/arm/arch-armv7a.inc
meta/conf/machine/include/tune-cortexm1.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexm1" +DEFAULTTUNE ?= "armv7a" require conf/machine/include/arm/arch-armv7a.inc
meta/conf/machine/include/tune-strongarm1100.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "strongarm" +DEFAULTTUNE ?= "armv4" require conf/machine/include/arm/arch-armv4.inc
meta/conf/machine/include/tune-xscale.inc +1 -1
@@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "xscale" +DEFAULTTUNE ?= "armv5te" require conf/machine/include/arm/arch-armv5-dsp.inc
Signature · 1 line
1.7.12
PATCH 7/7 scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs
In reply to Martin Jansa* it's not very universal, but works with default oe-core setup and shows basic HOW-TO, because many people still don't know how to detect machine specific sstate checksums
* someone can improve this with bitbake -e calls to detect BASE and to specify MACHINEs and TARGETs in parameter instead of hardcoded values in script..
--- scripts/sstate-diff.sh | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100755 scripts/sstate-diff.sh
scripts/sstate-diff.sh new file +32 -0
@@ -0,0 +1,32 @@ +#!/bin/sh + +# Used to compare sstate checksums between MACHINES +# Update MACHINES, TARGETS and BASE +# Execute script and compare generated list.M files + +# $ diff stamps.1349348392/fake-cortexa8/list.M stamps.1349348392/fake-cortexa9/list.M | wc -l +# 538 + +# Then to compare sigdata use something like: +# $ ls stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure* +# stamps.1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025 +# stamps.1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b +# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure* +# basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a +# Variable TUNE_CCARGS value changed from -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 + +MACHINES="fake-arm1136jf-s fake-arm920t fake-arm926ejs fake-arm9tdmi fake-cortexa8 fake-cortexa9 fake-cortexm1 fake-cortexm3 fake-cortexr4 fake-ep9312 fake-iwmmxt fake-strongarm1100 fake-xscale" +TARGETS="dhcp" + +BASE="/OE/oe-core" +OUTPUT=${BASE}/stamps.`date "+%s"` + +for M in ${MACHINES}; do + find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f + mkdir -p ${OUTPUT}/${M} + export MACHINE=${M}; bitbake -S ${TARGETS} | tee -a ${OUTPUT}/${M}/log; + cp -ra ${BASE}/tmp-eglibc/stamps/* ${OUTPUT}/${M} + find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list + sed "s/om_gta0/om-gta0/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M + find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f +done
Signature · 1 line
1.7.12
PATCH v2 1/1 scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs
* takes tmpdir, machines and targets from command arguments or env variables
--- scripts/sstate-diff.sh | 107 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100755 scripts/sstate-diff.sh
scripts/sstate-diff.sh new file +107 -0
@@ -0,0 +1,107 @@ +#!/bin/sh + +# Used to compare sstate checksums between MACHINES +# Execute script and compare generated list.M files + +# It's also usefull to keep older sstate checksums +# to be able to find out why something is rebuilding +# after updating metadata + +# $ diff \ +# sstate-diff/1349348392/fake-cortexa8/list.M \ +# sstate-diff/1349348392/fake-cortexa9/list.M \ +# | wc -l +# 538 + +# Then to compare sigdata use something like: +# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025 +# sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b +# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a +# Variable TUNE_CCARGS value changed from -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 + +# Global vars +tmpdir= +machines= +targets= +default_machines="qemuarm qemux86 qemux86-64" +default_targets="core-image-base" + +usage () { + cat << EOF +Welcome to utility to compare sstate checksums between different MACHINEs. +$0 <OPTION> + +Options: + -h, --help + Display this help and exit. + + --tmpdir=<tmpdir> + Specify tmpdir, will use the environment variable TMPDIR if it is not specified. + Something like /OE/oe-core/tmp-eglibc (no / at the end). + + --machines=<machines> + List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified. + Default value is "qemuarm qemux86 qemux86-64". + + --targets=<targets> + List of targets separated by space, will use the environment variable TARGETS if it is not specified. + Default value is "core-image-base". +EOF +} + +# Print error information and exit. +echo_error () { + echo "ERROR: $1" >&2 + exit 1 +} + +while [ -n "$1" ]; do + case $1 in + --tmpdir=*) + tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e` + [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir" + shift + ;; + --machines=*) + machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'` + shift + ;; + --targets=*) + targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'` + shift + ;; + --help|-h) + usage + exit 0 + ;; + *) + echo "Invalid arguments $*" + echo_error "Try '$0 -h' for more information." + ;; + esac +done + +# tmpdir directory, use environment variable TMPDIR +# if it was not specified, otherwise, error. +[ -n "$tmpdir" ] || tmpdir=$TMPDIR +[ -n "$tmpdir" ] || echo_error "No tmpdir found!" +[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\"" +[ -n "$machines" ] || machines=$MACHINES +[ -n "$machines" ] || machines=$default_machines +[ -n "$targets" ] || targets=$TARGETS +[ -n "$targets" ] || targets=$default_targets + +OUTPUT=${tmpdir}/sstate-diff/`date "+%s"` + +for M in ${machines}; do + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f + mkdir -p ${OUTPUT}/${M} + export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log; + cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M} + find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list + M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'` + sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f +done
Signature · 1 line
1.8.0
Re: [PATCHv2] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs
scripts/sstate-diff.sh
Quoted 9 lines · Martin Jansa
* takes tmpdir, machines and targets from command arguments or env variables
Signed-off-by Martin Jansa <[email protected]>--- scripts/sstate-diff.sh | 107 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100755 scripts/sstate-diff.shscripts/sstate-diff.sh +0
-0
Can we call this something a little more intuitive like sstate-diff-machines ?
Cheers,
Richard
PATCH v3 1/1 scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs
* takes tmpdir, machines and targets from command arguments or env variables
--- scripts/sstate-diff-machines.sh | 107 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100755 scripts/sstate-diff-machines.sh
scripts/sstate-diff-machines.sh new file +107 -0
@@ -0,0 +1,107 @@ +#!/bin/sh + +# Used to compare sstate checksums between MACHINES +# Execute script and compare generated list.M files + +# It's also usefull to keep older sstate checksums +# to be able to find out why something is rebuilding +# after updating metadata + +# $ diff \ +# sstate-diff/1349348392/fake-cortexa8/list.M \ +# sstate-diff/1349348392/fake-cortexa9/list.M \ +# | wc -l +# 538 + +# Then to compare sigdata use something like: +# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025 +# sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b +# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a +# Variable TUNE_CCARGS value changed from -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 + +# Global vars +tmpdir= +machines= +targets= +default_machines="qemuarm qemux86 qemux86-64" +default_targets="core-image-base" + +usage () { + cat << EOF +Welcome to utility to compare sstate checksums between different MACHINEs. +$0 <OPTION> + +Options: + -h, --help + Display this help and exit. + + --tmpdir=<tmpdir> + Specify tmpdir, will use the environment variable TMPDIR if it is not specified. + Something like /OE/oe-core/tmp-eglibc (no / at the end). + + --machines=<machines> + List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified. + Default value is "qemuarm qemux86 qemux86-64". + + --targets=<targets> + List of targets separated by space, will use the environment variable TARGETS if it is not specified. + Default value is "core-image-base". +EOF +} + +# Print error information and exit. +echo_error () { + echo "ERROR: $1" >&2 + exit 1 +} + +while [ -n "$1" ]; do + case $1 in + --tmpdir=*) + tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e` + [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir" + shift + ;; + --machines=*) + machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'` + shift + ;; + --targets=*) + targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'` + shift + ;; + --help|-h) + usage + exit 0 + ;; + *) + echo "Invalid arguments $*" + echo_error "Try '$0 -h' for more information." + ;; + esac +done + +# tmpdir directory, use environment variable TMPDIR +# if it was not specified, otherwise, error. +[ -n "$tmpdir" ] || tmpdir=$TMPDIR +[ -n "$tmpdir" ] || echo_error "No tmpdir found!" +[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\"" +[ -n "$machines" ] || machines=$MACHINES +[ -n "$machines" ] || machines=$default_machines +[ -n "$targets" ] || targets=$TARGETS +[ -n "$targets" ] || targets=$default_targets + +OUTPUT=${tmpdir}/sstate-diff/`date "+%s"` + +for M in ${machines}; do + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f + mkdir -p ${OUTPUT}/${M} + export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log; + cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M} + find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list + M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'` + sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f +done
Signature · 1 line
1.8.0
PATCH v4 1/1 scripts/sstate-diff-machines.sh: add simple script to compare sstate checksums between MACHINEs
In reply to Richard Purdie* takes tmpdir, machines and targets from command arguments or env variables
--- scripts/sstate-diff-machines.sh | 107 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100755 scripts/sstate-diff-machines.sh
scripts/sstate-diff-machines.sh new file +107 -0
@@ -0,0 +1,107 @@ +#!/bin/sh + +# Used to compare sstate checksums between MACHINES +# Execute script and compare generated list.M files + +# It's also usefull to keep older sstate checksums +# to be able to find out why something is rebuilding +# after updating metadata + +# $ diff \ +# sstate-diff/1349348392/fake-cortexa8/list.M \ +# sstate-diff/1349348392/fake-cortexa9/list.M \ +# | wc -l +# 538 + +# Then to compare sigdata use something like: +# $ ls sstate-diff/1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# sstate-diff/1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025 +# sstate-diff/1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers/3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b +# $ bitbake-diffsigs stamps.1349348392/*/armv7a-vfp-neon*/linux-libc-headers/*do_configure*sigdata* +# basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to e869fa61426e88e9c30726ba88a1216a +# Variable TUNE_CCARGS value changed from -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 + +# Global vars +tmpdir= +machines= +targets= +default_machines="qemuarm qemux86 qemux86-64" +default_targets="core-image-base" + +usage () { + cat << EOF +Welcome to utility to compare sstate checksums between different MACHINEs. +$0 <OPTION> + +Options: + -h, --help + Display this help and exit. + + --tmpdir=<tmpdir> + Specify tmpdir, will use the environment variable TMPDIR if it is not specified. + Something like /OE/oe-core/tmp-eglibc (no / at the end). + + --machines=<machines> + List of MACHINEs separated by space, will use the environment variable MACHINES if it is not specified. + Default value is "qemuarm qemux86 qemux86-64". + + --targets=<targets> + List of targets separated by space, will use the environment variable TARGETS if it is not specified. + Default value is "core-image-base". +EOF +} + +# Print error information and exit. +echo_error () { + echo "ERROR: $1" >&2 + exit 1 +} + +while [ -n "$1" ]; do + case $1 in + --tmpdir=*) + tmpdir=`echo $1 | sed -e 's#^--tmpdir=##' | xargs readlink -e` + [ -d "$tmpdir" ] || echo_error "Invalid argument to --tmpdir" + shift + ;; + --machines=*) + machines=`echo $1 | sed -e 's#^--machines="*\([^"]*\)"*#\1#'` + shift + ;; + --targets=*) + targets=`echo $1 | sed -e 's#^--targets="*\([^"]*\)"*#\1#'` + shift + ;; + --help|-h) + usage + exit 0 + ;; + *) + echo "Invalid arguments $*" + echo_error "Try '$0 -h' for more information." + ;; + esac +done + +# tmpdir directory, use environment variable TMPDIR +# if it was not specified, otherwise, error. +[ -n "$tmpdir" ] || tmpdir=$TMPDIR +[ -n "$tmpdir" ] || echo_error "No tmpdir found!" +[ -d "$tmpdir" ] || echo_error "Invalid tmpdir \"$tmpdir\"" +[ -n "$machines" ] || machines=$MACHINES +[ -n "$machines" ] || machines=$default_machines +[ -n "$targets" ] || targets=$TARGETS +[ -n "$targets" ] || targets=$default_targets + +OUTPUT=${tmpdir}/sstate-diff/`date "+%s"` + +for M in ${machines}; do + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f + mkdir -p ${OUTPUT}/${M} + export MACHINE=${M}; bitbake -S ${targets} | tee -a ${OUTPUT}/${M}/log; + cp -ra ${tmpdir}/stamps/* ${OUTPUT}/${M} + find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort > ${OUTPUT}/${M}/list + M_UNDERSCORE=`echo ${M} | sed 's/-/_/g'` + sed "s/${M_UNDERSCORE}/MACHINE/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort > ${OUTPUT}/${M}/list.M + find ${tmpdir}/stamps/ -name \*sigdata\* | xargs rm -f +done
Signature · 1 line
1.8.0