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.ja...@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.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
