Hi Khem, On Friday, March 21, 2014 6:06 PM, Khem Raj wrote: > On Fri, Mar 21, 2014 at 9:45 AM, Mark Hatle <[email protected]> wrote: >> On 3/21/14, 7:10 AM, Mats Kärrman wrote: >>> >>> Hi, >>> >>> On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote: >>>> >>>> My "home made" hard float tune for PowerPC looks like this: >>>> >>>> ------------------------------------------------------------------ >>>> # Tune for the e300c3 core >>>> require conf/machine/include/tune-ppce300c3.inc >>>> >>>> # Use hardware floating point >>>> AVAILTUNES += "ppce300c3hf" >>>> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3" >>>> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf" >>>> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf = >>>> "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf" >>>> DEFAULTTUNE = "ppce300c3hf" >>>> ------------------------------------------------------------------ >>>> >>> >>> I found the reason for the error (deviance) in the sqrt function. glibc >>> has >>> special code for PowerPC 603e core (e300 is an optimized variant of 603e). >>> By adding the following line to the tuning I now get the same result as >>> for all other environments that I've tried: >>> >>> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", >>> "-with-cpu=603e", "", d)}" >>> >>> Does anyone know about the reason for having soft-float as the default and >>> only available alternative for e300c2/3 tunings? >> >> >> My guess is because e300 e300c2 were both soft-float designs. And e300c3 is >> the first hard float design. >> >> The e300c3 should inherit and use the 603e directly. This includes >> definiting the TUNE_FEATURES that the 603e does. If it doesn't do that, I'd >> suggest it's a mistake. >> >> The default 603e tune should include: >> >> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e", >> "-with-cpu=603e", "", d)}" >> >> or similar already -- and should already be hard float enabled. (ppc603e >> soft-float should be the alternative -- as it is significantly rarer and the >> deviation.) > > > alternatively we should define fpu Iplies in glibc for e300c3, > >> >> >>> Would it be worthwhile to send a patch to add the hf tuning to OE-core? >> >> >> As the e300c3 should be hard float, we shouldn't have the 'hf' designation. >> Otherwise, we should ensure the e300c3 tune is correctly configured. > > may be for now controlling it in tune file is a quicker fix. >
Adding "-with-cpu=603e" to GLIBC_EXTRA_OECONF proved to be problematic as it leads to contradictive --mcpu= args to gcc, both "e300c3" and "603e". I solved that by using "-with-cpu=e300c3" and by adding a patch to eglibc: ------------------------------------------------------------------------------ --- libc.orig/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies +++ libc/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies @@ -0,0 +1,2 @@ +# e300c3 is a variant of 603e so use the same optimizations for sqrt +powerpc/powerpc32/603e/fpu ------------------------------------------------------------------------------ Does this seem correct to you? Initial tests shows that at least the sqrt test now works. The reason I'm holding back on patches to the tune file is that I still have trouble with time related syscalls, see [1]. >> >>> In that case what tests should be performed before that and what (related) >>> tests are performed by the OE auto-builder? BR // Mats [1] http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091011.html -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
