[yocto] Tuning for a machine based on Cortex-A9

[Lennart Sorensen]

On Wed, Aug 24, 2016 at 07:51:40AM +0000, Ottavio Campana wrote:
> Hello,
> 
> I am trying to port a third-party BSP based on buildroot to yocto, but I am not able to tune the compiler to extactly match the original one.
> 
> Particularly, if I run readelf on a binary compiled with the gcc that is used by buildroot I get this output
> 
> ottavio at ottavio:~$ readelf -A hello_world
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_Advanced_SIMD_arch: NEONv1
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio at ottavio:~$
> 
> I tried to replicate this by configuring a new machine, and my machine configuration looks like this
> 
> require ../../../meta/conf/machine/include/tune-cortexa9.inc
> 
> AVAILTUNES += "cortexa9t-vfpv3-neon"
> ARMPKGARCH_tune-cortexa9t-vfpv3-neon          = "cortexa9"
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon       = "${TUNE_FEATURES_tune-armv7at-vfpv3} neon cortexa9"
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-vfpv3} cortexa9-vfp cortexa9-vfpv3 cortexa9t2-vfp cortexa9t2-vfpv3 cortexa9-neon"
> 
> DEFAULTTUNE = "cortexa9t-vfpv3-neon"
> 
> If I run readelf on any compiled binary obtained with yocto, I get this result:
> 
> ottavio at ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$ readelf -A .libs/bzip2
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio at ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
> 
> I am quite close to get a similar binary, the missing part is the Tag_Advanced_SIMD_arch: NEONv1 .  I get exactly the same result if I use DEFAULTTUNE = "cortexa9t-vfpv3", thus it seems that the neon and cortexa9-neon options I tried to add are ignored.
> 
> At this point I have two questions
> 
> Question #1
> 
> How should I change ARMPKGARCH_tune-cortexa9t-vfpv3-neon , TUNE_FEATURES_tune-cortexa9t-vfpv3-neon and PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon to have exactly the same kind of elf?
> 
> Question # 2
> 
> Why the only options for neon in meta/conf/machine/include/tune-cortexa9.inc are offered for HF tunes?

Well it looks to me like the HF neon options imply vfp, while the vfp3
tunes imply not neon.  Since they share registers the performance may
in fact be better if they are not mixed.

Of course there exists A9's without neon, so one might want to build
for that.

The git commit that added the vfpv3 tunes says they are for 32 register
VFP on A9s.  Neon already implies 32 registers for the vfp.

As far as I can tell, you can set DEFAULTTUNE to cortexa9t-neon to get
softfp with neon support, or you can set it to cortexa9thf-neon to get
hardfp with neon support.

Certainly cortexa9t-vfpv3 should NOT do neon as far as I can tell.

Getting the output you had above with neon support in it, I believe
means doing DEFAULTTUNE=cortexa9thf-neon

There is no such option as cortexa9t-vfpv3-neon that I can find in the
files anywhere, so that wouldn't work.  No point trying to invent one
since neon implies vfpv3 already.

-- 
Len Sorensen