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: [email protected]
--
Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
