[Buildroot] [PATCH 3/8] arch: improve ARM floating point support and add support for EABIhf

Peter Korsgaard jacmet at uclibc.org
Sun Jul 7 20:44:08 UTC 2013


>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:

 Thomas> This commit introduces the support for the EABIhf ABI, next to the
 Thomas> existing support we have for EABI and OABI (even though OABI support
 Thomas> is deprecated). EABIhf allows to improve performance of floating point
 Thomas> workload by using floating point registers to transfer floating point
 Thomas> arguments when calling functions, instead of using integer registers
 Thomas> to do, as is done in the 'softfp' floating point model of EABI.

 Thomas> In addition to this, this commit introduces a list of options for the
 Thomas> floating point support:
 Thomas>  * Software floating point
 Thomas>  * VFP
 Thomas>  * VFPv3
 Thomas>  * VFPv3-D16
 Thomas>  * VFPv4
 Thomas>  * VFPv4-D16

 Thomas> and it introduces some logic to make sure the options are only visible
 Thomas> when it makes sense, depending on the ARM core being selected. This is
 Thomas> however made complicated by the fact that certain VFP capabilities are
 Thomas> mandatory on some cores, but optional on some other cores. The kconfig
 Thomas> logic tries to achieve the following goals:

 Thomas>  * Hide options that are definitely not possible.

 Thomas>  * Use safe default values (i.e for Cortex-A5 and A7, the presence of
 Thomas>    the VFPv4 unit is optional, so we default on software floating
 Thomas>    point on these cores)..

 Thomas>  * Show the available possibilities, even if some of them are not
 Thomas>    necessarily working on a particular core (again, for the Cortex-A5
 Thomas>    and A7 cores, there is no way of knowing whether the particular
 Thomas>    variant used by the user has VFPv4 or not, so we select software
 Thomas>    floating point by default, but still show VFP/VFPv3/VFPv4 options).

 Thomas> It is worth noting that this commit doesn't add support for all
 Thomas> possible -mfpu= values on ARM. We haven't added support for fpa, fpe2,
 Thomas> fpe3, maverick (those four are only used on very old ARM cores), for
 Thomas> vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16,
 Thomas> vfpv4-sp-d16. They can be added quite easily if needed thanks to the
 Thomas> new organization of the Config.in options.

 Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>


 Thomas>  config BR2_cortex_a15
 Thomas>  	bool "cortex-A15"
 Thomas>  	select BR2_ARM_CPU_HAS_NEON
 Thomas> +	select BR2_ARM_CPU_HAS_VFPV4
 Thomas>  config BR2_fa526
 Thomas>  	bool "fa526/626"
 Thomas>  config BR2_pj4
 Thomas>  	bool "pj4"
 Thomas> +	select BR2_ARM_CPU_HAS_VFPV3
 Thomas>  config BR2_strongarm
 Thomas>  	bool "strongarm sa110/sa1100"
 Thomas>  config BR2_xscale
 Thomas> @@ -67,34 +101,67 @@ config BR2_arm1136jf_s
 Thomas>  choice
 Thomas>  	prompt "Target ABI"
 Thomas>  	depends on BR2_arm || BR2_armeb
 Thomas> -	depends on BR2_DEPRECATED
 Thomas>  	default BR2_ARM_EABI

Looks good. You could argue that we should do:

      default BR2_ARM_EABIHF

instead (E.G. default to eabihf if available, otherwise fall back to
eabi), but with all the optional vfp units it's perhaps better to play
it safe..

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list