From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1T9ll4-00057K-A1 for openembedded-core@lists.openembedded.org; Fri, 07 Sep 2012 01:45:14 +0200 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q86NWmQI023516; Fri, 7 Sep 2012 00:32:48 +0100 Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22787-07; Fri, 7 Sep 2012 00:32:43 +0100 (BST) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q86NWesC023510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 00:32:41 +0100 Message-ID: <1346974360.7493.38.camel@ted> From: Richard Purdie To: Mark Hatle Date: Fri, 07 Sep 2012 00:32:40 +0100 In-Reply-To: <50492CAF.3010203@windriver.com> References: <1346969961.7493.24.camel@ted> <504921BD.4040004@windriver.com> <5049253B.4090402@windriver.com> <1346972362.7493.32.camel@ted> <50492CAF.3010203@windriver.com> X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at rpsys.net Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH 1/1] conf/tune: add tune-ppce300c3 X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:45:14 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-09-06 at 18:07 -0500, Mark Hatle wrote: > On 9/6/12 5:59 PM, Richard Purdie wrote: > > On Thu, 2012-09-06 at 17:35 -0500, Mark Hatle wrote: > >> On 9/6/12 5:20 PM, Bruce Ashfield wrote: > >>> On 12-09-06 6:19 PM, Richard Purdie wrote: > >>>> On Thu, 2012-09-06 at 14:43 -0400, Bruce Ashfield wrote: > >>>>> It has been pointed out several times that the yocto mpc8315e-rdb > >>>>> reference was using the wrong tuning (603e), since it is actually > >>>>> a e300c3 board. > >>>>> > >>>>> This commit creates a e300c3 tune file based on the e300c2 variant > >>>>> already in oe-core. > >>>>> > >>>>> This commit also inhibits altivec in flac when this new tuning is > >>>>> enabled. It was also noticed that the existing tune based overrides > >>>>> in the flac package would not be triggered since DEFAULTTUNE is not > >>>>> in the overrides list. To avoid doing per-board disabling of altivec > >>>>> DEFAULTTUNE is added to the local package OVERRIDES and then used > >>>>> to disable altivec. > >>>>> > >>>>> [YOCTO #1192] > >>>>> > >>>>> Signed-off-by: Bruce Ashfield > >>>>> > >>>>> asdfkljds > >>>>> Signed-off-by: Bruce Ashfield > >>>>> --- > >>>>> meta/conf/machine/include/tune-ppce300c3.inc | 11 +++++++++++ > >>>>> meta/recipes-multimedia/flac/flac_1.2.1.bb | 5 +++++ > >>>>> 2 files changed, 16 insertions(+), 0 deletions(-) > >>>>> create mode 100644 meta/conf/machine/include/tune-ppce300c3.inc > >>>>> > >>>>> diff --git a/meta/conf/machine/include/tune-ppce300c3.inc b/meta/conf/machine/include/tune-ppce300c3.inc > >>>>> new file mode 100644 > >>>>> index 0000000..3f5ac26 > >>>>> --- /dev/null > >>>>> +++ b/meta/conf/machine/include/tune-ppce300c3.inc > >>>>> @@ -0,0 +1,11 @@ > >>>>> +DEFAULTTUNE ?= "ppce300c3" > >>>>> + > >>>>> +require conf/machine/include/powerpc/arch-powerpc.inc > >>>>> + > >>>>> +TUNEVALID[ppce300c3] = "Enable ppce300c3 specific processor optimizations" > >>>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", "-mcpu=e300c3", "", d)}" > >>>>> + > >>>>> +AVAILTUNES += "ppce300c3" > >>>>> +TUNE_FEATURES_tune-ppce300c3 = "m32 fpu-soft ppce300c3" > >>>>> +TUNE_PKGARCH_tune-ppce300c3 = "ppce300c3" > >>>>> +PACKAGE_EXTRA_ARCHS_tune-ppce300c3 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppce300c3" > >>>>> diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb b/meta/recipes-multimedia/flac/flac_1.2.1.bb > >>>>> index 3c5b73c..25db1c4 100644 > >>>>> --- a/meta/recipes-multimedia/flac/flac_1.2.1.bb > >>>>> +++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb > >>>>> @@ -36,9 +36,14 @@ EXTRA_OECONF = "--disable-oggtest --disable-id3libtest \ > >>>>> --without-xmms-exec-prefix \ > >>>>> --without-libiconv-prefix \ > >>>>> --without-id3lib" > >>>>> + > >>>>> +FLACOVERRIDE = ":${DEFAULTTUNE}" > >>>>> +OVERRIDES .= "${FLACOVERRIDE}" > >>>>> + > >>>>> EXTRA_OECONF_prepend_e500mc = "--disable-altivec " > >>>>> EXTRA_OECONF_prepend_e5500 = "--disable-altivec " > >>>>> EXTRA_OECONF_prepend_e5500-64b = "--disable-altivec " > >>>>> +EXTRA_OECONF_prepend_ppce300c3 = "--disable-altivec " > >>>>> > >>>> > >>>> This is getting ugly and is kind of unsafe. Perhaps the architecture > >>>> should be doing something like: > >>>> > >>>> MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", ":noaltivec", "" ,d)} > >>>> > >>>> or even in this recipe just do: > >>>> > >>>> EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", " --disable-altivec", "" ,d)} > >>> > >>> I definitely considered this route. I can do that for the new arch, and the > >>> old ones, but can't test the old ones at the moment. > >> > >> The problem is actually in the flac. This recipe sees powerpc as the machine > >> type, and immediately enabled altivec. By default altivec support is disabled > >> in OE-Core. > >> > >> Perhaps one way we could address this is add a tune flag that says if the tune > >> has altivec support or not.. then in the flac binary, disable it unless it's > >> enabled? > > > > I think having altivec in the tune_features would be ideal. I'd love to > > get this cleaned up too but I lack much knowledge about powerpc... > > My proposal then would be to accept Bruce's patch, with the understanding that > we need to add a tune flag of 'altivec' to the PowerPC tunings (where > appropriate) and then make the flac recipe respect that flag. > > Unfortunately I don't have the time to do that right now or I would. Would an > enhancement bug in the Yocto Project bugzilla be enough to be sure the work is done? Please send something machine specific. Adding DEFAULTTUNE is a bad idea for several reasons, not least it might not be the selected tune. I took Matthew's original patch on the understanding this gets fixed and it hasn't happened but please do file the request. Cheers, Richard