[OE-core] ARM-tuning -- was qemuarm: should it really have TUNE_ARCH armv5te?
Martin Jansa
martin.jansa at gmail.com
Tue Sep 11 16:22:31 UTC 2012
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 at gmail.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Openembedded-core mailing list
> >>> Openembedded-core at lists.openembedded.org
> >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >>>
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core at lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
>
--
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120911/e9681ba6/attachment-0002.sig>
More information about the Openembedded-core
mailing list