kumquat-buildroot/arch/Config.in.arm

437 lines
13 KiB
Plaintext
Raw Normal View History

# arm cpu features
config BR2_ARM_CPU_HAS_NEON
bool
# for some cores, NEON support is optional
config BR2_ARM_CPU_MAYBE_HAS_NEON
bool
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
# for some cores, VFPv2 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV2
bool
config BR2_ARM_CPU_HAS_VFPV2
bool
# for some cores, VFPv3 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV3
bool
select BR2_ARM_CPU_MAYBE_HAS_VFPV2
config BR2_ARM_CPU_HAS_VFPV3
bool
select BR2_ARM_CPU_HAS_VFPV2
# for some cores, VFPv4 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV4
bool
select BR2_ARM_CPU_MAYBE_HAS_VFPV3
config BR2_ARM_CPU_HAS_VFPV4
bool
select BR2_ARM_CPU_HAS_VFPV3
config BR2_ARM_CPU_HAS_ARM
bool
config BR2_ARM_CPU_HAS_THUMB
bool
config BR2_ARM_CPU_HAS_THUMB2
bool
config BR2_ARM_CPU_ARMV4
bool
config BR2_ARM_CPU_ARMV5
bool
config BR2_ARM_CPU_ARMV6
bool
config BR2_ARM_CPU_ARMV7A
bool
choice
prompt "Target Architecture Variant"
depends on BR2_arm || BR2_armeb
default BR2_arm926t
help
Specific CPU variant to use
config BR2_arm920t
bool "arm920t"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV4
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm922t
bool "arm922t"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV4
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm926t
bool "arm926t"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_MAYBE_HAS_VFPV2
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV5
select BR2_ARCH_HAS_MMU_OPTIONAL
arch/arm: do not distinguish revisions of ARM1136JF-S In commit 88cf3bb91792c9c04586e14f293d89a6e0c13e1d ("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Benoît Thébaudeau added separate options for the revision 0 and revision 1 of the ARM1136JF-S processor, so that different -march values could be used (armv6j for revision 0, armv6k for revision 1). However, this is preventing the removal of the BR2_GCC_TARGET_ARCH option, which we need to do to give only the CPU type to gcc, and let it decide the architecture variant that matches. This is because this story of revision 0 vs. revision 1 is the only case where -mcpu doesn't fully define the CPU. Moreover, a quick test with gcc shows that -march=armv6j -mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with -march=armv6k switch". In addition, gcc 5 will apparently no longer allow to pass all of --with-arch, --with-cpu and --with-tune, so we will anyway have to rely only on one of them. As a consequence, this commit basically reverts 88cf3bb91792c9c04586e14f293d89a6e0c13e1d and provides only one option for ARM1136JF-S. If the two revisions are really different, then they should be supported in upstream gcc with different -mcpu values. Note that the removal of the two options should not break existing full .config, since the hidden option BR2_arm1136jf_s becomes again a visible option to select the CPU. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-21 22:27:08 +02:00
config BR2_arm1136jf_s
bool "arm1136jf-s"
select BR2_ARM_CPU_HAS_ARM
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV2
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1176jz_s
bool "arm1176jz-s"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1176jzf_s
bool "arm1176jzf-s"
select BR2_ARM_CPU_HAS_ARM
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV2
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a5
bool "cortex-A5"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_MAYBE_HAS_NEON
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_MAYBE_HAS_VFPV4
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a7
bool "cortex-A7"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_NEON
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV4
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a8
bool "cortex-A8"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_NEON
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV3
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a9
bool "cortex-A9"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_MAYBE_HAS_NEON
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_MAYBE_HAS_VFPV3
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a12
bool "cortex-A12"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_NEON
select BR2_ARM_CPU_HAS_VFPV4
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a15
bool "cortex-A15"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_NEON
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV4
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_fa526
bool "fa526/626"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_ARMV4
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_pj4
bool "pj4"
select BR2_ARM_CPU_HAS_ARM
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
select BR2_ARM_CPU_HAS_VFPV3
select BR2_ARM_CPU_ARMV7A
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_strongarm
bool "strongarm sa110/sa1100"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_ARMV4
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_xscale
bool "xscale"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV5
select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_iwmmxt
bool "iwmmxt"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_ARMV5
select BR2_ARCH_HAS_MMU_OPTIONAL
endchoice
choice
prompt "Target ABI"
depends on BR2_arm || BR2_armeb
default BR2_ARM_EABI
help
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
Application Binary Interface to use. The Application Binary
Interface describes the calling conventions (how arguments
are passed to functions, how the return value is passed, how
system calls are made, etc.).
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
config BR2_ARM_EABI
bool "EABI"
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
help
The EABI is currently the standard ARM ABI, which is used in
most projects. It supports both the 'soft' floating point
model (in which floating point instructions are emulated in
software) and the 'softfp' floating point model (in which
floating point instructions are executed using an hardware
floating point unit, but floating point arguments to
functions are passed in integer registers).
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
The 'softfp' floating point model is link-compatible with
the 'soft' floating point model, i.e you can link a library
built 'soft' with some other code built 'softfp'.
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
However, passing the floating point arguments in integer
registers is a bit inefficient, so if your ARM processor has
a floating point unit, and you don't have pre-compiled
'soft' or 'softfp' code, using the EABIhf ABI will provide
better floating point performances.
If your processor does not have a floating point unit, then
you must use this ABI.
config BR2_ARM_EABIHF
bool "EABIhf"
depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2
help
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
The EABIhf is an extension of EABI which supports the 'hard'
floating point model. This model uses the floating point
unit to execute floating point instructions, and passes
floating point arguments in floating point registers.
It is more efficient than EABI for floating point related
workload. However, it does not allow to link against code
that has been pre-built for the 'soft' or 'softfp' floating
point models.
If your processor has a floating point unit, and you don't
depend on existing pre-compiled code, this option is most
likely the best choice.
endchoice
config BR2_ARM_ENABLE_NEON
bool "Enable NEON SIMD extension support"
depends on BR2_ARM_CPU_MAYBE_HAS_NEON
select BR2_ARM_CPU_HAS_NEON
help
For some CPU cores, the NEON SIMD extension is optional.
Select this option if you are certain your particular
implementation has NEON support and you want to use it.
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
choice
prompt "Floating point strategy"
depends on BR2_ARM_EABI || BR2_ARM_EABIHF
default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4
default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3
default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2
default BR2_ARM_SOFT_FLOAT if !BR2_ARM_CPU_HAS_VFPV2
config BR2_ARM_SOFT_FLOAT
bool "Soft float"
depends on BR2_ARM_EABI
select BR2_SOFT_FLOAT
help
This option allows to use software emulated floating
point. It should be used for ARM cores that do not include a
Vector Floating Point unit, such as ARMv5 cores (ARM926 for
example) or certain ARMv6 cores.
config BR2_ARM_FPU_VFPV2
bool "VFPv2"
depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_MAYBE_HAS_VFPV2
help
This option allows to use the VFPv2 floating point unit, as
available in some ARMv5 processors (ARM926EJ-S) and some
ARMv6 processors (ARM1136JF-S, ARM1176JZF-S and ARM11
MPCore).
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
Note that this option is also safe to use for newer cores
such as Cortex-A, because the VFPv3 and VFPv4 units are
backward compatible with VFPv2.
config BR2_ARM_FPU_VFPV3
bool "VFPv3"
depends on BR2_ARM_CPU_HAS_VFPV3 || BR2_ARM_CPU_MAYBE_HAS_VFPV3
help
This option allows to use the VFPv3 floating point unit, as
available in some ARMv7 processors (Cortex-A{8, 9}). This
option requires a VFPv3 unit that has 32 double-precision
registers, which is not necessarily the case in all SOCs
based on Cortex-A{8, 9}. If you're unsure, use VFPv3-D16
instead, which is guaranteed to work on all Cortex-A{8, 9}.
Note that this option is also safe to use for newer cores
that have a VFPv4 unit, because VFPv4 is backward compatible
with VFPv3. They must of course also have 32
double-precision registers.
config BR2_ARM_FPU_VFPV3D16
bool "VFPv3-D16"
depends on BR2_ARM_CPU_HAS_VFPV3 || BR2_ARM_CPU_MAYBE_HAS_VFPV3
help
This option allows to use the VFPv3 floating point unit, as
available in some ARMv7 processors (Cortex-A{8, 9}). This
option requires a VFPv3 unit that has 16 double-precision
registers, which is generally the case in all SOCs based on
Cortex-A{8, 9}, even though VFPv3 is technically optional on
Cortex-A9. This is the safest option for those cores.
Note that this option is also safe to use for newer cores
such that have a VFPv4 unit, because the VFPv4 is backward
compatible with VFPv3.
config BR2_ARM_FPU_VFPV4
bool "VFPv4"
depends on BR2_ARM_CPU_HAS_VFPV4 || BR2_ARM_CPU_MAYBE_HAS_VFPV4
help
This option allows to use the VFPv4 floating point unit, as
available in some ARMv7 processors (Cortex-A{5, 7, 12,
15}). This option requires a VFPv4 unit that has 32
double-precision registers, which is not necessarily the
case in all SOCs based on Cortex-A{5, 7, 12, 15}. If you're
unsure, you should probably use VFPv4-D16 instead.
Note that if you want binary code that works on all ARMv7
cores, including the earlier Cortex-A{8, 9}, you should
instead select VFPv3.
config BR2_ARM_FPU_VFPV4D16
bool "VFPv4-D16"
depends on BR2_ARM_CPU_HAS_VFPV4 || BR2_ARM_CPU_MAYBE_HAS_VFPV4
help
This option allows to use the VFPv4 floating point unit, as
available in some ARMv7 processors (Cortex-A{5, 7, 12,
15}). This option requires a VFPv4 unit that has 16
double-precision registers, which is always available on
Cortex-A12 and Cortex-A15, but optional on Cortex-A5 and
Cortex-A7.
Note that if you want binary code that works on all ARMv7
cores, including the earlier Cortex-A{8, 9}, you should
instead select VFPv3-D16.
config BR2_ARM_FPU_NEON
bool "NEON"
depends on BR2_ARM_CPU_HAS_NEON
help
This option allows to use the NEON SIMD unit, as available
in some ARMv7 processors, as a floating-point unit. It
should however be noted that using NEON for floating point
operations doesn't provide a complete compatibility with the
IEEE 754.
config BR2_ARM_FPU_NEON_VFPV4
bool "NEON/VFPv4"
depends on BR2_ARM_CPU_HAS_VFPV4 || BR2_ARM_CPU_MAYBE_HAS_VFPV4
depends on BR2_ARM_CPU_HAS_NEON
help
This option allows to use both the VFPv4 and the NEON SIMD
units for floating point operations. Note that some ARMv7
cores do not necessarily have VFPv4 and/or NEON support, for
example on Cortex-A5 and Cortex-A7, support for VFPv4 and
NEON is optional.
endchoice
choice
prompt "ARM instruction set"
config BR2_ARM_INSTRUCTIONS_ARM
bool "ARM"
depends on BR2_ARM_CPU_HAS_ARM
help
This option instructs the compiler to generate regular ARM
instructions, that are all 32 bits wide.
config BR2_ARM_INSTRUCTIONS_THUMB
bool "Thumb"
depends on BR2_ARM_CPU_HAS_THUMB
help
This option instructions the compiler to generate Thumb
instructions, which allows to mix 16 bits instructions and
32 bits instructions. This generally provides a much smaller
compiled binary size.
config BR2_ARM_INSTRUCTIONS_THUMB2
bool "Thumb2"
depends on BR2_ARM_CPU_HAS_THUMB2
help
This option instructions the compiler to generate Thumb2
instructions, which allows to mix 16 bits instructions and
32 bits instructions. This generally provides a much smaller
compiled binary size.
endchoice
config BR2_ARCH
default "arm" if BR2_arm
default "armeb" if BR2_armeb
config BR2_ENDIAN
default "LITTLE" if BR2_arm
default "BIG" if BR2_armeb
config BR2_ARCH_HAS_ATOMICS
default y
config BR2_GCC_TARGET_CPU
default "arm920t" if BR2_arm920t
default "arm922t" if BR2_arm922t
default "arm926ej-s" if BR2_arm926t
default "arm1136j-s" if BR2_arm1136j_s
default "arm1136jf-s" if BR2_arm1136jf_s
default "arm1176jz-s" if BR2_arm1176jz_s
default "arm1176jzf-s" if BR2_arm1176jzf_s
default "cortex-a5" if BR2_cortex_a5
default "cortex-a7" if BR2_cortex_a7
default "cortex-a8" if BR2_cortex_a8
default "cortex-a9" if BR2_cortex_a9
default "cortex-a12" if BR2_cortex_a12
default "cortex-a15" if BR2_cortex_a15
default "fa526" if BR2_fa526
default "marvell-pj4" if BR2_pj4
default "strongarm" if BR2_strongarm
default "xscale" if BR2_xscale
default "iwmmxt" if BR2_iwmmxt
config BR2_GCC_TARGET_ABI
default "aapcs-linux"
arch: improve ARM floating point support and add support for EABIhf This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:14 +02:00
config BR2_GCC_TARGET_FPU
default "vfp" if BR2_ARM_FPU_VFPV2
default "vfpv3" if BR2_ARM_FPU_VFPV3
default "vfpv3-d16" if BR2_ARM_FPU_VFPV3D16
default "vfpv4" if BR2_ARM_FPU_VFPV4
default "vfpv4-d16" if BR2_ARM_FPU_VFPV4D16
default "neon" if BR2_ARM_FPU_NEON
default "neon-vfpv4" if BR2_ARM_FPU_NEON_VFPV4
config BR2_GCC_TARGET_FLOAT_ABI
default "soft" if BR2_ARM_SOFT_FLOAT
default "softfp" if !BR2_ARM_SOFT_FLOAT && BR2_ARM_EABI
default "hard" if !BR2_ARM_SOFT_FLOAT && BR2_ARM_EABIHF
config BR2_GCC_TARGET_MODE
default "arm" if BR2_ARM_INSTRUCTIONS_ARM
default "thumb" if BR2_ARM_INSTRUCTIONS_THUMB || BR2_ARM_INSTRUCTIONS_THUMB2