On Mar 27, 2014 8:16 AM, "Mats Kärrman" <[email protected]> wrote: > > 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
yes thats ok > ------------------------------------------------------------------------------ > 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
