2012-12-14 06:20:48 +08:00
|
|
|
# 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
|
|
|
|
|
2018-02-26 04:18:14 +08:00
|
|
|
# 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 16:03:14 +08:00
|
|
|
# for some cores, VFPv2 is optional
|
|
|
|
config BR2_ARM_CPU_MAYBE_HAS_VFPV2
|
|
|
|
bool
|
2018-02-26 04:18:14 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
|
|
|
|
config BR2_ARM_CPU_HAS_VFPV2
|
|
|
|
bool
|
2018-02-26 04:18:14 +08:00
|
|
|
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 16:03:14 +08: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
|
|
|
|
|
2018-02-26 04:18:15 +08:00
|
|
|
# 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
|
|
|
|
|
2018-02-26 04:18:16 +08:00
|
|
|
# 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
|
|
|
|
|
2016-12-01 05:12:08 +08:00
|
|
|
config BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
bool
|
|
|
|
select BR2_ARM_CPU_HAS_VFPV4
|
|
|
|
|
2015-01-23 02:33:25 +08:00
|
|
|
config BR2_ARM_CPU_HAS_ARM
|
|
|
|
bool
|
|
|
|
|
2013-07-17 23:39:15 +08:00
|
|
|
config BR2_ARM_CPU_HAS_THUMB
|
|
|
|
bool
|
|
|
|
|
2013-07-16 16:03:22 +08:00
|
|
|
config BR2_ARM_CPU_HAS_THUMB2
|
|
|
|
bool
|
|
|
|
|
2014-10-22 04:26:48 +08:00
|
|
|
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-27 00:39:51 +08:00
|
|
|
select BR2_USE_MMU
|
2014-10-22 04:26:48 +08:00
|
|
|
|
|
|
|
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-27 00:39:51 +08:00
|
|
|
select BR2_USE_MMU
|
2014-10-22 04:26:48 +08:00
|
|
|
|
|
|
|
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-27 00:39:51 +08:00
|
|
|
select BR2_USE_MMU
|
2014-10-22 04:26:48 +08:00
|
|
|
|
|
|
|
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-27 00:39:51 +08:00
|
|
|
select BR2_USE_MMU
|
2014-10-22 04:26:48 +08:00
|
|
|
|
2016-03-19 05:08:03 +08:00
|
|
|
config BR2_ARM_CPU_ARMV7M
|
|
|
|
bool
|
2024-09-30 04:14:54 +08:00
|
|
|
select BR2_ARCH_HAS_FDPIC_SUPPORT
|
2016-03-19 05:08:03 +08:00
|
|
|
|
2017-09-03 21:17:43 +08:00
|
|
|
config BR2_ARM_CPU_ARMV8A
|
2016-12-01 05:12:06 +08:00
|
|
|
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-27 00:39:51 +08:00
|
|
|
select BR2_USE_MMU
|
2016-12-01 05:12:06 +08:00
|
|
|
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
choice
|
|
|
|
prompt "Target Architecture Variant"
|
2017-12-05 04:43:31 +08:00
|
|
|
default BR2_cortex_a53 if BR2_ARCH_IS_64
|
2013-04-04 15:29:45 +08:00
|
|
|
default BR2_arm926t
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
help
|
|
|
|
Specific CPU variant to use
|
|
|
|
|
2017-09-03 21:17:42 +08:00
|
|
|
if !BR2_ARCH_IS_64
|
2017-09-03 21:17:41 +08:00
|
|
|
comment "armv4 cores"
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_arm920t
|
|
|
|
bool "arm920t"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV4
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_arm922t
|
|
|
|
bool "arm922t"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV4
|
2017-09-03 21:17:41 +08:00
|
|
|
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"
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_arm926t
|
|
|
|
bool "arm926t"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2013-07-17 08:32:45 +08:00
|
|
|
select BR2_ARM_CPU_MAYBE_HAS_VFPV2
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV5
|
2017-09-03 21:17:41 +08:00
|
|
|
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"
|
2015-08-24 06:43:12 +08:00
|
|
|
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-22 04:27:08 +08:00
|
|
|
config BR2_arm1136jf_s
|
|
|
|
bool "arm1136jf-s"
|
2015-01-23 02:33:25 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_HAS_VFPV2
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV6
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_arm1176jz_s
|
|
|
|
bool "arm1176jz-s"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV6
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_arm1176jzf_s
|
|
|
|
bool "arm1176jzf-s"
|
2015-01-23 02:33:25 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_HAS_VFPV2
|
2013-07-17 23:39:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV6
|
2015-11-28 22:55:21 +08:00
|
|
|
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
|
2017-09-03 21:17:41 +08:00
|
|
|
|
|
|
|
comment "armv7a cores"
|
2012-12-09 19:54:03 +08:00
|
|
|
config BR2_cortex_a5
|
|
|
|
bool "cortex-A5"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2012-12-14 06:20:48 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_MAYBE_HAS_VFPV4
|
2013-07-16 16:03:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
2013-06-09 10:53:50 +08:00
|
|
|
config BR2_cortex_a7
|
|
|
|
bool "cortex-A7"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2013-06-09 10:53:50 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_HAS_VFPV4
|
2013-07-16 16:03:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_cortex_a8
|
|
|
|
bool "cortex-A8"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2012-12-14 06:20:48 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_HAS_VFPV3
|
2013-07-16 16:03:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
config BR2_cortex_a9
|
|
|
|
bool "cortex-A9"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2012-12-14 06:20:48 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_MAYBE_HAS_VFPV3
|
2013-07-16 16:03:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
2014-04-24 09:00:31 +08:00
|
|
|
config BR2_cortex_a12
|
|
|
|
bool "cortex-A12"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2014-04-24 09:00:31 +08:00
|
|
|
select BR2_ARM_CPU_HAS_NEON
|
|
|
|
select BR2_ARM_CPU_HAS_VFPV4
|
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
2012-12-09 19:54:03 +08:00
|
|
|
config BR2_cortex_a15
|
|
|
|
bool "cortex-A15"
|
2015-01-23 02:33:25 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
2012-12-14 06:20:48 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
select BR2_ARM_CPU_HAS_VFPV4
|
2013-07-16 16:03:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2014-10-22 04:26:48 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7A
|
2017-07-09 17:30:00 +08:00
|
|
|
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
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_4_9
|
2016-02-21 21:12:10 +08:00
|
|
|
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
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
2017-07-09 17:30:00 +08:00
|
|
|
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
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
2017-09-03 21:17:41 +08:00
|
|
|
config BR2_pj4
|
|
|
|
bool "pj4"
|
|
|
|
select BR2_ARM_CPU_HAS_ARM
|
|
|
|
select BR2_ARM_CPU_HAS_VFPV3
|
|
|
|
select BR2_ARM_CPU_ARMV7A
|
|
|
|
|
2022-06-08 17:46:49 +08:00
|
|
|
# Cortex-M cores are only supported for little endian configurations
|
|
|
|
if BR2_arm
|
2017-09-03 21:17:41 +08:00
|
|
|
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
|
2018-02-26 04:18:17 +08:00
|
|
|
select BR2_ARM_CPU_MAYBE_HAS_FPV4
|
2017-09-03 21:17:41 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7M
|
2018-02-26 04:18:13 +08:00
|
|
|
config BR2_cortex_m7
|
|
|
|
bool "cortex-M7"
|
|
|
|
select BR2_ARM_CPU_HAS_THUMB2
|
2018-02-26 04:18:18 +08:00
|
|
|
select BR2_ARM_CPU_MAYBE_HAS_FPV5
|
2018-02-26 04:18:13 +08:00
|
|
|
select BR2_ARM_CPU_ARMV7M
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
2022-06-08 17:46:49 +08:00
|
|
|
endif # BR2_arm
|
2017-09-03 21:17:42 +08:00
|
|
|
endif # !BR2_ARCH_IS_64
|
2017-09-03 21:17:41 +08:00
|
|
|
|
|
|
|
comment "armv8 cores"
|
2017-09-03 21:17:45 +08:00
|
|
|
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
|
2017-09-03 21:17:46 +08:00
|
|
|
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
|
2016-12-01 05:12:10 +08:00
|
|
|
config BR2_cortex_a53
|
|
|
|
bool "cortex-A53"
|
2016-12-07 17:25:20 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
|
2016-12-07 17:25:21 +08:00
|
|
|
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
|
2016-12-07 17:25:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
|
2016-12-01 05:12:10 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
2017-09-03 21:17:43 +08:00
|
|
|
select BR2_ARM_CPU_ARMV8A
|
2016-12-01 05:12:11 +08:00
|
|
|
config BR2_cortex_a57
|
|
|
|
bool "cortex-A57"
|
2016-12-07 17:25:20 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
|
2016-12-07 17:25:21 +08:00
|
|
|
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
|
2016-12-07 17:25:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
|
2016-12-01 05:12:11 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
2017-09-03 21:17:43 +08:00
|
|
|
select BR2_ARM_CPU_ARMV8A
|
2017-07-09 17:30:00 +08:00
|
|
|
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
|
2017-09-03 21:17:43 +08:00
|
|
|
select BR2_ARM_CPU_ARMV8A
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
|
2016-12-01 05:12:11 +08:00
|
|
|
config BR2_cortex_a72
|
|
|
|
bool "cortex-A72"
|
2016-12-07 17:25:20 +08:00
|
|
|
select BR2_ARM_CPU_HAS_ARM if !BR2_ARCH_IS_64
|
2016-12-07 17:25:21 +08:00
|
|
|
select BR2_ARM_CPU_HAS_NEON if !BR2_ARCH_IS_64
|
2016-12-07 17:25:22 +08:00
|
|
|
select BR2_ARM_CPU_HAS_THUMB2 if !BR2_ARCH_IS_64
|
2016-12-01 05:12:11 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
2017-09-03 21:17:43 +08:00
|
|
|
select BR2_ARM_CPU_ARMV8A
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
2017-07-09 17:30:00 +08:00
|
|
|
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
|
2017-09-03 21:17:43 +08:00
|
|
|
select BR2_ARM_CPU_ARMV8A
|
2017-09-03 17:44:33 +08:00
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
|
2017-09-03 21:17:46 +08:00
|
|
|
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
|
2019-06-20 18:07:22 +08:00
|
|
|
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
|
2017-09-03 21:17:47 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
2019-06-20 18:07:22 +08:00
|
|
|
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
|
2017-09-03 21:17:47 +08:00
|
|
|
config BR2_qdf24xx
|
|
|
|
bool "qdf24xx"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
|
|
|
|
config BR2_thunderx
|
2019-06-20 18:07:20 +08:00
|
|
|
bool "thunderx (aka octeontx)"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
|
|
|
config BR2_thunderxt81
|
2019-06-20 18:07:20 +08:00
|
|
|
bool "thunderxt81 (aka octeontx81)"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
|
|
|
config BR2_thunderxt83
|
2019-06-20 18:07:20 +08:00
|
|
|
bool "thunderxt83 (aka octeontx83)"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:47 +08:00
|
|
|
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
|
2017-09-03 21:17:48 +08:00
|
|
|
|
|
|
|
comment "armv8.1a cores"
|
|
|
|
config BR2_thunderx2t99
|
|
|
|
bool "thunderx2t99"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:48 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:48 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2017-09-03 21:17:48 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
arch/arm: add armv8.2a cortex-based cores
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-30 22:16:12 +08:00
|
|
|
|
|
|
|
comment "armv8.2a cores"
|
|
|
|
config BR2_cortex_a55
|
|
|
|
bool "cortex-A55"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
arch/arm: add armv8.2a cortex-based cores
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-30 22:16:12 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
arch/arm: add armv8.2a cortex-based cores
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-30 22:16:12 +08:00
|
|
|
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"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
arch/arm: add armv8.2a cortex-based cores
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-30 22:16:12 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
|
2019-06-20 18:07:23 +08:00
|
|
|
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
|
2019-06-20 18:07:24 +08:00
|
|
|
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
|
2018-12-30 22:16:13 +08:00
|
|
|
|
2019-06-20 18:07:21 +08:00
|
|
|
comment "armv8.4a cores"
|
2018-12-30 22:16:13 +08:00
|
|
|
config BR2_saphira
|
|
|
|
bool "saphira"
|
2019-06-20 18:07:19 +08:00
|
|
|
depends on BR2_ARCH_IS_64
|
2018-12-30 22:16:13 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FP_ARMV8
|
|
|
|
select BR2_ARM_CPU_ARMV8A
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
endchoice
|
|
|
|
|
2015-12-27 00:05:41 +08:00
|
|
|
config BR2_ARM_ENABLE_NEON
|
|
|
|
bool "Enable NEON SIMD extension support"
|
|
|
|
depends on BR2_ARM_CPU_MAYBE_HAS_NEON
|
|
|
|
select BR2_ARM_CPU_HAS_NEON
|
|
|
|
help
|
|
|
|
For some CPU cores, the NEON SIMD extension is optional.
|
|
|
|
Select this option if you are certain your particular
|
|
|
|
implementation has NEON support and you want to use it.
|
|
|
|
|
arch/arm: add option to enable an optional VFP unit
Currently, the VFP selection for ARM is a little bit muddy:
- some CPUs definitely do not have a VFP or NEON,
- some CPUs definitely do have a VFP or NEON,
- some CPUs may have a VFP or NEON.
However, we currently conflate the availability of the VFP/NEON with the
possibility to use them. Even is the user chooses a floating point
strategy with a 'lower' solution (i.e. VFPv2 when a VFPv3 exists, or not
using NEON when the CPU has it), some packages are still using the
CPU-defined HW availaibility rather thean the usr's selection.
Furthermore, for CPU that may have a VFP/NEON, there is no way for the
user to actually specify that the HW is indeed available; the user can
only specify the floating point strategy. This means that some packages
or some package versions, like nodejs for example, can not be properly
selected on some CPU cores, like Cortex-A9 which only may have a VFP.
Like we have an option to enable an optional NEON unit, add a similar
option to enable an optional VFP unit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 00:05:42 +08:00
|
|
|
config BR2_ARM_ENABLE_VFP
|
|
|
|
bool "Enable VFP extension support"
|
2018-02-26 04:18:14 +08:00
|
|
|
depends on BR2_ARM_CPU_MAYBE_HAS_FPU
|
2018-02-26 04:18:16 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FPV5 if BR2_ARM_CPU_MAYBE_HAS_FPV5
|
2018-02-26 04:18:15 +08:00
|
|
|
select BR2_ARM_CPU_HAS_FPV4 if BR2_ARM_CPU_MAYBE_HAS_FPV4
|
arch/arm: add option to enable an optional VFP unit
Currently, the VFP selection for ARM is a little bit muddy:
- some CPUs definitely do not have a VFP or NEON,
- some CPUs definitely do have a VFP or NEON,
- some CPUs may have a VFP or NEON.
However, we currently conflate the availability of the VFP/NEON with the
possibility to use them. Even is the user chooses a floating point
strategy with a 'lower' solution (i.e. VFPv2 when a VFPv3 exists, or not
using NEON when the CPU has it), some packages are still using the
CPU-defined HW availaibility rather thean the usr's selection.
Furthermore, for CPU that may have a VFP/NEON, there is no way for the
user to actually specify that the HW is indeed available; the user can
only specify the floating point strategy. This means that some packages
or some package versions, like nodejs for example, can not be properly
selected on some CPU cores, like Cortex-A9 which only may have a VFP.
Like we have an option to enable an optional NEON unit, add a similar
option to enable an optional VFP unit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 00:05:42 +08:00
|
|
|
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
|
2015-12-27 19:22:43 +08:00
|
|
|
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.
|
arch/arm: add option to enable an optional VFP unit
Currently, the VFP selection for ARM is a little bit muddy:
- some CPUs definitely do not have a VFP or NEON,
- some CPUs definitely do have a VFP or NEON,
- some CPUs may have a VFP or NEON.
However, we currently conflate the availability of the VFP/NEON with the
possibility to use them. Even is the user chooses a floating point
strategy with a 'lower' solution (i.e. VFPv2 when a VFPv3 exists, or not
using NEON when the CPU has it), some packages are still using the
CPU-defined HW availaibility rather thean the usr's selection.
Furthermore, for CPU that may have a VFP/NEON, there is no way for the
user to actually specify that the HW is indeed available; the user can
only specify the floating point strategy. This means that some packages
or some package versions, like nodejs for example, can not be properly
selected on some CPU cores, like Cortex-A9 which only may have a VFP.
Like we have an option to enable an optional NEON unit, add a similar
option to enable an optional VFP unit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 00:05:42 +08:00
|
|
|
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
choice
|
|
|
|
prompt "Target ABI"
|
2018-02-26 04:18:14 +08:00
|
|
|
default BR2_ARM_EABIHF if BR2_ARM_CPU_HAS_FPU
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
default BR2_ARM_EABI
|
2018-04-01 13:08:34 +08:00
|
|
|
depends on BR2_arm || BR2_armeb
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
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 16:03:14 +08: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.).
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
|
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 16:03:14 +08:00
|
|
|
config BR2_ARM_EABI
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
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 16:03:14 +08: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).
|
Split target/Config.in.arch into multiple Config.in.* in arch/
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-03 16:27:59 +08:00
|
|
|
|
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 16:03:14 +08: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'.
|
2013-02-06 21:51:24 +08:00
|
|
|
|
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 16:03:14 +08: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"
|
2018-02-26 04:18:14 +08:00
|
|
|
depends on BR2_ARM_CPU_HAS_FPU
|
2013-07-16 16:03:13 +08:00
|
|
|
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 16:03:14 +08: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
|
2013-07-16 16:03:13 +08:00
|
|
|
|
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 16:03:14 +08:00
|
|
|
choice
|
|
|
|
prompt "Floating point strategy"
|
2016-12-01 05:12:08 +08:00
|
|
|
default BR2_ARM_FPU_FP_ARMV8 if BR2_ARM_CPU_HAS_FP_ARMV8
|
2018-02-26 04:18:16 +08:00
|
|
|
default BR2_ARM_FPU_FPV5D16 if BR2_ARM_CPU_HAS_FPV5
|
2018-02-26 04:18:15 +08:00
|
|
|
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 16:03:14 +08: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
|
2018-02-26 04:18:14 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
help
|
|
|
|
This option allows to use the VFPv2 floating point unit, as
|
2013-07-18 04:30:50 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08: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"
|
2015-12-27 00:05:44 +08:00
|
|
|
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 16:03:14 +08: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.
|
|
|
|
|
2018-02-26 04:18:15 +08:00
|
|
|
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).
|
|
|
|
|
2018-02-26 04:18:16 +08:00
|
|
|
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.
|
|
|
|
|
2016-12-01 05:12:08 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
endchoice
|
|
|
|
|
2013-07-16 16:03:22 +08:00
|
|
|
choice
|
|
|
|
prompt "ARM instruction set"
|
arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.
Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.
In order to do this, we:
- Make the "ARM instruction set" choice only visible on ARM 32 bits,
since we currently don't support ARM vs. Thumb on AArch64.
- Add the relevant values for the BR2_ARCH option.
- Add the relevant values for the BR2_ENDIAN option.
- Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
bits, since this ABI doesn't mean anything on AArch64.
- Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
there is no -mfpu option on AArch64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-01 05:12:04 +08:00
|
|
|
depends on BR2_arm || BR2_armeb
|
2013-07-16 16:03:22 +08:00
|
|
|
|
2015-01-23 02:33:25 +08:00
|
|
|
config BR2_ARM_INSTRUCTIONS_ARM
|
2013-07-16 16:03:22 +08:00
|
|
|
bool "ARM"
|
2015-01-23 02:33:25 +08:00
|
|
|
depends on BR2_ARM_CPU_HAS_ARM
|
2013-07-16 16:03:22 +08:00
|
|
|
help
|
|
|
|
This option instructs the compiler to generate regular ARM
|
|
|
|
instructions, that are all 32 bits wide.
|
|
|
|
|
2013-07-17 23:39:15 +08:00
|
|
|
config BR2_ARM_INSTRUCTIONS_THUMB
|
|
|
|
bool "Thumb"
|
|
|
|
depends on BR2_ARM_CPU_HAS_THUMB
|
2015-11-03 07:34:37 +08:00
|
|
|
# Thumb-1 and VFP are not compatible
|
|
|
|
depends on BR2_ARM_SOFT_FLOAT
|
2013-07-17 23:39:15 +08:00
|
|
|
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.
|
|
|
|
|
2015-11-03 07:34:37 +08:00
|
|
|
comment "Thumb1 is not compatible with VFP"
|
|
|
|
depends on BR2_ARM_CPU_HAS_THUMB
|
|
|
|
depends on !BR2_ARM_SOFT_FLOAT
|
|
|
|
|
2013-07-16 16:03:22 +08:00
|
|
|
config BR2_ARM_INSTRUCTIONS_THUMB2
|
|
|
|
bool "Thumb2"
|
2013-07-17 23:39:15 +08:00
|
|
|
depends on BR2_ARM_CPU_HAS_THUMB2
|
2013-07-16 16:03:22 +08:00
|
|
|
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 21:12:48 +08: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"
|
|
|
|
|
2023-12-11 23:59:50 +08:00
|
|
|
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 21:12:48 +08:00
|
|
|
config BR2_ARM64_PAGE_SIZE_64K
|
|
|
|
bool "64KB"
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config BR2_ARM64_PAGE_SIZE
|
|
|
|
string
|
|
|
|
default "4K" if BR2_ARM64_PAGE_SIZE_4K
|
2023-12-11 23:59:50 +08:00
|
|
|
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 21:12:48 +08:00
|
|
|
default "64K" if BR2_ARM64_PAGE_SIZE_64K
|
|
|
|
|
arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 11:53:48 +08:00
|
|
|
config BR2_ARCH
|
arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.
Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.
In order to do this, we:
- Make the "ARM instruction set" choice only visible on ARM 32 bits,
since we currently don't support ARM vs. Thumb on AArch64.
- Add the relevant values for the BR2_ARCH option.
- Add the relevant values for the BR2_ENDIAN option.
- Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
bits, since this ABI doesn't mean anything on AArch64.
- Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
there is no -mfpu option on AArch64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-01 05:12:04 +08:00
|
|
|
default "arm" if BR2_arm
|
|
|
|
default "armeb" if BR2_armeb
|
|
|
|
default "aarch64" if BR2_aarch64
|
|
|
|
default "aarch64_be" if BR2_aarch64_be
|
arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 11:53:48 +08:00
|
|
|
|
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-16 04:03:00 +08:00
|
|
|
config BR2_NORMALIZED_ARCH
|
2022-01-16 04:02:59 +08:00
|
|
|
default "arm" if BR2_arm || BR2_armeb
|
|
|
|
default "arm64" if BR2_aarch64 || BR2_aarch64_be
|
|
|
|
|
arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 11:53:48 +08:00
|
|
|
config BR2_ENDIAN
|
arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.
Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.
In order to do this, we:
- Make the "ARM instruction set" choice only visible on ARM 32 bits,
since we currently don't support ARM vs. Thumb on AArch64.
- Add the relevant values for the BR2_ARCH option.
- Add the relevant values for the BR2_ENDIAN option.
- Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
bits, since this ABI doesn't mean anything on AArch64.
- Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
there is no -mfpu option on AArch64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-01 05:12:04 +08:00
|
|
|
default "LITTLE" if (BR2_arm || BR2_aarch64)
|
|
|
|
default "BIG" if (BR2_armeb || BR2_aarch64_be)
|
arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 11:53:48 +08:00
|
|
|
|
2013-11-02 23:39:06 +08:00
|
|
|
config BR2_GCC_TARGET_CPU
|
2017-09-03 21:17:41 +08:00
|
|
|
# armv4
|
2012-11-15 11:53:53 +08:00
|
|
|
default "arm920t" if BR2_arm920t
|
|
|
|
default "arm922t" if BR2_arm922t
|
2017-09-03 21:17:41 +08:00
|
|
|
default "fa526" if BR2_fa526
|
|
|
|
default "strongarm" if BR2_strongarm
|
|
|
|
# armv5
|
2012-11-15 11:53:53 +08:00
|
|
|
default "arm926ej-s" if BR2_arm926t
|
2017-09-03 21:17:41 +08:00
|
|
|
default "xscale" if BR2_xscale
|
|
|
|
# armv6
|
2012-11-15 11:53:53 +08:00
|
|
|
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
|
2015-11-28 22:55:21 +08:00
|
|
|
default "mpcore" if BR2_arm11mpcore && BR2_ARM_CPU_HAS_VFPV2
|
|
|
|
default "mpcorenovfp" if BR2_arm11mpcore
|
2017-09-03 21:17:41 +08:00
|
|
|
# armv7a
|
2012-12-09 19:54:03 +08:00
|
|
|
default "cortex-a5" if BR2_cortex_a5
|
2013-06-09 10:53:50 +08:00
|
|
|
default "cortex-a7" if BR2_cortex_a7
|
2012-11-15 11:53:53 +08:00
|
|
|
default "cortex-a8" if BR2_cortex_a8
|
|
|
|
default "cortex-a9" if BR2_cortex_a9
|
2014-04-24 09:00:31 +08:00
|
|
|
default "cortex-a12" if BR2_cortex_a12
|
2012-12-09 19:54:03 +08:00
|
|
|
default "cortex-a15" if BR2_cortex_a15
|
2017-07-09 17:30:00 +08:00
|
|
|
default "cortex-a15.cortex-a7" if BR2_cortex_a15_a7
|
2016-02-21 21:12:10 +08:00
|
|
|
default "cortex-a17" if BR2_cortex_a17
|
2017-07-09 17:30:00 +08:00
|
|
|
default "cortex-a17.cortex-a7" if BR2_cortex_a17_a7
|
2017-09-03 21:17:41 +08:00
|
|
|
default "marvell-pj4" if BR2_pj4
|
|
|
|
# armv7m
|
2015-06-27 01:33:19 +08:00
|
|
|
default "cortex-m3" if BR2_cortex_m3
|
2016-03-19 05:08:05 +08:00
|
|
|
default "cortex-m4" if BR2_cortex_m4
|
2018-02-26 04:18:13 +08:00
|
|
|
default "cortex-m7" if BR2_cortex_m7
|
2017-09-03 21:17:43 +08:00
|
|
|
# armv8a
|
2017-09-03 21:17:45 +08:00
|
|
|
default "cortex-a32" if BR2_cortex_a32
|
2017-09-03 21:17:46 +08:00
|
|
|
default "cortex-a35" if BR2_cortex_a35
|
2017-07-09 17:29:58 +08:00
|
|
|
default "cortex-a53" if BR2_cortex_a53
|
|
|
|
default "cortex-a57" if BR2_cortex_a57
|
2017-07-09 17:30:00 +08:00
|
|
|
default "cortex-a57.cortex-a53" if BR2_cortex_a57_a53
|
2017-07-09 17:29:58 +08:00
|
|
|
default "cortex-a72" if BR2_cortex_a72
|
2017-07-09 17:30:00 +08:00
|
|
|
default "cortex-a72.cortex-a53" if BR2_cortex_a72_a53
|
2017-09-03 21:17:46 +08:00
|
|
|
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
|
2019-06-20 18:07:22 +08:00
|
|
|
default "emag" if BR2_emag
|
2017-09-03 21:17:47 +08:00
|
|
|
default "exynos-m1" if BR2_exynos_m1
|
|
|
|
default "falkor" if BR2_falkor
|
2019-06-20 18:07:22 +08:00
|
|
|
default "phecda" if BR2_phecda
|
2017-09-03 21:17:47 +08:00
|
|
|
default "qdf24xx" if BR2_qdf24xx
|
2019-06-20 18:07:20 +08:00
|
|
|
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
|
2017-09-03 21:17:47 +08:00
|
|
|
default "thunderxt88" if BR2_thunderxt88
|
|
|
|
default "thunderxt88p1" if BR2_thunderxt88p1
|
|
|
|
default "xgene1" if BR2_xgene1
|
2017-09-03 21:17:48 +08:00
|
|
|
# armv8.1a
|
|
|
|
default "thunderx2t99" if BR2_thunderx2t99
|
|
|
|
default "thunderx2t99p1" if BR2_thunderx2t99p1
|
|
|
|
default "vulcan" if BR2_vulcan
|
arch/arm: add armv8.2a cortex-based cores
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-30 22:16:12 +08:00
|
|
|
# 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
|
2019-06-20 18:07:23 +08:00
|
|
|
default "cortex-a76" if BR2_cortex_a76
|
|
|
|
default "cortex-a76.cortex-a55" if BR2_cortex_a76_a55
|
2019-06-20 18:07:24 +08:00
|
|
|
default "neoverse-n1" if BR2_neoverse_n1
|
|
|
|
default "tsv110" if BR2_tsv110
|
2019-06-20 18:07:21 +08:00
|
|
|
# armv8.4a
|
2018-12-30 22:16:13 +08:00
|
|
|
default "saphira" if BR2_saphira
|
arch: improve definition of gcc mtune, mcpu, etc.
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-15 11:53:48 +08:00
|
|
|
|
|
|
|
config BR2_GCC_TARGET_ABI
|
arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.
Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.
In order to do this, we:
- Make the "ARM instruction set" choice only visible on ARM 32 bits,
since we currently don't support ARM vs. Thumb on AArch64.
- Add the relevant values for the BR2_ARCH option.
- Add the relevant values for the BR2_ENDIAN option.
- Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
bits, since this ABI doesn't mean anything on AArch64.
- Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
there is no -mfpu option on AArch64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-01 05:12:04 +08:00
|
|
|
default "aapcs-linux" if BR2_arm || BR2_armeb
|
2016-12-01 05:12:09 +08:00
|
|
|
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 16:03:14 +08:00
|
|
|
|
|
|
|
config BR2_GCC_TARGET_FPU
|
|
|
|
default "vfp" if BR2_ARM_FPU_VFPV2
|
|
|
|
default "vfpv3" if BR2_ARM_FPU_VFPV3
|
2017-03-26 23:05:43 +08:00
|
|
|
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
|
2018-02-26 04:18:15 +08:00
|
|
|
default "fpv4-sp-d16" if BR2_ARM_FPU_FPV4D16
|
2018-02-26 04:18:16 +08:00
|
|
|
default "fpv5-sp-d16" if BR2_ARM_FPU_FPV5D16
|
|
|
|
default "fpv5-d16" if BR2_ARM_FPU_FPV5DPD16
|
2016-12-01 05:12:08 +08:00
|
|
|
default "fp-armv8" if BR2_ARM_FPU_FP_ARMV8
|
|
|
|
default "neon-fp-armv8" if BR2_ARM_FPU_NEON_FP_ARMV8
|
2018-04-01 13:08:34 +08:00
|
|
|
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 16:03:14 +08: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
|
2013-07-16 16:03:22 +08:00
|
|
|
|
|
|
|
config BR2_GCC_TARGET_MODE
|
|
|
|
default "arm" if BR2_ARM_INSTRUCTIONS_ARM
|
2013-07-17 23:39:15 +08:00
|
|
|
default "thumb" if BR2_ARM_INSTRUCTIONS_THUMB || BR2_ARM_INSTRUCTIONS_THUMB2
|
2017-03-19 21:07:51 +08:00
|
|
|
|
|
|
|
config BR2_READELF_ARCH_NAME
|
|
|
|
default "ARM" if BR2_arm || BR2_armeb
|
|
|
|
default "AArch64" if BR2_aarch64 || BR2_aarch64_be
|
2019-05-03 21:10:17 +08:00
|
|
|
|
|
|
|
# vim: ft=kconfig
|
|
|
|
# -*- mode:kconfig; -*-
|