[OE-core] Tune files and knobs to turn

[Darren Hart]

On 06/24/2011 04:54 AM, Koen Kooi wrote:
> Hi,
> 
> We discussed tune files a bit during last nights TSC meeting and Khem had
> expressed the need before, so I'd like to get this discussion started by using
> armv7a as an example.
> 
> For armv7a capable cores we have the following hardware features:
> 
> * armv7a instruction set
> * thumb1 instruction set
> * thumb2 instruction set
> * VFP coprocessor
> * optional NEON coprocessor
> 
> For the ABI we can choose the following:
> 
> * softtp without hw support (e.g. no VFP instructions emitted, slow)
> * softfp with hw support (e.g. VFP and/or NEON instructions emitted, fast)
> * hardfp, emits VFP and/or NEON instructions, slightly faster than softfp/hw,
>   incompatible with everything else
> 
> And the extra knobs:
> 
> * pure thumb1, no arm instructions (limited use)
> * thumb1/arm interworking
> * pure thumb2,  no arm instructions
> * thumb2 interworking (not sure if that's actually usefull, thumb2 has complete coverage)
> 
> In OE .dev we have the following vars:
> 
> TARGET_FPU: switches between hw float and sw float, no reflection in package arch
> ARM_FP_ABI: switches between softfp and hardfp, will create 'armv7a' or
>             'armv7a-hardfp' as package arch
> ARM_INSTRUCTION_SET: switches between arm and thumb1, no reflection in package arch
> THUMB_INTERWORK: turns on interworking, no reflection in package arch
> 
> (side note, oe-core/distroless and meta-yocto/poky don't turn set TARGET_FPU
>  for armv7a and will generate slow code, angstrom does turn it on)


oe-core tune-cortexa8.inc doesn't make use of these variables (unlike
meta-texasinstruments) and does make use of the neon coprocessor, but
still uses the softfp float-api:

TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -fno-tree-vectorize"

Seems like the oe-core tune files need to be synced up with vendor layers?

--
Darren


> 
> Khem and I would like to start building armv7a (and armv6) in pure thumb2 mode
> but we want to have the variables to turn those knobs make sense and be
> consistent. RP has expressed his desire to sort this all out before merging
> multilib. I'm sure x86/mips/ppc/etc have a similar need, so let's get this
> discussion started.
> 
> regards,
> 
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel