kumquat-buildroot/arch/Config.in.arm

917 lines
27 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
# For some cores, the FPU is optional
config BR2_ARM_CPU_MAYBE_HAS_FPU
bool
config BR2_ARM_CPU_HAS_FPU
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
select BR2_ARM_CPU_MAYBE_HAS_FPU
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_CPU_HAS_VFPV2
bool
select BR2_ARM_CPU_HAS_FPU
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, 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
# FPv4 is always optional
config BR2_ARM_CPU_MAYBE_HAS_FPV4
bool
select BR2_ARM_CPU_MAYBE_HAS_FPU
config BR2_ARM_CPU_HAS_FPV4
bool
select BR2_ARM_CPU_HAS_FPU
# FPv5 is always optional
config BR2_ARM_CPU_MAYBE_HAS_FPV5
bool
select BR2_ARM_CPU_MAYBE_HAS_FPV4
config BR2_ARM_CPU_HAS_FPV5
bool
select BR2_ARM_CPU_HAS_FPV4
config BR2_ARM_CPU_HAS_FP_ARMV8
bool
select BR2_ARM_CPU_HAS_VFPV4
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
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
config BR2_ARM_CPU_ARMV5
bool
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
config BR2_ARM_CPU_ARMV6
bool
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
config BR2_ARM_CPU_ARMV7A
bool
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
config BR2_ARM_CPU_ARMV7M
bool
config BR2_ARM_CPU_ARMV8A
bool
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
choice
prompt "Target Architecture Variant"
default BR2_cortex_a53 if BR2_ARCH_IS_64
default BR2_arm926t
help
Specific CPU variant to use
if !BR2_ARCH_IS_64
comment "armv4 cores"
config BR2_arm920t
bool "arm920t"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV4
config BR2_arm922t
bool "arm922t"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV4
config BR2_fa526
bool "fa526/626"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_ARMV4
config BR2_strongarm
bool "strongarm sa110/sa1100"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_ARMV4
comment "armv5 cores"
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
config BR2_xscale
bool "xscale"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV5
comment "armv6 cores"
config BR2_arm1136j_s
bool "arm1136j-s"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
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
config BR2_arm1176jz_s
bool "arm1176jz-s"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
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
config BR2_arm11mpcore
bool "mpcore"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_MAYBE_HAS_VFPV2
select BR2_ARM_CPU_HAS_THUMB
select BR2_ARM_CPU_ARMV6
comment "armv7a cores"
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
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
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
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
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
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
config BR2_cortex_a15_a7
bool "cortex-A15/A7 big.LITTLE"
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_NEEDS_GCC_AT_LEAST_4_9
config BR2_cortex_a17
bool "cortex-A17"
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_NEEDS_GCC_AT_LEAST_5
config BR2_cortex_a17_a7
bool "cortex-A17/A7 big.LITTLE"
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_NEEDS_GCC_AT_LEAST_5
config BR2_pj4
bool "pj4"
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_VFPV3
select BR2_ARM_CPU_ARMV7A
# Cortex-M cores are only supported for little endian configurations
if BR2_arm
comment "armv7m cores"
config BR2_cortex_m3
bool "cortex-M3"
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_ARMV7M
config BR2_cortex_m4
bool "cortex-M4"
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_MAYBE_HAS_FPV4
select BR2_ARM_CPU_ARMV7M
config BR2_cortex_m7
bool "cortex-M7"
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_MAYBE_HAS_FPV5
select BR2_ARM_CPU_ARMV7M
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
endif # BR2_arm
endif # !BR2_ARCH_IS_64
comment "armv8 cores"
config BR2_cortex_a32
bool "cortex-A32"
depends on !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_ARM
select BR2_ARM_CPU_HAS_NEON
select BR2_ARM_CPU_HAS_THUMB2
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
config BR2_cortex_a35
bool "cortex-A35"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
config BR2_cortex_a53
bool "cortex-A53"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
config BR2_cortex_a57
bool "cortex-A57"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
config BR2_cortex_a57_a53
bool "cortex-A57/A53 big.LITTLE"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
config BR2_cortex_a72
bool "cortex-A72"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
config BR2_cortex_a72_a53
bool "cortex-A72/A53 big.LITTLE"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
config BR2_cortex_a73
bool "cortex-A73"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_cortex_a73_a35
bool "cortex-A73/A35 big.LITTLE"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_cortex_a73_a53
bool "cortex-A73/A53 big.LITTLE"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_emag
bool "emag"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
config BR2_exynos_m1
bool "exynos-m1"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
config BR2_falkor
bool "falkor"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_phecda
bool "phecda"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
config BR2_qdf24xx
bool "qdf24xx"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
config BR2_thunderx
bool "thunderx (aka octeontx)"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
config BR2_thunderxt81
bool "thunderxt81 (aka octeontx81)"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_thunderxt83
bool "thunderxt83 (aka octeontx83)"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_thunderxt88
bool "thunderxt88"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_thunderxt88p1
bool "thunderxt88p1"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_xgene1
bool "xgene1"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
comment "armv8.1a cores"
config BR2_thunderx2t99
bool "thunderx2t99"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_thunderx2t99p1
bool "thunderx2t99p1"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
config BR2_vulcan
bool "vulcan"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
comment "armv8.2a cores"
config BR2_cortex_a55
bool "cortex-A55"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
config BR2_cortex_a75
bool "cortex-A75"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
config BR2_cortex_a75_a55
bool "cortex-A75/A55 big.LITTLE"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
config BR2_cortex_a76
bool "cortex-A76"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
config BR2_cortex_a76_a55
bool "cortex-A76/A55 big.LITTLE"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
config BR2_neoverse_n1
bool "neoverse-N1 (aka ares)"
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
config BR2_tsv110
bool "tsv110"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
comment "armv8.4a cores"
config BR2_saphira
bool "saphira"
depends on BR2_ARCH_IS_64
select BR2_ARM_CPU_HAS_FP_ARMV8
select BR2_ARM_CPU_ARMV8A
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
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.
config BR2_ARM_ENABLE_VFP
bool "Enable VFP extension support"
depends on BR2_ARM_CPU_MAYBE_HAS_FPU
select BR2_ARM_CPU_HAS_FPV5 if BR2_ARM_CPU_MAYBE_HAS_FPV5
select BR2_ARM_CPU_HAS_FPV4 if BR2_ARM_CPU_MAYBE_HAS_FPV4
select BR2_ARM_CPU_HAS_VFPV4 if BR2_ARM_CPU_MAYBE_HAS_VFPV4
select BR2_ARM_CPU_HAS_VFPV3 if BR2_ARM_CPU_MAYBE_HAS_VFPV3
select BR2_ARM_CPU_HAS_VFPV2 if BR2_ARM_CPU_MAYBE_HAS_VFPV2
help
For some CPU cores, the VFP extension is optional. Select
this option if you are certain your particular
implementation has VFP support and you want to use it.
choice
prompt "Target ABI"
default BR2_ARM_EABIHF if BR2_ARM_CPU_HAS_FPU
default BR2_ARM_EABI
depends on BR2_arm || BR2_armeb
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_HAS_FPU
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
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"
default BR2_ARM_FPU_FP_ARMV8 if BR2_ARM_CPU_HAS_FP_ARMV8
default BR2_ARM_FPU_FPV5D16 if BR2_ARM_CPU_HAS_FPV5
default BR2_ARM_FPU_FPV4D16 if BR2_ARM_CPU_HAS_FPV4
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
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_FPU
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_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
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
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
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
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
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
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
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
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
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
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
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
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.
config BR2_ARM_FPU_FPV4D16
bool "FPv4-D16"
depends on BR2_ARM_CPU_HAS_FPV4
help
This option allows to use the FPv4-SP (single precision)
floating point unit, as available in some ARMv7m processors
(Cortex-M4).
config BR2_ARM_FPU_FPV5D16
bool "FPv5-D16"
depends on BR2_ARM_CPU_HAS_FPV5
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
help
This option allows to use the FPv5-SP (single precision)
floating point unit, as available in some ARMv7m processors
(Cortex-M7).
Note that if you want binary code that works on the earlier
Cortex-M4, you should instead select FPv4-D16.
config BR2_ARM_FPU_FPV5DPD16
bool "FPv5-DP-D16"
depends on BR2_ARM_CPU_HAS_FPV5
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
help
This option allows to use the FPv5-DP (double precision)
floating point unit, as available in some ARMv7m processors
(Cortex-M7).
Note that if you want binary code that works on the earlier
Cortex-M4, you should instead select FPv4-D16.
config BR2_ARM_FPU_FP_ARMV8
bool "FP-ARMv8"
depends on BR2_ARM_CPU_HAS_FP_ARMV8
help
This option allows to use the ARMv8 floating point unit.
config BR2_ARM_FPU_NEON_FP_ARMV8
bool "NEON/FP-ARMv8"
depends on BR2_ARM_CPU_HAS_FP_ARMV8
depends on BR2_ARM_CPU_HAS_NEON
help
This option allows to use both the ARMv8 floating point unit
and the NEON SIMD unit for floating point operations.
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
endchoice
choice
prompt "ARM instruction set"
depends on BR2_arm || BR2_armeb
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
# Thumb-1 and VFP are not compatible
depends on BR2_ARM_SOFT_FLOAT
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.
comment "Thumb1 is not compatible with VFP"
depends on BR2_ARM_CPU_HAS_THUMB
depends on !BR2_ARM_SOFT_FLOAT
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
arch: add support for configurable page size on ARM64 This commit is based on earlier work from Łukasz Stelmach <l.stelmach@samsung.com> to add support for different page sizes on ARM64. In his initial submission, Łukasz took an approach similar to this one, i.e make it ARM64-specific. Following the feedback on the mailing list, his second version [1] tried to generalize the logic to configure the page size between architectures. But the general consensus during the review process was that there wasn't much to generalize in the end. So, this new iteration is back to a simpler approach: * We have new options in Config.in.arm to configure the page size. Only 4 KB and 64 KB are supported, because our testing in Qemu and real hardware has not allowed to get a successful setup for 16 KB pages. We can always re-add support for 16 KB later if that is resolved. * The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is moved from the ARC-specific file to arch/arch.mk, and extended to cover ARM64. * The appropriate logic in uclibc.mk and linux.mk is added to tweak the relevant configuration options. * A test case is added in the runtime test infrastructure to test building and booting under Qemu a 64 KB configuration, with all 3 C libraries. For the regular configuration of 4 KB pages, this commit makes one functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in the compiler flags of the wrapper. [1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
choice
prompt "MMU Page Size"
default BR2_ARM64_PAGE_SIZE_4K
depends on BR2_aarch64 || BR2_aarch64_be
help
The default is 4KB, and you should probably keep this unless
you know what you are doing. In particular, the kernel
configuration must match this choice. If your kernel is
built by Buildroot, the kernel configuration is
automatically adjusted, but not if you built your kernel
outside of Buildroot.
config BR2_ARM64_PAGE_SIZE_4K
bool "4KB"
config BR2_ARM64_PAGE_SIZE_16K
bool "16KB"
arch: add support for configurable page size on ARM64 This commit is based on earlier work from Łukasz Stelmach <l.stelmach@samsung.com> to add support for different page sizes on ARM64. In his initial submission, Łukasz took an approach similar to this one, i.e make it ARM64-specific. Following the feedback on the mailing list, his second version [1] tried to generalize the logic to configure the page size between architectures. But the general consensus during the review process was that there wasn't much to generalize in the end. So, this new iteration is back to a simpler approach: * We have new options in Config.in.arm to configure the page size. Only 4 KB and 64 KB are supported, because our testing in Qemu and real hardware has not allowed to get a successful setup for 16 KB pages. We can always re-add support for 16 KB later if that is resolved. * The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is moved from the ARC-specific file to arch/arch.mk, and extended to cover ARM64. * The appropriate logic in uclibc.mk and linux.mk is added to tweak the relevant configuration options. * A test case is added in the runtime test infrastructure to test building and booting under Qemu a 64 KB configuration, with all 3 C libraries. For the regular configuration of 4 KB pages, this commit makes one functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in the compiler flags of the wrapper. [1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
config BR2_ARM64_PAGE_SIZE_64K
bool "64KB"
endchoice
config BR2_ARM64_PAGE_SIZE
string
default "4K" if BR2_ARM64_PAGE_SIZE_4K
default "16K" if BR2_ARM64_PAGE_SIZE_16K
arch: add support for configurable page size on ARM64 This commit is based on earlier work from Łukasz Stelmach <l.stelmach@samsung.com> to add support for different page sizes on ARM64. In his initial submission, Łukasz took an approach similar to this one, i.e make it ARM64-specific. Following the feedback on the mailing list, his second version [1] tried to generalize the logic to configure the page size between architectures. But the general consensus during the review process was that there wasn't much to generalize in the end. So, this new iteration is back to a simpler approach: * We have new options in Config.in.arm to configure the page size. Only 4 KB and 64 KB are supported, because our testing in Qemu and real hardware has not allowed to get a successful setup for 16 KB pages. We can always re-add support for 16 KB later if that is resolved. * The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is moved from the ARC-specific file to arch/arch.mk, and extended to cover ARM64. * The appropriate logic in uclibc.mk and linux.mk is added to tweak the relevant configuration options. * A test case is added in the runtime test infrastructure to test building and booting under Qemu a 64 KB configuration, with all 3 C libraries. For the regular configuration of 4 KB pages, this commit makes one functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in the compiler flags of the wrapper. [1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
default "64K" if BR2_ARM64_PAGE_SIZE_64K
config BR2_ARCH
default "arm" if BR2_arm
default "armeb" if BR2_armeb
default "aarch64" if BR2_aarch64
default "aarch64_be" if BR2_aarch64_be
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
config BR2_NORMALIZED_ARCH
default "arm" if BR2_arm || BR2_armeb
default "arm64" if BR2_aarch64 || BR2_aarch64_be
config BR2_ENDIAN
default "LITTLE" if (BR2_arm || BR2_aarch64)
default "BIG" if (BR2_armeb || BR2_aarch64_be)
config BR2_GCC_TARGET_CPU
# armv4
default "arm920t" if BR2_arm920t
default "arm922t" if BR2_arm922t
default "fa526" if BR2_fa526
default "strongarm" if BR2_strongarm
# armv5
default "arm926ej-s" if BR2_arm926t
default "xscale" if BR2_xscale
# armv6
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 "mpcore" if BR2_arm11mpcore && BR2_ARM_CPU_HAS_VFPV2
default "mpcorenovfp" if BR2_arm11mpcore
# armv7a
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 "cortex-a15.cortex-a7" if BR2_cortex_a15_a7
default "cortex-a17" if BR2_cortex_a17
default "cortex-a17.cortex-a7" if BR2_cortex_a17_a7
default "marvell-pj4" if BR2_pj4
# armv7m
default "cortex-m3" if BR2_cortex_m3
default "cortex-m4" if BR2_cortex_m4
default "cortex-m7" if BR2_cortex_m7
# armv8a
default "cortex-a32" if BR2_cortex_a32
default "cortex-a35" if BR2_cortex_a35
default "cortex-a53" if BR2_cortex_a53
default "cortex-a57" if BR2_cortex_a57
default "cortex-a57.cortex-a53" if BR2_cortex_a57_a53
default "cortex-a72" if BR2_cortex_a72
default "cortex-a72.cortex-a53" if BR2_cortex_a72_a53
default "cortex-a73" if BR2_cortex_a73
default "cortex-a73.cortex-a35" if BR2_cortex_a73_a35
default "cortex-a73.cortex-a53" if BR2_cortex_a73_a53
default "emag" if BR2_emag
default "exynos-m1" if BR2_exynos_m1
default "falkor" if BR2_falkor
default "phecda" if BR2_phecda
default "qdf24xx" if BR2_qdf24xx
default "thunderx" if BR2_thunderx && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "octeontx" if BR2_thunderx && BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "thunderxt81" if BR2_thunderxt81 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "octeontx81" if BR2_thunderxt81 && BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "thunderxt83" if BR2_thunderxt83 && !BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "octeontx83" if BR2_thunderxt83 && BR2_TOOLCHAIN_GCC_AT_LEAST_9
default "thunderxt88" if BR2_thunderxt88
default "thunderxt88p1" if BR2_thunderxt88p1
default "xgene1" if BR2_xgene1
# armv8.1a
default "thunderx2t99" if BR2_thunderx2t99
default "thunderx2t99p1" if BR2_thunderx2t99p1
default "vulcan" if BR2_vulcan
# armv8.2a
default "cortex-a55" if BR2_cortex_a55
default "cortex-a75" if BR2_cortex_a75
default "cortex-a75.cortex-a55" if BR2_cortex_a75_a55
default "cortex-a76" if BR2_cortex_a76
default "cortex-a76.cortex-a55" if BR2_cortex_a76_a55
default "neoverse-n1" if BR2_neoverse_n1
default "tsv110" if BR2_tsv110
# armv8.4a
default "saphira" if BR2_saphira
config BR2_GCC_TARGET_ABI
default "aapcs-linux" if BR2_arm || BR2_armeb
default "lp64" if BR2_aarch64 || BR2_aarch64_be
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
default "fpv4-sp-d16" if BR2_ARM_FPU_FPV4D16
default "fpv5-sp-d16" if BR2_ARM_FPU_FPV5D16
default "fpv5-d16" if BR2_ARM_FPU_FPV5DPD16
default "fp-armv8" if BR2_ARM_FPU_FP_ARMV8
default "neon-fp-armv8" if BR2_ARM_FPU_NEON_FP_ARMV8
depends on BR2_arm || BR2_armeb
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_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
config BR2_READELF_ARCH_NAME
default "ARM" if BR2_arm || BR2_armeb
default "AArch64" if BR2_aarch64 || BR2_aarch64_be
# vim: ft=kconfig
# -*- mode:kconfig; -*-