* qemuarm: should it really have TUNE_ARCH armv5te?
@ 2012-09-11 13:01 Martin Jansa
2012-09-11 13:48 ` Martin Jansa
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Martin Jansa @ 2012-09-11 13:01 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]
Hi,
when building spitz and qemuarm (both produces packages in armv5te feed)
resulting packages are tuned with -mtune=xscale (when built for spitz)
or -mtune=arm926ej-s (when built for qemuarm).
From
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended.
Does qemuarm use oe-core as it's intended?
Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs?
It would cause all recipes to build again (cannot share armv5te feed anymore),
but at least it would build it and user will really get it on target, right now
opkg upgrade can download some packages with xscale some with arm926ej-s.
$ ~/bitbake/bin/bitbake-diffsigs
stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1
Variable TUNE_CCARGS value changed from
${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}
to
${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 13:01 qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa @ 2012-09-11 13:48 ` Martin Jansa 2012-09-11 15:51 ` ARM-tuning -- was " Mark Hatle 2012-09-11 16:46 ` Phil Blundell 2012-09-12 14:33 ` Richard Purdie 2 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 13:48 UTC (permalink / raw) To: openembedded-core; +Cc: paul.eggleton [-- Attachment #1: Type: text/plain, Size: 4513 bytes --] On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: > Hi, > > when building spitz and qemuarm (both produces packages in armv5te feed) > resulting packages are tuned with -mtune=xscale (when built for spitz) > or -mtune=arm926ej-s (when built for qemuarm). > > From > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. > > Does qemuarm use oe-core as it's intended? CCing bluelightning because xscale is used in lot of meta-handheld machines: Does this make sense? OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*; diff -uNr tune-xscale.inc* --- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200 +++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200 @@ -8,4 +8,4 @@ AVAILTUNES += "arm926ejs" TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" - +TUNE_PKGARCH_tune-arm926ejs = "armv5te-arm926ejs" --- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200 +++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200 @@ -8,10 +8,12 @@ AVAILTUNES += "xscale" TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" +TUNE_PKGARCH_tune-xscale = "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}" +TUNE_PKGARCH_tune-xscale-be = "armv5teb-xscale" # webkit-gtk has alignment issues with double instructions on armv5 so # disable them here > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > It would cause all recipes to build again (cannot share armv5te feed anymore), > but at least it would build it and user will really get it on target, right now > opkg upgrade can download some packages with xscale some with arm926ej-s. > > $ ~/bitbake/bin/bitbake-diffsigs > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > Variable TUNE_CCARGS value changed from > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > to > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > -- > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 13:48 ` Martin Jansa @ 2012-09-11 15:51 ` Mark Hatle 2012-09-11 15:59 ` Martin Jansa 2012-09-11 16:13 ` Koen Kooi 0 siblings, 2 replies; 28+ messages in thread From: Mark Hatle @ 2012-09-11 15:51 UTC (permalink / raw) To: openembedded-core On 9/11/12 8:48 AM, Martin Jansa wrote: > On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: >> Hi, >> >> when building spitz and qemuarm (both produces packages in armv5te feed) >> resulting packages are tuned with -mtune=xscale (when built for spitz) >> or -mtune=arm926ej-s (when built for qemuarm). I argued this when we original did the work for the tunings, and I lost.... >> From >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 >> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. That is certainly my expectation. I'm not sure that the arm926ej-s can produce binaries that are -not- arm5te binaries -- as that seems to be the standard for what an armv5te is. The xscale on the other hand is capable of having different tuning parameters and had a few additional instructions. In the past I've generated a tuning simple called "xscale" that was compatible w/ armv5te. This way you could share non-optimized things, and go w/ xscale as necessary. >> Does qemuarm use oe-core as it's intended? > > CCing bluelightning because xscale is used in lot of meta-handheld machines: > > Does this make sense? > > OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*; diff -uNr tune-xscale.inc* > --- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200 > +++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200 > @@ -8,4 +8,4 @@ > AVAILTUNES += "arm926ejs" > TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" > PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > - > +TUNE_PKGARCH_tune-arm926ejs = "armv5te-arm926ejs" I'd suggest simply arm926ejs.... > --- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200 > +++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200 > @@ -8,10 +8,12 @@ > AVAILTUNES += "xscale" > TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" > PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > +TUNE_PKGARCH_tune-xscale = "armv5te-xscale" Again simplify to 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}" > +TUNE_PKGARCH_tune-xscale-be = "armv5teb-xscale" And xscaleeb (or be) --Mark > # webkit-gtk has alignment issues with double instructions on armv5 so > # disable them here > >> >> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? >> It would cause all recipes to build again (cannot share armv5te feed anymore), >> but at least it would build it and user will really get it on target, right now >> opkg upgrade can download some packages with xscale some with arm926ej-s. >> >> $ ~/bitbake/bin/bitbake-diffsigs >> stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc >> stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 >> basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 >> Variable TUNE_CCARGS value changed from >> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} >> to >> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} >> >> -- >> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com > > > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 15:51 ` ARM-tuning -- was " Mark Hatle @ 2012-09-11 15:59 ` Martin Jansa 2012-09-11 16:09 ` Mark Hatle 2012-09-11 16:13 ` Koen Kooi 1 sibling, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 15:59 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 7058 bytes --] On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote: > On 9/11/12 8:48 AM, Martin Jansa wrote: > > On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: > >> Hi, > >> > >> when building spitz and qemuarm (both produces packages in armv5te feed) > >> resulting packages are tuned with -mtune=xscale (when built for spitz) > >> or -mtune=arm926ej-s (when built for qemuarm). > > I argued this when we original did the work for the tunings, and I lost.... > > >> From > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > >> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. > > That is certainly my expectation. I'm not sure that the arm926ej-s can produce > binaries that are -not- arm5te binaries -- as that seems to be the standard for > what an armv5te is. The xscale on the other hand is capable of having different > tuning parameters and had a few additional instructions. In the past I've > generated a tuning simple called "xscale" that was compatible w/ armv5te. This > way you could share non-optimized things, and go w/ xscale as necessary. Few more comments I did on IRC: 16:41:23 < JaMa> let's hope RP will comment on that as that was his comment I was copy&pasting 16:41:53 < JaMa> e.g. ppc seems to set TUNE_PKGARCH for each tune-* 16:44:24 < JaMa> but it would be better to set xscale/arm926 tune only for packages where such -mtune brings some speedup (and for those where we set PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march 16:45:36 < JaMa> but mixed feed and -mtune=xscale packages on arm926 targets looks like worst case 16:50:20 < JaMa> oe-classic had the same issue with mixed -mtune in package arch feeds, but at least it wasn't rebuilding them after each machine switch And I'm not sure where we could decide what's worth -mtune and what is not, because in recipe we can do it only with a lot of _arch overrides and in tune file with lot of _pn-foo overrides (and some could be also in other layers then oe-core etc.) But it would be nice to share most packages as "general" armv5te between e.g. spitz and qemuarm builds. Cheers, > > >> Does qemuarm use oe-core as it's intended? > > > > CCing bluelightning because xscale is used in lot of meta-handheld machines: > > > > Does this make sense? > > > > OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*; diff -uNr tune-xscale.inc* > > --- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200 > > +++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200 > > @@ -8,4 +8,4 @@ > > AVAILTUNES += "arm926ejs" > > TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" > > PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > > - > > +TUNE_PKGARCH_tune-arm926ejs = "armv5te-arm926ejs" > > I'd suggest simply arm926ejs.... > > > --- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200 > > +++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200 > > @@ -8,10 +8,12 @@ > > AVAILTUNES += "xscale" > > TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" > > PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > > +TUNE_PKGARCH_tune-xscale = "armv5te-xscale" > > Again simplify to 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}" > > +TUNE_PKGARCH_tune-xscale-be = "armv5teb-xscale" > > And xscaleeb (or be) > > --Mark > > > # webkit-gtk has alignment issues with double instructions on armv5 so > > # disable them here > > > >> > >> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > >> It would cause all recipes to build again (cannot share armv5te feed anymore), > >> but at least it would build it and user will really get it on target, right now > >> opkg upgrade can download some packages with xscale some with arm926ej-s. > >> > >> $ ~/bitbake/bin/bitbake-diffsigs > >> stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > >> stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > >> basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > >> Variable TUNE_CCARGS value changed from > >> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > >> to > >> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > >> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > >> > >> -- > >> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com > > > > > > > > > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 15:59 ` Martin Jansa @ 2012-09-11 16:09 ` Mark Hatle 2012-09-11 16:22 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Mark Hatle @ 2012-09-11 16:09 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On 9/11/12 10:59 AM, Martin Jansa wrote: > On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote: >> On 9/11/12 8:48 AM, Martin Jansa wrote: >>> On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: >>>> Hi, >>>> >>>> when building spitz and qemuarm (both produces packages in armv5te feed) >>>> resulting packages are tuned with -mtune=xscale (when built for spitz) >>>> or -mtune=arm926ej-s (when built for qemuarm). >> >> I argued this when we original did the work for the tunings, and I lost.... >> >>>> From >>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 >>>> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. >> >> That is certainly my expectation. I'm not sure that the arm926ej-s can produce >> binaries that are -not- arm5te binaries -- as that seems to be the standard for >> what an armv5te is. The xscale on the other hand is capable of having different >> tuning parameters and had a few additional instructions. In the past I've >> generated a tuning simple called "xscale" that was compatible w/ armv5te. This >> way you could share non-optimized things, and go w/ xscale as necessary. > > Few more comments I did on IRC: > > 16:41:23 < JaMa> let's hope RP will comment on that as that was his comment I was copy&pasting > 16:41:53 < JaMa> e.g. ppc seems to set TUNE_PKGARCH for each tune-* > 16:44:24 < JaMa> but it would be better to set xscale/arm926 tune only for packages where such -mtune brings some speedup (and for those where we set PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march > 16:45:36 < JaMa> but mixed feed and -mtune=xscale packages on arm926 targets looks like worst case > 16:50:20 < JaMa> oe-classic had the same issue with mixed -mtune in package arch feeds, but at least it wasn't rebuilding them after each machine switch > > And I'm not sure where we could decide what's worth -mtune and what is not, > because in recipe we can do it only with a lot of _arch overrides and in tune > file with lot of _pn-foo overrides (and some could be also in other layers then oe-core etc.) > > But it would be nice to share most packages as "general" armv5te between e.g. spitz and qemuarm builds. This really hints that defining the tunings become a distribution configuration. You should be able to do: DEFAULTTUNE_pn-openssl = "xscale" To enable just openssl benefits from the xscale tunings. (The pn- may not be needed.. I can never remember anymore...) But that was the original idea with the tunings, make a way to specify DEFAULTTUNE for various things when alternative, but compatible tunings made a difference... set that in the distro.conf and you have an optimized distribution for specific uses. (You of course could also move that to a machine setting or similar file.) --Mark > Cheers, > >> >>>> Does qemuarm use oe-core as it's intended? >>> >>> CCing bluelightning because xscale is used in lot of meta-handheld machines: >>> >>> Does this make sense? >>> >>> OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*; diff -uNr tune-xscale.inc* >>> --- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200 >>> +++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200 >>> @@ -8,4 +8,4 @@ >>> AVAILTUNES += "arm926ejs" >>> TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" >>> PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" >>> - >>> +TUNE_PKGARCH_tune-arm926ejs = "armv5te-arm926ejs" >> >> I'd suggest simply arm926ejs.... >> >>> --- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200 >>> +++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200 >>> @@ -8,10 +8,12 @@ >>> AVAILTUNES += "xscale" >>> TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" >>> PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" >>> +TUNE_PKGARCH_tune-xscale = "armv5te-xscale" >> >> Again simplify to 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}" >>> +TUNE_PKGARCH_tune-xscale-be = "armv5teb-xscale" >> >> And xscaleeb (or be) >> >> --Mark >> >>> # webkit-gtk has alignment issues with double instructions on armv5 so >>> # disable them here >>> >>>> >>>> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? >>>> It would cause all recipes to build again (cannot share armv5te feed anymore), >>>> but at least it would build it and user will really get it on target, right now >>>> opkg upgrade can download some packages with xscale some with arm926ej-s. >>>> >>>> $ ~/bitbake/bin/bitbake-diffsigs >>>> stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc >>>> stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 >>>> basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 >>>> Variable TUNE_CCARGS value changed from >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} >>>> to >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} >>>> >>>> -- >>>> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >>> >> >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 16:09 ` Mark Hatle @ 2012-09-11 16:22 ` Martin Jansa 0 siblings, 0 replies; 28+ messages in thread From: Martin Jansa @ 2012-09-11 16:22 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 9064 bytes --] On Tue, Sep 11, 2012 at 11:09:53AM -0500, Mark Hatle wrote: > On 9/11/12 10:59 AM, Martin Jansa wrote: > > On Tue, Sep 11, 2012 at 10:51:40AM -0500, Mark Hatle wrote: > >> On 9/11/12 8:48 AM, Martin Jansa wrote: > >>> On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: > >>>> Hi, > >>>> > >>>> when building spitz and qemuarm (both produces packages in armv5te feed) > >>>> resulting packages are tuned with -mtune=xscale (when built for spitz) > >>>> or -mtune=arm926ej-s (when built for qemuarm). > >> > >> I argued this when we original did the work for the tunings, and I lost.... > >> > >>>> From > >>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > >>>> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. > >> > >> That is certainly my expectation. I'm not sure that the arm926ej-s can produce > >> binaries that are -not- arm5te binaries -- as that seems to be the standard for > >> what an armv5te is. The xscale on the other hand is capable of having different > >> tuning parameters and had a few additional instructions. In the past I've > >> generated a tuning simple called "xscale" that was compatible w/ armv5te. This > >> way you could share non-optimized things, and go w/ xscale as necessary. > > > > Few more comments I did on IRC: > > > > 16:41:23 < JaMa> let's hope RP will comment on that as that was his comment I was copy&pasting > > 16:41:53 < JaMa> e.g. ppc seems to set TUNE_PKGARCH for each tune-* > > 16:44:24 < JaMa> but it would be better to set xscale/arm926 tune only for packages where such -mtune brings some speedup (and for those where we set PACKAGE_ARCH = MACHINE_ARCH already) and build the rest only with -march > > 16:45:36 < JaMa> but mixed feed and -mtune=xscale packages on arm926 targets looks like worst case > > 16:50:20 < JaMa> oe-classic had the same issue with mixed -mtune in package arch feeds, but at least it wasn't rebuilding them after each machine switch > > > > And I'm not sure where we could decide what's worth -mtune and what is not, > > because in recipe we can do it only with a lot of _arch overrides and in tune > > file with lot of _pn-foo overrides (and some could be also in other layers then oe-core etc.) > > > > But it would be nice to share most packages as "general" armv5te between e.g. spitz and qemuarm builds. > > This really hints that defining the tunings become a distribution configuration. > > You should be able to do: > > DEFAULTTUNE_pn-openssl = "xscale" Where? in some distro config? What after I switch machine to some armv7a machine? (that's why I said a lot of _arch overrides) something like: # to set only armv5te as default (for most PN) DEFAULTTUNE_armv5te = "armv5te" # then use "optimized" DEFAULTTUNE where it's worth DEFAULTTUNE_pn-openssl_spitz = "xscale" DEFAULTTUNE_pn-openssl_mycorei7 = "corei7" But that sucks because I have to list all MACHINES which have some "optimized" DEFAULTTUNE. What about something like this: bitbake.conf: OPTDEFAULTTUNE ??= "${DEFAULTTUNE}" conf/machine/include/tune-xscale.inc: -DEFAULTTUNE ?= "xscale" +OPTDEFAULTTUNE ?= "xscale" conf/machine/include/tune-arm926ejs.inc -DEFAULTTUNE ?= "arm926ejs" +OPTDEFAULTTUNE ?= "arm926ejs" conf/distro/include/opt-default-tune.inc: DEFAULTTUNE_pn-openssl = ${OPTDEFAULTTUNE} DEFAULTTUNE_pn-mplayer = ${OPTDEFAULTTUNE} That would be easier to manage I guess. > > To enable just openssl benefits from the xscale tunings. (The pn- may not be > needed.. I can never remember anymore...) But that was the original idea with > the tunings, make a way to specify DEFAULTTUNE for various things when > alternative, but compatible tunings made a difference... set that in the > distro.conf and you have an optimized distribution for specific uses. (You of > course could also move that to a machine setting or similar file.) > > --Mark > > > Cheers, > > > >> > >>>> Does qemuarm use oe-core as it's intended? > >>> > >>> CCing bluelightning because xscale is used in lot of meta-handheld machines: > >>> > >>> Does this make sense? > >>> > >>> OE @ ~/openembedded-core/meta/conf/machine/include $ diff -uNr tune-arm926*; diff -uNr tune-xscale.inc* > >>> --- tune-arm926ejs.inc 2012-09-11 15:45:47.958202057 +0200 > >>> +++ tune-arm926ejs.inc.new 2012-09-11 15:45:40.579194777 +0200 > >>> @@ -8,4 +8,4 @@ > >>> AVAILTUNES += "arm926ejs" > >>> TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" > >>> PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > >>> - > >>> +TUNE_PKGARCH_tune-arm926ejs = "armv5te-arm926ejs" > >> > >> I'd suggest simply arm926ejs.... > >> > >>> --- tune-xscale.inc 2012-08-28 11:01:04.899070433 +0200 > >>> +++ tune-xscale.inc.new 2012-09-11 15:43:24.560060591 +0200 > >>> @@ -8,10 +8,12 @@ > >>> AVAILTUNES += "xscale" > >>> TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale" > >>> PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}" > >>> +TUNE_PKGARCH_tune-xscale = "armv5te-xscale" > >> > >> Again simplify to 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}" > >>> +TUNE_PKGARCH_tune-xscale-be = "armv5teb-xscale" > >> > >> And xscaleeb (or be) > >> > >> --Mark > >> > >>> # webkit-gtk has alignment issues with double instructions on armv5 so > >>> # disable them here > >>> > >>>> > >>>> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > >>>> It would cause all recipes to build again (cannot share armv5te feed anymore), > >>>> but at least it would build it and user will really get it on target, right now > >>>> opkg upgrade can download some packages with xscale some with arm926ej-s. > >>>> > >>>> $ ~/bitbake/bin/bitbake-diffsigs > >>>> stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > >>>> stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > >>>> basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > >>>> Variable TUNE_CCARGS value changed from > >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > >>>> to > >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > >>>> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > >>>> > >>>> -- > >>>> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Openembedded-core mailing list > >>> Openembedded-core@lists.openembedded.org > >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >>> > >> > >> > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core@lists.openembedded.org > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 15:51 ` ARM-tuning -- was " Mark Hatle 2012-09-11 15:59 ` Martin Jansa @ 2012-09-11 16:13 ` Koen Kooi 2012-09-11 18:40 ` Khem Raj 1 sibling, 1 reply; 28+ messages in thread From: Koen Kooi @ 2012-09-11 16:13 UTC (permalink / raw) To: Mark Hatle; +Cc: openembedded-core Op 11 sep. 2012, om 17:51 heeft Mark Hatle <mark.hatle@windriver.com> het volgende geschreven: > On 9/11/12 8:48 AM, Martin Jansa wrote: >> On Tue, Sep 11, 2012 at 03:01:55PM +0200, Martin Jansa wrote: >>> Hi, >>> >>> when building spitz and qemuarm (both produces packages in armv5te feed) >>> resulting packages are tuned with -mtune=xscale (when built for spitz) >>> or -mtune=arm926ej-s (when built for qemuarm). > > I argued this when we original did the work for the tunings, and I lost.... > >>> From >>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 >>> Firstly, if you go changing the tune parameters in a given machine, you are expected to use a different PACKAGE_ARCH. If you do that, you will get a different package feed for the different binaries, different WORKDIR and so on. This was always the way the package architectures was intended to work and nothing has changed there. Yes, you as the user changing various variables can create inconsistent package feeds. There are 101 ways you can do that, the simple answer is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR or remove PACKAGE_ARCH, please just use it as its intended. > > That is certainly my expectation. I'm not sure that the arm926ej-s can produce binaries that are -not- arm5te binaries -- as that seems to be the standard for what an armv5te is. The xscale on the other hand is capable of having different tuning parameters and had a few additional instructions. From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 16:13 ` Koen Kooi @ 2012-09-11 18:40 ` Khem Raj 2012-09-11 18:53 ` Phil Blundell 0 siblings, 1 reply; 28+ messages in thread From: Khem Raj @ 2012-09-11 18:40 UTC (permalink / raw) To: Koen Kooi; +Cc: openembedded-core On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. Not really, when you tune for XScale it will use ldrd/strd and pld if possible ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 18:40 ` Khem Raj @ 2012-09-11 18:53 ` Phil Blundell 2012-09-11 19:58 ` Khem Raj 0 siblings, 1 reply; 28+ messages in thread From: Phil Blundell @ 2012-09-11 18:53 UTC (permalink / raw) To: Khem Raj; +Cc: Koen Kooi, openembedded-core On Tue, 2012-09-11 at 11:40 -0700, Khem Raj wrote: > On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. > > Not really, when you tune for XScale it will use ldrd/strd and pld if possible Are you sure? As far as I remember, the only effects of -mtune=xscale are to alter some minor pipeline-related tradeoffs in code generation. In particular, LDM is especially slow on xscale so it is usually best avoided unless loading very large numbers of registers. I can't think of any reason why pld would be any more beneficial on xscale than generic v5TE, and I don't think gcc does anything special with it in that regard. p. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 18:53 ` Phil Blundell @ 2012-09-11 19:58 ` Khem Raj 0 siblings, 0 replies; 28+ messages in thread From: Khem Raj @ 2012-09-11 19:58 UTC (permalink / raw) To: Phil Blundell; +Cc: Koen Kooi, openembedded-core On (11/09/12 19:53), Phil Blundell wrote: > On Tue, 2012-09-11 at 11:40 -0700, Khem Raj wrote: > > On Tue, Sep 11, 2012 at 9:13 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > > From a gcc point of view both are the same ISA, but using xscale will take in account the absurdly long pipeline on that SoC. > > > > Not really, when you tune for XScale it will use ldrd/strd and pld if possible > > Are you sure? As far as I remember, the only effects of -mtune=xscale > are to alter some minor pipeline-related tradeoffs in code generation. > In particular, LDM is especially slow on xscale so it is usually best > avoided unless loading very large numbers of registers. yes that seems to be right looking at trunk and it does not prefer LDRD/STRD/PLD too. so all my claims are not valid anymore. const struct tune_params arm_xscale_tune = { arm_xscale_rtx_costs, xscale_sched_adjust_cost, 2, /* Constant limit. */ 3, /* Max cond insns. */ ARM_PREFETCH_NOT_BENEFICIAL, true, /* Prefer constant pool. */ arm_default_branch_cost, false /* Prefer LDRD/STRD. */ }; > > I can't think of any reason why pld would be any more beneficial on > xscale than generic v5TE, and I don't think gcc does anything special > with it in that regard. > > p. > > -- -Khem ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 13:01 qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa 2012-09-11 13:48 ` Martin Jansa @ 2012-09-11 16:46 ` Phil Blundell 2012-09-11 16:53 ` Martin Jansa 2012-09-12 14:33 ` Richard Purdie 2 siblings, 1 reply; 28+ messages in thread From: Phil Blundell @ 2012-09-11 16:46 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? That's a DISTRO policy decision really. "armv5te", in common with most of the PACKAGE_ARCHes, represents an ISA. That is, it is guaranteed to only contain instructions which are supported by all v5TE cores (which includes both ARM926EJ-S and XScale). It obviously follows from this that packages with PACKAGE_ARCH=armv5te are suitable for running on both qemuarm and xscale MACHINEs. Note that a binary that was built with -mtune=arm926ej-s is still an ARMv5TE binary and will run just fine on xscale. It won't run quite as fast as one that was built -mtune=xscale, though the performance difference is not so great as to be completely crippling. With current gcc, the reverse is true as well: a binary built -mtune=xscale is also still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the performance penalty is less this way around. Now, if your DISTRO feels that the performance difference is important enough to be worth distinguishing the packages, you can certainly arrange for those two tunings to get separate PACKAGE_ARCHes and maintain parallel feeds. But in the general case it's not totally obvious that this would be worthwhile, and I'm not sure it is a very useful thing to do by default. p. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 16:46 ` Phil Blundell @ 2012-09-11 16:53 ` Martin Jansa 2012-09-11 17:14 ` Phil Blundell 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 16:53 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 2131 bytes --] On Tue, Sep 11, 2012 at 05:46:12PM +0100, Phil Blundell wrote: > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > That's a DISTRO policy decision really. > > "armv5te", in common with most of the PACKAGE_ARCHes, represents an ISA. > That is, it is guaranteed to only contain instructions which are > supported by all v5TE cores (which includes both ARM926EJ-S and XScale). > It obviously follows from this that packages with PACKAGE_ARCH=armv5te > are suitable for running on both qemuarm and xscale MACHINEs. > > Note that a binary that was built with -mtune=arm926ej-s is still an > ARMv5TE binary and will run just fine on xscale. It won't run quite as > fast as one that was built -mtune=xscale, though the performance > difference is not so great as to be completely crippling. With current > gcc, the reverse is true as well: a binary built -mtune=xscale is also > still ARMv5TE and will run just fine on ARM926EJ-S, and in fact the > performance penalty is less this way around. > > Now, if your DISTRO feels that the performance difference is important > enough to be worth distinguishing the packages, you can certainly > arrange for those two tunings to get separate PACKAGE_ARCHes and > maintain parallel feeds. But in the general case it's not totally > obvious that this would be worthwhile, and I'm not sure it is a very > useful thing to do by default. But that is default now, that's why I've started this thread. It uses PACKAGE_ARCH=armv5te while using -mtune. Causing different sstate checksums and rebuilds when you switch e.g. qemuarm and spitz. If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then PACKAGE_ARCH=armv5te would be the same and the same feed will be built only once. And if DISTO feels that the performance difference is important then something like OPTDEFAULTTUNE could be added: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029455.html Cheers, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 16:53 ` Martin Jansa @ 2012-09-11 17:14 ` Phil Blundell 2012-09-11 17:21 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Phil Blundell @ 2012-09-11 17:14 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote: > If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then > PACKAGE_ARCH=armv5te would be the same and the same feed will be built > only once. Well, that would also make those two tune files rather useless. It seems like it would be better to just refrain from including them if you don't want the corresponding tunings. p. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 17:14 ` Phil Blundell @ 2012-09-11 17:21 ` Martin Jansa 2012-09-11 17:35 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 17:21 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 778 bytes --] On Tue, Sep 11, 2012 at 06:14:22PM +0100, Phil Blundell wrote: > On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote: > > If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then > > PACKAGE_ARCH=armv5te would be the same and the same feed will be built > > only once. > > Well, that would also make those two tune files rather useless. It > seems like it would be better to just refrain from including them if you > don't want the corresponding tunings. But that does not allow me to still use it for few packages if my DISTRO decides it's worth it. I'll test tomorrow, something like top 3 patches here: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune Cheers, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 17:21 ` Martin Jansa @ 2012-09-11 17:35 ` Martin Jansa 2012-09-11 17:37 ` Phil Blundell 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 17:35 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 1416 bytes --] On Tue, Sep 11, 2012 at 07:21:07PM +0200, Martin Jansa wrote: > On Tue, Sep 11, 2012 at 06:14:22PM +0100, Phil Blundell wrote: > > On Tue, 2012-09-11 at 18:53 +0200, Martin Jansa wrote: > > > If we drop DEFAULTTUNE from tune-xscale and tune-arm926ejs then > > > PACKAGE_ARCH=armv5te would be the same and the same feed will be built > > > only once. > > > > Well, that would also make those two tune files rather useless. It > > seems like it would be better to just refrain from including them if you > > don't want the corresponding tunings. > > But that does not allow me to still use it for few packages if my DISTRO > decides it's worth it. > > I'll test tomorrow, something like top 3 patches here: > http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune If this works then DISTRO would have 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 DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH == MACHINE_ARCH -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 17:35 ` Martin Jansa @ 2012-09-11 17:37 ` Phil Blundell 2012-09-11 17:43 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Phil Blundell @ 2012-09-11 17:37 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote: > If this works then DISTRO would have 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 > > DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH == > MACHINE_ARCH Yeah, that all sounds fairly reasonable to me. I'm not sure that optimized-tune.inc belongs in oe-core, since its contents is inherently distro-specific, but the general plan seems pretty good. p. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 17:37 ` Phil Blundell @ 2012-09-11 17:43 ` Martin Jansa 2012-09-11 18:00 ` Mark Hatle 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-11 17:43 UTC (permalink / raw) To: Phil Blundell; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 1318 bytes --] On Tue, Sep 11, 2012 at 06:37:23PM +0100, Phil Blundell wrote: > On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote: > > If this works then DISTRO would have 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 > > > > DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH == > > MACHINE_ARCH > > Yeah, that all sounds fairly reasonable to me. I'm not sure that > optimized-tune.inc belongs in oe-core, since its contents is inherently > distro-specific, but the general plan seems pretty good. OK, thanks I've put optimized-tune.inc to oe-core only to share knowledge of which packages are worth using OPTDEFAULTTUNE, but I expect DISTRO maintainers to add their own entries too (e.g. for stuff which is only in their own layer), so I'm fine with optimized-tune.inc in meta-distro too. Cheers, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 17:43 ` Martin Jansa @ 2012-09-11 18:00 ` Mark Hatle 0 siblings, 0 replies; 28+ messages in thread From: Mark Hatle @ 2012-09-11 18:00 UTC (permalink / raw) To: openembedded-core On 9/11/12 12:43 PM, Martin Jansa wrote: > On Tue, Sep 11, 2012 at 06:37:23PM +0100, Phil Blundell wrote: >> On Tue, 2012-09-11 at 19:35 +0200, Martin Jansa wrote: >>> If this works then DISTRO would have 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 >>> >>> DEFAULTTUNE = ${OPTDEFAULTTUNE} should also be used for PACKAGE_ARCH == >>> MACHINE_ARCH >> >> Yeah, that all sounds fairly reasonable to me. I'm not sure that >> optimized-tune.inc belongs in oe-core, since its contents is inherently >> distro-specific, but the general plan seems pretty good. > > OK, thanks > > I've put optimized-tune.inc to oe-core only to share knowledge of which > packages are worth using OPTDEFAULTTUNE, but I expect DISTRO maintainers > to add their own entries too (e.g. for stuff which is only in their own > layer), so I'm fine with optimized-tune.inc in meta-distro too. Along those lines.. I'm always asked for optimized crypto libraries (nss, openssl, beecrypt, etc...), database (mysql or similar), codecs, sometimes libc itself, and graphics drivers.. otherwise nobody seems to care if it's "good enough". --Mark > Cheers, > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-11 13:01 qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa 2012-09-11 13:48 ` Martin Jansa 2012-09-11 16:46 ` Phil Blundell @ 2012-09-12 14:33 ` Richard Purdie 2012-09-13 6:20 ` Martin Jansa 2 siblings, 1 reply; 28+ messages in thread From: Richard Purdie @ 2012-09-12 14:33 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > Hi, > > when building spitz and qemuarm (both produces packages in armv5te feed) > resulting packages are tuned with -mtune=xscale (when built for spitz) > or -mtune=arm926ej-s (when built for qemuarm). > > From > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > Firstly, if you go changing the tune parameters in a given machine, > you are expected to use a different PACKAGE_ARCH. If you do that, you > will get a different package feed for the different binaries, > different WORKDIR and so on. This was always the way the package > architectures was intended to work and nothing has changed there. Yes, > you as the user changing various variables can create inconsistent > package feeds. There are 101 ways you can do that, the simple answer > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > or remove PACKAGE_ARCH, please just use it as its intended. > > Does qemuarm use oe-core as it's intended? > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > It would cause all recipes to build again (cannot share armv5te feed anymore), > but at least it would build it and user will really get it on target, right now > opkg upgrade can download some packages with xscale some with arm926ej-s. > > $ ~/bitbake/bin/bitbake-diffsigs > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > Variable TUNE_CCARGS value changed from > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > to > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > This is a tricky one. As others have mentioned, this is a tune parameter, not an arch one and as such the binaries are compatible with each other although they potentially are compiled differently with different optimisations. As such, mixing the feeds is permitted and will not cause any real world usage problem. As you point out, sstate is much more sensitive to this kind of change and is correctly deciding the output is different though. I think my preferred approach would be to have the tune files do something like: -mtune=${ARMV5TEDEFAULTTUNE} and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a appropriate. This would result in the package feed at least having a consistent state of one tune and sstate would be happy. It then becomes a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE would default to the current values meaning the distro would then just do: ARMV5TEDEFAULTTUNE_poky = "xscale" and hence make their decision. Of course the distro could also decide to split the package architectures up which is equally fine. Does something like that sound like it would work? Cheers, Richard ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-12 14:33 ` Richard Purdie @ 2012-09-13 6:20 ` Martin Jansa 2012-09-13 10:42 ` Richard Purdie 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-13 6:20 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 4605 bytes --] On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > Hi, > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > or -mtune=arm926ej-s (when built for qemuarm). > > > > From > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > Firstly, if you go changing the tune parameters in a given machine, > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > will get a different package feed for the different binaries, > > different WORKDIR and so on. This was always the way the package > > architectures was intended to work and nothing has changed there. Yes, > > you as the user changing various variables can create inconsistent > > package feeds. There are 101 ways you can do that, the simple answer > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > Does qemuarm use oe-core as it's intended? > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > but at least it would build it and user will really get it on target, right now > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > $ ~/bitbake/bin/bitbake-diffsigs > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > Variable TUNE_CCARGS value changed from > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > to > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > This is a tricky one. As others have mentioned, this is a tune > parameter, not an arch one and as such the binaries are compatible with > each other although they potentially are compiled differently with > different optimisations. > > As such, mixing the feeds is permitted and will not cause any real world > usage problem. As you point out, sstate is much more sensitive to this > kind of change and is correctly deciding the output is different though. > > I think my preferred approach would be to have the tune files do > something like: > > -mtune=${ARMV5TEDEFAULTTUNE} > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > appropriate. This would result in the package feed at least having a > consistent state of one tune and sstate would be happy. It then becomes > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > would default to the current values meaning the distro would then just > do: > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > and hence make their decision. Of course the distro could also decide to > split the package architectures up which is equally fine. > > Does something like that sound like it would work? My solution seems to be a bit more flexible then this. -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 6:20 ` Martin Jansa @ 2012-09-13 10:42 ` Richard Purdie 2012-09-13 12:14 ` Martin Jansa 2012-09-13 16:47 ` Mark Hatle 0 siblings, 2 replies; 28+ messages in thread From: Richard Purdie @ 2012-09-13 10:42 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: > On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > > Hi, > > > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > > or -mtune=arm926ej-s (when built for qemuarm). > > > > > > From > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > > Firstly, if you go changing the tune parameters in a given machine, > > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > > will get a different package feed for the different binaries, > > > different WORKDIR and so on. This was always the way the package > > > architectures was intended to work and nothing has changed there. Yes, > > > you as the user changing various variables can create inconsistent > > > package feeds. There are 101 ways you can do that, the simple answer > > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > > > Does qemuarm use oe-core as it's intended? > > > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > > but at least it would build it and user will really get it on target, right now > > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > > > $ ~/bitbake/bin/bitbake-diffsigs > > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > > Variable TUNE_CCARGS value changed from > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > > to > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > > > > This is a tricky one. As others have mentioned, this is a tune > > parameter, not an arch one and as such the binaries are compatible with > > each other although they potentially are compiled differently with > > different optimisations. > > > > As such, mixing the feeds is permitted and will not cause any real world > > usage problem. As you point out, sstate is much more sensitive to this > > kind of change and is correctly deciding the output is different though. > > > > I think my preferred approach would be to have the tune files do > > something like: > > > > -mtune=${ARMV5TEDEFAULTTUNE} > > > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > > appropriate. This would result in the package feed at least having a > > consistent state of one tune and sstate would be happy. It then becomes > > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > > would default to the current values meaning the distro would then just > > do: > > > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > > > and hence make their decision. Of course the distro could also decide to > > split the package architectures up which is equally fine. > > > > Does something like that sound like it would work? > > My solution seems to be a bit more flexible then this. Which cases does it enable which the above doesn't? I'm a little worried about adding more indirection to the DEFAULTTUNE variable itself since the whole tune situation is already convoluted and indirected enough without adding another level of it :/. That variable is the one exposed to the user straight away, not hidden more behind the scenes. Taking a step back and looking at the APIs I'm really not very happy with the usability of them already and I don't think this helps. Someone commented about the ppc situation and I was told that there, the binaries are incompatible with each other. It is more unusual to have situations where there are micro-optimisations through -mtune yet the binaries remain compatible. Cheers, Richard ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 10:42 ` Richard Purdie @ 2012-09-13 12:14 ` Martin Jansa 2012-09-13 12:58 ` Richard Purdie 2012-09-13 16:47 ` Mark Hatle 1 sibling, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-13 12:14 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 6251 bytes --] On Thu, Sep 13, 2012 at 11:42:06AM +0100, Richard Purdie wrote: > On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: > > On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > > > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > > > Hi, > > > > > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > > > or -mtune=arm926ej-s (when built for qemuarm). > > > > > > > > From > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > > > Firstly, if you go changing the tune parameters in a given machine, > > > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > > > will get a different package feed for the different binaries, > > > > different WORKDIR and so on. This was always the way the package > > > > architectures was intended to work and nothing has changed there. Yes, > > > > you as the user changing various variables can create inconsistent > > > > package feeds. There are 101 ways you can do that, the simple answer > > > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > > > > > Does qemuarm use oe-core as it's intended? > > > > > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > > > but at least it would build it and user will really get it on target, right now > > > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > > > > > $ ~/bitbake/bin/bitbake-diffsigs > > > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > > > Variable TUNE_CCARGS value changed from > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > > > to > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > > > > > > > This is a tricky one. As others have mentioned, this is a tune > > > parameter, not an arch one and as such the binaries are compatible with > > > each other although they potentially are compiled differently with > > > different optimisations. > > > > > > As such, mixing the feeds is permitted and will not cause any real world > > > usage problem. As you point out, sstate is much more sensitive to this > > > kind of change and is correctly deciding the output is different though. > > > > > > I think my preferred approach would be to have the tune files do > > > something like: > > > > > > -mtune=${ARMV5TEDEFAULTTUNE} > > > > > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > > > appropriate. This would result in the package feed at least having a > > > consistent state of one tune and sstate would be happy. It then becomes > > > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > > > would default to the current values meaning the distro would then just > > > do: > > > > > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > > > > > and hence make their decision. Of course the distro could also decide to > > > split the package architectures up which is equally fine. > > > > > > Does something like that sound like it would work? > > > > My solution seems to be a bit more flexible then this. > > Which cases does it enable which the above doesn't? To have separate binary feeds for some packages while keeping most of other packages in armv5te feed without any -mtune or with some ARMV5TEDEFAULTTUNE. But -mtune=${ARMV5TEDEFAULTTUNE} in tune-arm926ejs.inc with xscale value set through ARMV5TEDEFAULTTUNE_disto doesn't look very intuitive. And how many .*DEFAUTTUNE variables distro should set? Anyway I'll be off for next 10 days or so.. > I'm a little worried about adding more indirection to the DEFAULTTUNE > variable itself since the whole tune situation is already convoluted and > indirected enough without adding another level of it :/. That variable > is the one exposed to the user straight away, not hidden more behind the > scenes. > > Taking a step back and looking at the APIs I'm really not very happy > with the usability of them already and I don't think this helps. > > Someone commented about the ppc situation and I was told that there, the > binaries are incompatible with each other. It is more unusual to have > situations where there are micro-optimisations through -mtune yet the > binaries remain compatible. > > Cheers, > > Richard > > -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 12:14 ` Martin Jansa @ 2012-09-13 12:58 ` Richard Purdie 2012-09-15 7:01 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Richard Purdie @ 2012-09-13 12:58 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Thu, 2012-09-13 at 14:14 +0200, Martin Jansa wrote: > On Thu, Sep 13, 2012 at 11:42:06AM +0100, Richard Purdie wrote: > > On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: > > > On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > > > > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > > > > Hi, > > > > > > > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > > > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > > > > or -mtune=arm926ej-s (when built for qemuarm). > > > > > > > > > > From > > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > > > > Firstly, if you go changing the tune parameters in a given machine, > > > > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > > > > will get a different package feed for the different binaries, > > > > > different WORKDIR and so on. This was always the way the package > > > > > architectures was intended to work and nothing has changed there. Yes, > > > > > you as the user changing various variables can create inconsistent > > > > > package feeds. There are 101 ways you can do that, the simple answer > > > > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > > > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > > > > > > > Does qemuarm use oe-core as it's intended? > > > > > > > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > > > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > > > > but at least it would build it and user will really get it on target, right now > > > > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > > > > > > > $ ~/bitbake/bin/bitbake-diffsigs > > > > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > > > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > > > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > > > > Variable TUNE_CCARGS value changed from > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > > > > to > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > > > > > > > > > > This is a tricky one. As others have mentioned, this is a tune > > > > parameter, not an arch one and as such the binaries are compatible with > > > > each other although they potentially are compiled differently with > > > > different optimisations. > > > > > > > > As such, mixing the feeds is permitted and will not cause any real world > > > > usage problem. As you point out, sstate is much more sensitive to this > > > > kind of change and is correctly deciding the output is different though. > > > > > > > > I think my preferred approach would be to have the tune files do > > > > something like: > > > > > > > > -mtune=${ARMV5TEDEFAULTTUNE} > > > > > > > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > > > > appropriate. This would result in the package feed at least having a > > > > consistent state of one tune and sstate would be happy. It then becomes > > > > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > > > > would default to the current values meaning the distro would then just > > > > do: > > > > > > > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > > > > > > > and hence make their decision. Of course the distro could also decide to > > > > split the package architectures up which is equally fine. > > > > > > > > Does something like that sound like it would work? > > > > > > My solution seems to be a bit more flexible then this. > > > > Which cases does it enable which the above doesn't? > > To have separate binary feeds for some packages while keeping most of > other packages in armv5te feed without any -mtune or with some > ARMV5TEDEFAULTTUNE. Firstly, lets clearly define what the problems are. We want to have some packages with the existing tune in separate feeds and have other packages sharing (or have no) mtune values? The reason I say that is that initially this looked like a problem with sstate and the specific mtune values which is a relatively generic and widespread issue. The problem described above is implementation of what is very specific distro policy. I want to be clear about which problem(s) we're solving as that is leading to confusion discussing it. If the problem(s) we're solving are the distro feed one rather than sstate, the problem is more specific the distro policy and I'd expect the distro itself to be handling this and not the core. > But -mtune=${ARMV5TEDEFAULTTUNE} in tune-arm926ejs.inc with > xscale value set through ARMV5TEDEFAULTTUNE_disto doesn't look very > intuitive. I'm not saying that it is. What I'm saying is that it puts the pain in the place of the person trying to do the deep configuration and isn't the first thing a new user hits and struggles with. We can add variables for *everything*. That doesn't mean that we should and this is one case that I think the proposal complicates something that is already too complicated, badly (under) documented and being misused (see the number of patches I've seen recently abusing DEFAULTTUNE). At least if the tune files and system was well documented I might feel better about things but right now it isn't. > And how many .*DEFAUTTUNE variables distro should set? As soon as you enter the world of recipe specific tunings, I suspect a number of variables are going to need to get set. Cheers, Richard ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 12:58 ` Richard Purdie @ 2012-09-15 7:01 ` Martin Jansa 2012-09-21 15:52 ` Martin Jansa 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-15 7:01 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 8440 bytes --] On Thu, Sep 13, 2012 at 01:58:31PM +0100, Richard Purdie wrote: > On Thu, 2012-09-13 at 14:14 +0200, Martin Jansa wrote: > > On Thu, Sep 13, 2012 at 11:42:06AM +0100, Richard Purdie wrote: > > > On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: > > > > On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > > > > > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > > > > > Hi, > > > > > > > > > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > > > > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > > > > > or -mtune=arm926ej-s (when built for qemuarm). > > > > > > > > > > > > From > > > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > > > > > Firstly, if you go changing the tune parameters in a given machine, > > > > > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > > > > > will get a different package feed for the different binaries, > > > > > > different WORKDIR and so on. This was always the way the package > > > > > > architectures was intended to work and nothing has changed there. Yes, > > > > > > you as the user changing various variables can create inconsistent > > > > > > package feeds. There are 101 ways you can do that, the simple answer > > > > > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > > > > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > > > > > > > > > Does qemuarm use oe-core as it's intended? > > > > > > > > > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > > > > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > > > > > but at least it would build it and user will really get it on target, right now > > > > > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > > > > > > > > > $ ~/bitbake/bin/bitbake-diffsigs > > > > > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > > > > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > > > > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > > > > > Variable TUNE_CCARGS value changed from > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > > > > > to > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > > > > > > > > > > > > > This is a tricky one. As others have mentioned, this is a tune > > > > > parameter, not an arch one and as such the binaries are compatible with > > > > > each other although they potentially are compiled differently with > > > > > different optimisations. > > > > > > > > > > As such, mixing the feeds is permitted and will not cause any real world > > > > > usage problem. As you point out, sstate is much more sensitive to this > > > > > kind of change and is correctly deciding the output is different though. > > > > > > > > > > I think my preferred approach would be to have the tune files do > > > > > something like: > > > > > > > > > > -mtune=${ARMV5TEDEFAULTTUNE} > > > > > > > > > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > > > > > appropriate. This would result in the package feed at least having a > > > > > consistent state of one tune and sstate would be happy. It then becomes > > > > > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > > > > > would default to the current values meaning the distro would then just > > > > > do: > > > > > > > > > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > > > > > > > > > and hence make their decision. Of course the distro could also decide to > > > > > split the package architectures up which is equally fine. > > > > > > > > > > Does something like that sound like it would work? > > > > > > > > My solution seems to be a bit more flexible then this. > > > > > > Which cases does it enable which the above doesn't? > > > > To have separate binary feeds for some packages while keeping most of > > other packages in armv5te feed without any -mtune or with some > > ARMV5TEDEFAULTTUNE. > > Firstly, lets clearly define what the problems are. We want to have some > packages with the existing tune in separate feeds and have other > packages sharing (or have no) mtune values? The proble is, that tune-cpu.inc files sets different -mcpu while keeping the same PACKAGE_ARCH (first commit in my brach) > The reason I say that is that initially this looked like a problem with > sstate and the specific mtune values which is a relatively generic and > widespread issue. The problem described above is implementation of what > is very specific distro policy. I want to be clear about which > problem(s) we're solving as that is leading to confusion discussing it. sstate is "correctly" detecting -mcpu change and rebuild all packages with new mcpu, but resulting ipk are in the same arch -> user wont see which -mcpu was used to buld particular .ipk. > If the problem(s) we're solving are the distro feed one rather than > sstate, the problem is more specific the distro policy and I'd expect > the distro itself to be handling this and not the core. If I add those PACKAGE_ARCH setting to each tune* which sets new DEFAULTUNE them some distributions can see it as regression as e.g. xscale and arm926ejs feed will need twice as much space as now shared armv5te. Removin tune-cpu from machine config also seems bad, because of loosing the option to use correct -mcpu. That's my solution keeps all information "local" in tune file DEFAULTTUNE will be set to generic arm5te OPTDEFAULTTUN to xscale and distro then can choose which one to use by default or for some packages.. see my e-mail about it (I won't write it again because I'm writting from phone) > > But -mtune=${ARMV5TEDEFAULTTUNE} in tune-arm926ejs.inc with > > xscale value set through ARMV5TEDEFAULTTUNE_disto doesn't look very > > intuitive. > > I'm not saying that it is. What I'm saying is that it puts the pain in > the place of the person trying to do the deep configuration and isn't > the first thing a new user hits and struggles with. > > We can add variables for *everything*. That doesn't mean that we should > and this is one case that I think the proposal complicates something > that is already too complicated, badly (under) documented and being > misused (see the number of patches I've seen recently abusing > DEFAULTTUNE). > > At least if the tune files and system was well documented I might feel > better about things but right now it isn't. > > > And how many .*DEFAUTTUNE variables distro should set? > > As soon as you enter the world of recipe specific tunings, I suspect a > number of variables are going to need to get set. > > Cheers, > > Richard > -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-15 7:01 ` Martin Jansa @ 2012-09-21 15:52 ` Martin Jansa 2012-09-22 11:48 ` Richard Purdie 0 siblings, 1 reply; 28+ messages in thread From: Martin Jansa @ 2012-09-21 15:52 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 11081 bytes --] On Sat, Sep 15, 2012 at 09:01:42AM +0200, Martin Jansa wrote: > On Thu, Sep 13, 2012 at 01:58:31PM +0100, Richard Purdie wrote: > > On Thu, 2012-09-13 at 14:14 +0200, Martin Jansa wrote: > > > On Thu, Sep 13, 2012 at 11:42:06AM +0100, Richard Purdie wrote: > > > > On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: > > > > > On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: > > > > > > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: > > > > > > > Hi, > > > > > > > > > > > > > > when building spitz and qemuarm (both produces packages in armv5te feed) > > > > > > > resulting packages are tuned with -mtune=xscale (when built for spitz) > > > > > > > or -mtune=arm926ej-s (when built for qemuarm). > > > > > > > > > > > > > > From > > > > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 > > > > > > > Firstly, if you go changing the tune parameters in a given machine, > > > > > > > you are expected to use a different PACKAGE_ARCH. If you do that, you > > > > > > > will get a different package feed for the different binaries, > > > > > > > different WORKDIR and so on. This was always the way the package > > > > > > > architectures was intended to work and nothing has changed there. Yes, > > > > > > > you as the user changing various variables can create inconsistent > > > > > > > package feeds. There are 101 ways you can do that, the simple answer > > > > > > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR > > > > > > > or remove PACKAGE_ARCH, please just use it as its intended. > > > > > > > > > > > > > > Does qemuarm use oe-core as it's intended? > > > > > > > > > > > > > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? > > > > > > > It would cause all recipes to build again (cannot share armv5te feed anymore), > > > > > > > but at least it would build it and user will really get it on target, right now > > > > > > > opkg upgrade can download some packages with xscale some with arm926ej-s. > > > > > > > > > > > > > > $ ~/bitbake/bin/bitbake-diffsigs > > > > > > > stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc > > > > > > > stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 > > > > > > > basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 > > > > > > > Variable TUNE_CCARGS value changed from > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > > > > > > > to > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > > > > > > > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > > > > > > > > > > > > > > > > > > > This is a tricky one. As others have mentioned, this is a tune > > > > > > parameter, not an arch one and as such the binaries are compatible with > > > > > > each other although they potentially are compiled differently with > > > > > > different optimisations. > > > > > > > > > > > > As such, mixing the feeds is permitted and will not cause any real world > > > > > > usage problem. As you point out, sstate is much more sensitive to this > > > > > > kind of change and is correctly deciding the output is different though. > > > > > > > > > > > > I think my preferred approach would be to have the tune files do > > > > > > something like: > > > > > > > > > > > > -mtune=${ARMV5TEDEFAULTTUNE} > > > > > > > > > > > > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a > > > > > > appropriate. This would result in the package feed at least having a > > > > > > consistent state of one tune and sstate would be happy. It then becomes > > > > > > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE > > > > > > would default to the current values meaning the distro would then just > > > > > > do: > > > > > > > > > > > > ARMV5TEDEFAULTTUNE_poky = "xscale" > > > > > > > > > > > > and hence make their decision. Of course the distro could also decide to > > > > > > split the package architectures up which is equally fine. > > > > > > > > > > > > Does something like that sound like it would work? > > > > > > > > > > My solution seems to be a bit more flexible then this. > > > > > > > > Which cases does it enable which the above doesn't? > > > > > > To have separate binary feeds for some packages while keeping most of > > > other packages in armv5te feed without any -mtune or with some > > > ARMV5TEDEFAULTTUNE. > > > > Firstly, lets clearly define what the problems are. We want to have some > > packages with the existing tune in separate feeds and have other > > packages sharing (or have no) mtune values? > > The proble is, that tune-cpu.inc files sets different -mcpu while > keeping the same PACKAGE_ARCH (first commit in my brach) > > > The reason I say that is that initially this looked like a problem with > > sstate and the specific mtune values which is a relatively generic and > > widespread issue. The problem described above is implementation of what > > is very specific distro policy. I want to be clear about which > > problem(s) we're solving as that is leading to confusion discussing it. > > sstate is "correctly" detecting -mcpu change and rebuild all packages > with new mcpu, but resulting ipk are in the same arch -> user wont see > which -mcpu was used to buld particular .ipk. > > > If the problem(s) we're solving are the distro feed one rather than > > sstate, the problem is more specific the distro policy and I'd expect > > the distro itself to be handling this and not the core. > > If I add those PACKAGE_ARCH setting to each tune* which sets new > DEFAULTUNE them some distributions can see it as regression as e.g. > xscale and arm926ejs feed will need twice as much space as now shared > armv5te. > > Removin tune-cpu from machine config also seems bad, because of loosing > the option to use correct -mcpu. > > That's my solution keeps all information "local" in tune file > DEFAULTTUNE will be set to generic arm5te > OPTDEFAULTTUN to xscale > > and distro then can choose which one to use by default or for some > packages.. see my e-mail about it (I won't write it again because I'm > writting from phone) Even with last version of jansa/tune it does not really help with rebuilds $ bitbake-diffsigs stamps.1348241943/*/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure* basehash changed from 82dd3229952508550532e9ab37e78dc4 to 1d04ba204fe9afb1d346156dc066da93 Variable TUNE_CCARGS value changed from ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} to ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} Hash for dependent task linux-libc-headers_3.4.3.bb.do_patch changed from 4d1f46fa912bc21421d343811acab517 to 663e25ca238e049eaff02fd288c5342e So even if I let both machines using only armv5 thumb dsp TUNE_FEATURES it still rebuilds e.g. linux-libc-headers. We can merge all those TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}" fragmets to arch-armv5-dsp.inc, but that doesn't look very correct too (imagine someone who wants to add new tune-magicfoo in his BSP which adds another possible value for TUNE_FEATURES but still uses armv5te feed. Any idea? Cheers, > > > > But -mtune=${ARMV5TEDEFAULTTUNE} in tune-arm926ejs.inc with > > > xscale value set through ARMV5TEDEFAULTTUNE_disto doesn't look very > > > intuitive. > > > > I'm not saying that it is. What I'm saying is that it puts the pain in > > the place of the person trying to do the deep configuration and isn't > > the first thing a new user hits and struggles with. > > > > We can add variables for *everything*. That doesn't mean that we should > > and this is one case that I think the proposal complicates something > > that is already too complicated, badly (under) documented and being > > misused (see the number of patches I've seen recently abusing > > DEFAULTTUNE). > > > > At least if the tune files and system was well documented I might feel > > better about things but right now it isn't. > > > > > And how many .*DEFAUTTUNE variables distro should set? > > > > As soon as you enter the world of recipe specific tunings, I suspect a > > number of variables are going to need to get set. > > > > Cheers, > > > > Richard > > > > -- > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-21 15:52 ` Martin Jansa @ 2012-09-22 11:48 ` Richard Purdie 0 siblings, 0 replies; 28+ messages in thread From: Richard Purdie @ 2012-09-22 11:48 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core On Fri, 2012-09-21 at 17:52 +0200, Martin Jansa wrote: > Even with last version of jansa/tune it does not really help with > rebuilds > > $ bitbake-diffsigs stamps.1348241943/*/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure* > basehash changed from 82dd3229952508550532e9ab37e78dc4 to 1d04ba204fe9afb1d346156dc066da93 > Variable TUNE_CCARGS value changed from > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} > to > ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} > ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} > ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} > ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} > Hash for dependent task linux-libc-headers_3.4.3.bb.do_patch changed from 4d1f46fa912bc21421d343811acab517 to 663e25ca238e049eaff02fd288c5342e > > So even if I let both machines using only armv5 thumb dsp TUNE_FEATURES it still > rebuilds e.g. linux-libc-headers. > > We can merge all those > TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}" > fragmets to arch-armv5-dsp.inc, but that doesn't look very correct too (imagine someone who > wants to add new tune-magicfoo in his BSP which adds another possible value for TUNE_FEATURES > but still uses armv5te feed. > > Any idea? TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}" This should flatten it. We care about the final value, not how its obtained in this case. Cheers, Richard ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 10:42 ` Richard Purdie 2012-09-13 12:14 ` Martin Jansa @ 2012-09-13 16:47 ` Mark Hatle 2012-09-13 17:02 ` Phil Blundell 1 sibling, 1 reply; 28+ messages in thread From: Mark Hatle @ 2012-09-13 16:47 UTC (permalink / raw) To: openembedded-core On 9/13/12 5:42 AM, Richard Purdie wrote: > On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote: >> On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote: >>> On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote: >>>> Hi, >>>> >>>> when building spitz and qemuarm (both produces packages in armv5te feed) >>>> resulting packages are tuned with -mtune=xscale (when built for spitz) >>>> or -mtune=arm926ej-s (when built for qemuarm). >>>> >>>> From >>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5 >>>> Firstly, if you go changing the tune parameters in a given machine, >>>> you are expected to use a different PACKAGE_ARCH. If you do that, you >>>> will get a different package feed for the different binaries, >>>> different WORKDIR and so on. This was always the way the package >>>> architectures was intended to work and nothing has changed there. Yes, >>>> you as the user changing various variables can create inconsistent >>>> package feeds. There are 101 ways you can do that, the simple answer >>>> is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR >>>> or remove PACKAGE_ARCH, please just use it as its intended. >>>> >>>> Does qemuarm use oe-core as it's intended? >>>> >>>> Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs? >>>> It would cause all recipes to build again (cannot share armv5te feed anymore), >>>> but at least it would build it and user will really get it on target, right now >>>> opkg upgrade can download some packages with xscale some with arm926ej-s. >>>> >>>> $ ~/bitbake/bin/bitbake-diffsigs >>>> stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc >>>> stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14 >>>> basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1 >>>> Variable TUNE_CCARGS value changed from >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} >>>> to >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} >>>> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)} >>>> >>> >>> This is a tricky one. As others have mentioned, this is a tune >>> parameter, not an arch one and as such the binaries are compatible with >>> each other although they potentially are compiled differently with >>> different optimisations. >>> >>> As such, mixing the feeds is permitted and will not cause any real world >>> usage problem. As you point out, sstate is much more sensitive to this >>> kind of change and is correctly deciding the output is different though. >>> >>> I think my preferred approach would be to have the tune files do >>> something like: >>> >>> -mtune=${ARMV5TEDEFAULTTUNE} >>> >>> and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a >>> appropriate. This would result in the package feed at least having a >>> consistent state of one tune and sstate would be happy. It then becomes >>> a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE >>> would default to the current values meaning the distro would then just >>> do: >>> >>> ARMV5TEDEFAULTTUNE_poky = "xscale" >>> >>> and hence make their decision. Of course the distro could also decide to >>> split the package architectures up which is equally fine. >>> >>> Does something like that sound like it would work? >> >> My solution seems to be a bit more flexible then this. > > Which cases does it enable which the above doesn't? > > I'm a little worried about adding more indirection to the DEFAULTTUNE > variable itself since the whole tune situation is already convoluted and > indirected enough without adding another level of it :/. That variable > is the one exposed to the user straight away, not hidden more behind the > scenes. > > Taking a step back and looking at the APIs I'm really not very happy > with the usability of them already and I don't think this helps. > > Someone commented about the ppc situation and I was told that there, the > binaries are incompatible with each other. It is more unusual to have > situations where there are micro-optimisations through -mtune yet the > binaries remain compatible. On PPC there are a bunch of different ABIs: PPC32 (Classic) PPC32-soft float (Classic) PPC32-e500v1 (e500v1 instructions and registers) PPC32-e500v2 (e500v2 instructions and registers) There are some variations in the classic mode, w/ and w/o using Altivec. However, on PPC the save/restore of variables on context switching is done using exception handling -- and register passing for classic mode is always through normal registers. They do have variants of processors for the PPC32 and PPC32-soft float ABIs, for each variant we just assign a new package arch -- and then make that compatible with the other package archs. (Almost exactly the same way it's done on traditional Linux systems on x86). So in the end you really have two levels of information that make up the package ARCH. ABI & CPU instructions/optimization. MIPS is a bit more complex, but generally the same rules apply. You have ABI and processor optimizations that produce the package ARCH. ARM seems to be the one exception, where you have three levels.. ABI (EABI/hf-EABI), processor family (armv4, armv5, armv7, cortext....), and then CPU optimization. This seems to cause additional confusion, as the CPU optimizations are not being captured in the current package ARCH, which makes it difficult to optimize on a feed. --Mark > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: qemuarm: should it really have TUNE_ARCH armv5te? 2012-09-13 16:47 ` Mark Hatle @ 2012-09-13 17:02 ` Phil Blundell 0 siblings, 0 replies; 28+ messages in thread From: Phil Blundell @ 2012-09-13 17:02 UTC (permalink / raw) To: openembedded-core On Thu, 2012-09-13 at 11:47 -0500, Mark Hatle wrote: > ARM seems to be the one exception, where you have three levels.. ABI > (EABI/hf-EABI), processor family (armv4, armv5, armv7, cortext....), and then > CPU optimization. This seems to cause additional confusion, as the CPU > optimizations are not being captured in the current package ARCH, which makes it > difficult to optimize on a feed. I guess that by "processor family" you mean ISA. (I'm not aware of an ARM ISA variant named "cortext", though I haven't really been keeping up with the latest developments there so I could imagine that one might exist.) Anyway, the basic three-way scenario (ISA, ABI, optimisation) that you describe above isn't in any sense unique to ARM; the concept of per-cpu-model optimisation/tuning applies equally to other architectures (x86 for example) as well. It's probably less of an issue for MIPS but I suspect that's more a reflection of gcc's weaker optimisation capabilities on that architecture rather than a homogeous CPU population. I don't know PowerPC well enough to make any comment about that. There's no particular reason that the per-cpu tuning couldn't be captured in PACKAGE_ARCH if one wanted to do it. But the decision about how to structure a binary feed is clearly one for the DISTRO and the question of how to map that into PACKAGE_ARCH is, equally clearly, one that the distro ought to be solving. Since oe-core itself doesn't build any feeds, I don't think there's any reason for it to make heroic efforts to sort out the package architectures that would go into them. p. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2012-09-22 12:00 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-11 13:01 qemuarm: should it really have TUNE_ARCH armv5te? Martin Jansa 2012-09-11 13:48 ` Martin Jansa 2012-09-11 15:51 ` ARM-tuning -- was " Mark Hatle 2012-09-11 15:59 ` Martin Jansa 2012-09-11 16:09 ` Mark Hatle 2012-09-11 16:22 ` Martin Jansa 2012-09-11 16:13 ` Koen Kooi 2012-09-11 18:40 ` Khem Raj 2012-09-11 18:53 ` Phil Blundell 2012-09-11 19:58 ` Khem Raj 2012-09-11 16:46 ` Phil Blundell 2012-09-11 16:53 ` Martin Jansa 2012-09-11 17:14 ` Phil Blundell 2012-09-11 17:21 ` Martin Jansa 2012-09-11 17:35 ` Martin Jansa 2012-09-11 17:37 ` Phil Blundell 2012-09-11 17:43 ` Martin Jansa 2012-09-11 18:00 ` Mark Hatle 2012-09-12 14:33 ` Richard Purdie 2012-09-13 6:20 ` Martin Jansa 2012-09-13 10:42 ` Richard Purdie 2012-09-13 12:14 ` Martin Jansa 2012-09-13 12:58 ` Richard Purdie 2012-09-15 7:01 ` Martin Jansa 2012-09-21 15:52 ` Martin Jansa 2012-09-22 11:48 ` Richard Purdie 2012-09-13 16:47 ` Mark Hatle 2012-09-13 17:02 ` Phil Blundell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox