2013-09-04 23:35:55 +02:00
|
|
|
menu "Target options"
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
config BR2_ARCH_IS_64
|
2013-07-16 10:03:25 +02:00
|
|
|
bool
|
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 09:27:59 +01:00
|
|
|
|
2013-10-25 15:10:22 +02:00
|
|
|
config BR2_KERNEL_64_USERLAND_32
|
|
|
|
|
bool
|
|
|
|
|
|
2013-07-16 10:03:13 +02:00
|
|
|
config BR2_SOFT_FLOAT
|
|
|
|
|
bool
|
|
|
|
|
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
config BR2_USE_MMU
|
2015-06-04 00:34:03 +02:00
|
|
|
bool
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
choice
|
|
|
|
|
prompt "Target Architecture"
|
|
|
|
|
default BR2_i386
|
|
|
|
|
help
|
|
|
|
|
Select the target architecture family to build for.
|
|
|
|
|
|
2013-05-02 11:51:23 +02:00
|
|
|
config BR2_arcle
|
|
|
|
|
bool "ARC (little endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2013-05-02 11:51:23 +02:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
Synopsys' DesignWare ARC Processor Cores are a family of
|
|
|
|
|
32-bit CPUs that can be used from deeply embedded to high
|
|
|
|
|
performance host applications. Little endian.
|
2013-05-02 11:51:23 +02:00
|
|
|
|
|
|
|
|
config BR2_arceb
|
|
|
|
|
bool "ARC (big endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2013-05-02 11:51:23 +02:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
Synopsys' DesignWare ARC Processor Cores are a family of
|
|
|
|
|
32-bit CPUs that can be used from deeply embedded to high
|
|
|
|
|
performance host applications. Big endian.
|
2013-05-02 11:51:23 +02: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 09:27:59 +01:00
|
|
|
config BR2_arm
|
|
|
|
|
bool "ARM (little endian)"
|
2015-06-04 00:34:03 +02:00
|
|
|
# MMU support is set by the subarchitecture file, arch/Config.in.arm
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
ARM is a 32-bit reduced instruction set computer (RISC)
|
|
|
|
|
instruction set architecture (ISA) developed by ARM Holdings.
|
|
|
|
|
Little endian.
|
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 09:27:59 +01:00
|
|
|
http://www.arm.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/ARM
|
|
|
|
|
|
|
|
|
|
config BR2_armeb
|
|
|
|
|
bool "ARM (big endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
ARM is a 32-bit reduced instruction set computer (RISC)
|
|
|
|
|
instruction set architecture (ISA) developed by ARM Holdings.
|
|
|
|
|
Big endian.
|
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 09:27:59 +01:00
|
|
|
http://www.arm.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/ARM
|
|
|
|
|
|
|
|
|
|
config BR2_aarch64
|
2015-03-18 10:49:48 +01:00
|
|
|
bool "AArch64 (little endian)"
|
|
|
|
|
select BR2_ARCH_IS_64
|
|
|
|
|
help
|
|
|
|
|
Aarch64 is a 64-bit architecture developed by ARM Holdings.
|
|
|
|
|
http://www.arm.com/products/processors/instruction-set-architectures/armv8-architecture.php
|
|
|
|
|
http://en.wikipedia.org/wiki/ARM
|
|
|
|
|
|
|
|
|
|
config BR2_aarch64_be
|
|
|
|
|
bool "AArch64 (big endian)"
|
2013-03-18 06:18:09 +01:00
|
|
|
select BR2_ARCH_IS_64
|
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 09:27:59 +01:00
|
|
|
help
|
|
|
|
|
Aarch64 is a 64-bit architecture developed by ARM Holdings.
|
|
|
|
|
http://www.arm.com/products/processors/instruction-set-architectures/armv8-architecture.php
|
|
|
|
|
http://en.wikipedia.org/wiki/ARM
|
|
|
|
|
|
|
|
|
|
config BR2_i386
|
|
|
|
|
bool "i386"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
|
|
|
|
Intel i386 architecture compatible microprocessor
|
|
|
|
|
http://en.wikipedia.org/wiki/I386
|
|
|
|
|
|
|
|
|
|
config BR2_m68k
|
|
|
|
|
bool "m68k"
|
2016-04-29 19:51:23 +02:00
|
|
|
# MMU support is set by the subarchitecture file, arch/Config.in.m68k
|
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 09:27:59 +01:00
|
|
|
help
|
|
|
|
|
Motorola 68000 family microprocessor
|
|
|
|
|
http://en.wikipedia.org/wiki/M68k
|
|
|
|
|
|
|
|
|
|
config BR2_microblazeel
|
|
|
|
|
bool "Microblaze AXI (little endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
Soft processor core designed for Xilinx FPGAs from Xilinx. AXI
|
|
|
|
|
bus based architecture (little endian)
|
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 09:27:59 +01:00
|
|
|
http://www.xilinx.com
|
|
|
|
|
http://en.wikipedia.org/wiki/Microblaze
|
|
|
|
|
|
|
|
|
|
config BR2_microblazebe
|
|
|
|
|
bool "Microblaze non-AXI (big endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
Soft processor core designed for Xilinx FPGAs from Xilinx. PLB
|
|
|
|
|
bus based architecture (non-AXI, big endian)
|
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 09:27:59 +01:00
|
|
|
http://www.xilinx.com
|
|
|
|
|
http://en.wikipedia.org/wiki/Microblaze
|
|
|
|
|
|
|
|
|
|
config BR2_mips
|
|
|
|
|
bool "MIPS (big endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
MIPS is a RISC microprocessor from MIPS Technologies. Big
|
|
|
|
|
endian.
|
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 09:27:59 +01:00
|
|
|
http://www.mips.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/MIPS_Technologies
|
|
|
|
|
|
|
|
|
|
config BR2_mipsel
|
|
|
|
|
bool "MIPS (little endian)"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
MIPS is a RISC microprocessor from MIPS Technologies. Little
|
|
|
|
|
endian.
|
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 09:27:59 +01:00
|
|
|
http://www.mips.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/MIPS_Technologies
|
|
|
|
|
|
|
|
|
|
config BR2_mips64
|
|
|
|
|
bool "MIPS64 (big endian)"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
MIPS is a RISC microprocessor from MIPS Technologies. Big
|
|
|
|
|
endian.
|
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 09:27:59 +01:00
|
|
|
http://www.mips.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/MIPS_Technologies
|
|
|
|
|
|
|
|
|
|
config BR2_mips64el
|
|
|
|
|
bool "MIPS64 (little endian)"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
MIPS is a RISC microprocessor from MIPS Technologies. Little
|
|
|
|
|
endian.
|
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 09:27:59 +01:00
|
|
|
http://www.mips.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/MIPS_Technologies
|
|
|
|
|
|
2013-08-30 00:10:40 +02:00
|
|
|
config BR2_nios2
|
|
|
|
|
bool "Nios II"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2013-08-30 00:10:40 +02:00
|
|
|
help
|
|
|
|
|
Nios II is a soft core processor from Altera Corporation.
|
|
|
|
|
http://www.altera.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/Nios_II
|
|
|
|
|
|
2017-01-25 07:35:07 +01:00
|
|
|
config BR2_or1k
|
|
|
|
|
bool "OpenRISC"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2017-01-25 07:35:07 +01:00
|
|
|
help
|
|
|
|
|
OpenRISC is a free and open processor for embedded system.
|
|
|
|
|
http://openrisc.io
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
config BR2_powerpc
|
|
|
|
|
bool "PowerPC"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
PowerPC is a RISC architecture created by Apple-IBM-Motorola
|
|
|
|
|
alliance. Big endian.
|
2014-05-13 07:28:21 +02:00
|
|
|
http://www.power.org/
|
|
|
|
|
http://en.wikipedia.org/wiki/Powerpc
|
|
|
|
|
|
|
|
|
|
config BR2_powerpc64
|
|
|
|
|
bool "PowerPC64 (big endian)"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2014-05-13 07:28:21 +02:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
PowerPC is a RISC architecture created by Apple-IBM-Motorola
|
|
|
|
|
alliance. Big endian.
|
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 09:27:59 +01:00
|
|
|
http://www.power.org/
|
|
|
|
|
http://en.wikipedia.org/wiki/Powerpc
|
|
|
|
|
|
2014-05-25 08:59:22 +02:00
|
|
|
config BR2_powerpc64le
|
|
|
|
|
bool "PowerPC64 (little endian)"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2014-05-25 08:59:22 +02:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
PowerPC is a RISC architecture created by Apple-IBM-Motorola
|
|
|
|
|
alliance. Little endian.
|
2014-05-25 08:59:22 +02:00
|
|
|
http://www.power.org/
|
|
|
|
|
http://en.wikipedia.org/wiki/Powerpc
|
|
|
|
|
|
2018-09-12 12:22:54 +02:00
|
|
|
config BR2_riscv
|
|
|
|
|
bool "RISCV"
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
|
|
|
|
help
|
|
|
|
|
RISC-V is an open, free Instruction Set Architecture created
|
|
|
|
|
by the UC Berkeley Architecture Research group and supported
|
|
|
|
|
and promoted by RISC-V Foundation.
|
|
|
|
|
https://riscv.org/
|
|
|
|
|
https://en.wikipedia.org/wiki/RISC-V
|
|
|
|
|
|
2020-09-17 06:07:51 +02:00
|
|
|
config BR2_s390x
|
|
|
|
|
bool "s390x"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2020-09-17 06:07:51 +02:00
|
|
|
help
|
|
|
|
|
s390x is a big-endian architecture made by IBM.
|
|
|
|
|
http://www.ibm.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/IBM_System/390
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
config BR2_sh
|
|
|
|
|
bool "SuperH"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
SuperH (or SH) is a 32-bit reduced instruction set computer
|
|
|
|
|
(RISC) instruction set architecture (ISA) developed by
|
|
|
|
|
Hitachi.
|
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 09:27:59 +01:00
|
|
|
http://www.hitachi.com/
|
|
|
|
|
http://en.wikipedia.org/wiki/SuperH
|
|
|
|
|
|
|
|
|
|
config BR2_sparc
|
|
|
|
|
bool "SPARC"
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2023-07-28 00:25:43 +02:00
|
|
|
# uClibc-ng broken on sparc due to recent gcc changes
|
|
|
|
|
# that need to be reverted since gcc 8.4, 9.3 and 10.1.
|
|
|
|
|
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784
|
|
|
|
|
# gcc <= 10.x has been removed from Buildroot.
|
|
|
|
|
select BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
|
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 09:27:59 +01:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
SPARC (from Scalable Processor Architecture) is a RISC
|
|
|
|
|
instruction set architecture (ISA) developed by Sun
|
|
|
|
|
Microsystems.
|
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 09:27:59 +01:00
|
|
|
http://www.oracle.com/sun
|
|
|
|
|
http://en.wikipedia.org/wiki/Sparc
|
|
|
|
|
|
2015-08-29 09:57:33 +02:00
|
|
|
config BR2_sparc64
|
|
|
|
|
bool "SPARC64"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
2015-08-29 09:57:33 +02:00
|
|
|
help
|
2018-04-01 07:08:40 +02:00
|
|
|
SPARC (from Scalable Processor Architecture) is a RISC
|
|
|
|
|
instruction set architecture (ISA) developed by Sun
|
|
|
|
|
Microsystems.
|
2015-08-29 09:57:33 +02:00
|
|
|
http://www.oracle.com/sun
|
|
|
|
|
http://en.wikipedia.org/wiki/Sparc
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
config BR2_x86_64
|
|
|
|
|
bool "x86_64"
|
|
|
|
|
select BR2_ARCH_IS_64
|
arch: rework MMU option handling and move to "Target architecture" menu
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
|
|
|
select BR2_USE_MMU
|
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 09:27:59 +01:00
|
|
|
help
|
|
|
|
|
x86-64 is an extension of the x86 instruction set (Intel i386
|
|
|
|
|
architecture compatible microprocessor).
|
|
|
|
|
http://en.wikipedia.org/wiki/X86_64
|
|
|
|
|
|
2012-11-15 04:53:51 +01:00
|
|
|
config BR2_xtensa
|
|
|
|
|
bool "Xtensa"
|
2015-06-04 00:34:03 +02:00
|
|
|
# MMU support is set by the subarchitecture file, arch/Config.in.xtensa
|
2012-11-15 04:53:51 +01:00
|
|
|
help
|
|
|
|
|
Xtensa is a Tensilica processor IP architecture.
|
|
|
|
|
http://en.wikipedia.org/wiki/Xtensa
|
|
|
|
|
http://www.tensilica.com/
|
|
|
|
|
|
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 09:27:59 +01:00
|
|
|
endchoice
|
|
|
|
|
|
2017-09-03 11:22:16 +02:00
|
|
|
# For some architectures or specific cores, our internal toolchain
|
|
|
|
|
# backend is not suitable (like, missing support in upstream gcc, or
|
|
|
|
|
# no ChipCo fork exists...)
|
|
|
|
|
config BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT
|
|
|
|
|
bool
|
|
|
|
|
default y if !BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
|
|
|
|
|
|
arch: introduce minimal required gcc version
Some CPU variants require that a recent-enough gcc be selected. For
example, ARM's cortex-a35 requires gcc-5, while cortex-a73 requires
gcc-7. Same goes for other architectures, of course.
Currently, we hard-code every such conditions in the gcc version choice,
as well as in the individual external toolchains.
However, as we add even more CPU variants, the conditions are getting
more and more complex to write and maintain.
Introduce new symbols, that architectures can select if they have a
specific requirement on the gcc version. gcc and external toolchains
can then properly depend on those symbols.
The burden of maintaining the requirements on the gcc version now falls
down to the architeture, instead of being split up in gcc and all the
external toolchains.
As the oldest gcc version to handle, we can either choose gcc-4.9, as
the oldest version we support in our internal toolchain, or choose
gcc-4.8, as the oldest external toolchain we support (except for the
custom ones, but they'll be handled specifically in upcoming changes).
We choose to go back up to gcc-4.8.
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>
2017-09-03 11:44:27 +02:00
|
|
|
# The following symbols are selected by the individual
|
|
|
|
|
# Config.in.$ARCH files
|
|
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_4_8
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_4_9
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_4_8
|
|
|
|
|
|
|
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_4_9
|
|
|
|
|
|
|
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_6
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_5
|
|
|
|
|
|
|
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_6
|
|
|
|
|
|
2018-05-29 23:52:53 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_8
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_7
|
|
|
|
|
|
2019-06-20 12:07:16 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_9
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_8
|
|
|
|
|
|
2020-06-09 00:13:45 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_10
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_9
|
|
|
|
|
|
2021-06-12 11:40:13 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_11
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_10
|
|
|
|
|
|
2022-05-29 15:18:09 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_12
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_11
|
|
|
|
|
|
2023-07-28 00:25:40 +02:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_13
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_12
|
|
|
|
|
|
2023-12-27 18:13:41 +01:00
|
|
|
config BR2_ARCH_NEEDS_GCC_AT_LEAST_14
|
|
|
|
|
bool
|
|
|
|
|
select BR2_ARCH_NEEDS_GCC_AT_LEAST_13
|
|
|
|
|
|
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 04:53:48 +01:00
|
|
|
# The following string values are defined by the individual
|
|
|
|
|
# Config.in.$ARCH files
|
|
|
|
|
config BR2_ARCH
|
|
|
|
|
string
|
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 09:27:59 +01: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-15 21:03:00 +01:00
|
|
|
config BR2_NORMALIZED_ARCH
|
2022-01-15 21:02:59 +01:00
|
|
|
string
|
|
|
|
|
|
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 04:53:48 +01:00
|
|
|
config BR2_ENDIAN
|
|
|
|
|
string
|
|
|
|
|
|
|
|
|
|
config BR2_GCC_TARGET_ARCH
|
|
|
|
|
string
|
|
|
|
|
|
|
|
|
|
config BR2_GCC_TARGET_ABI
|
|
|
|
|
string
|
|
|
|
|
|
2017-06-28 17:17:10 +02:00
|
|
|
config BR2_GCC_TARGET_NAN
|
|
|
|
|
string
|
|
|
|
|
|
2017-06-28 17:17:11 +02:00
|
|
|
config BR2_GCC_TARGET_FP32_MODE
|
|
|
|
|
string
|
|
|
|
|
|
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 04:53:48 +01:00
|
|
|
config BR2_GCC_TARGET_CPU
|
|
|
|
|
string
|
|
|
|
|
|
arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 10:03:12 +02:00
|
|
|
# The value of this option will be passed as --with-fpu=<value> when
|
|
|
|
|
# building gcc (internal backend) or -mfpu=<value> in the toolchain
|
|
|
|
|
# wrapper (external toolchain)
|
|
|
|
|
config BR2_GCC_TARGET_FPU
|
|
|
|
|
string
|
|
|
|
|
|
|
|
|
|
# The value of this option will be passed as --with-float=<value> when
|
|
|
|
|
# building gcc (internal backend) or -mfloat-abi=<value> in the toolchain
|
|
|
|
|
# wrapper (external toolchain)
|
|
|
|
|
config BR2_GCC_TARGET_FLOAT_ABI
|
|
|
|
|
string
|
|
|
|
|
|
2013-07-16 10:03:22 +02:00
|
|
|
# The value of this option will be passed as --with-mode=<value> when
|
|
|
|
|
# building gcc (internal backend) or -m<value> in the toolchain
|
|
|
|
|
# wrapper (external toolchain)
|
|
|
|
|
config BR2_GCC_TARGET_MODE
|
|
|
|
|
string
|
|
|
|
|
|
2014-12-03 22:41:32 +01:00
|
|
|
# Must be selected by binary formats that support shared libraries.
|
|
|
|
|
config BR2_BINFMT_SUPPORTS_SHARED
|
|
|
|
|
bool
|
|
|
|
|
|
2017-03-19 14:07:51 +01:00
|
|
|
# Must match the name of the architecture from readelf point of view,
|
|
|
|
|
# i.e the "Machine:" field of readelf output. See get_machine_name()
|
|
|
|
|
# in binutils/readelf.c for the list of possible values.
|
|
|
|
|
config BR2_READELF_ARCH_NAME
|
|
|
|
|
string
|
|
|
|
|
|
2013-05-02 11:51:23 +02:00
|
|
|
if BR2_arcle || BR2_arceb
|
|
|
|
|
source "arch/Config.in.arc"
|
|
|
|
|
endif
|
|
|
|
|
|
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-11-30 22:12:04 +01:00
|
|
|
if BR2_arm || BR2_armeb || BR2_aarch64 || BR2_aarch64_be
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.arm"
|
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 04:53:48 +01:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if BR2_m68k
|
|
|
|
|
source "arch/Config.in.m68k"
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if BR2_microblazeel || BR2_microblazebe
|
|
|
|
|
source "arch/Config.in.microblaze"
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if BR2_mips || BR2_mips64 || BR2_mipsel || BR2_mips64el
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.mips"
|
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 04:53:48 +01:00
|
|
|
endif
|
|
|
|
|
|
2013-08-30 00:10:40 +02:00
|
|
|
if BR2_nios2
|
|
|
|
|
source "arch/Config.in.nios2"
|
|
|
|
|
endif
|
|
|
|
|
|
2017-01-25 07:35:07 +01:00
|
|
|
if BR2_or1k
|
|
|
|
|
source "arch/Config.in.or1k"
|
|
|
|
|
endif
|
|
|
|
|
|
2014-05-13 07:28:21 +02:00
|
|
|
if BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.powerpc"
|
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 04:53:48 +01:00
|
|
|
endif
|
|
|
|
|
|
2018-09-12 12:22:54 +02:00
|
|
|
if BR2_riscv
|
|
|
|
|
source "arch/Config.in.riscv"
|
|
|
|
|
endif
|
|
|
|
|
|
2020-09-17 06:07:51 +02:00
|
|
|
if BR2_s390x
|
|
|
|
|
source "arch/Config.in.s390x"
|
|
|
|
|
endif
|
|
|
|
|
|
2016-09-08 20:38:57 +02:00
|
|
|
if BR2_sh
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.sh"
|
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 04:53:48 +01:00
|
|
|
endif
|
|
|
|
|
|
2015-08-29 09:57:33 +02:00
|
|
|
if BR2_sparc || BR2_sparc64
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.sparc"
|
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 04:53:48 +01:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if BR2_i386 || BR2_x86_64
|
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 09:27:59 +01:00
|
|
|
source "arch/Config.in.x86"
|
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 04:53:48 +01:00
|
|
|
endif
|
2012-11-15 04:53:51 +01:00
|
|
|
|
|
|
|
|
if BR2_xtensa
|
|
|
|
|
source "arch/Config.in.xtensa"
|
|
|
|
|
endif
|
2013-09-04 23:35:55 +02:00
|
|
|
|
2022-07-26 18:39:50 +02:00
|
|
|
# Set up target binary format
|
|
|
|
|
choice
|
|
|
|
|
prompt "Target Binary Format"
|
|
|
|
|
default BR2_BINFMT_ELF if BR2_USE_MMU
|
|
|
|
|
default BR2_BINFMT_FLAT
|
|
|
|
|
|
|
|
|
|
config BR2_BINFMT_ELF
|
|
|
|
|
bool "ELF"
|
|
|
|
|
depends on BR2_USE_MMU
|
|
|
|
|
select BR2_BINFMT_SUPPORTS_SHARED
|
|
|
|
|
help
|
|
|
|
|
ELF (Executable and Linkable Format) is a format for libraries
|
|
|
|
|
and executables used across different architectures and
|
|
|
|
|
operating systems.
|
|
|
|
|
|
|
|
|
|
config BR2_BINFMT_FLAT
|
|
|
|
|
bool "FLAT"
|
|
|
|
|
depends on !BR2_USE_MMU
|
|
|
|
|
help
|
|
|
|
|
FLAT binary is a relatively simple and lightweight executable
|
|
|
|
|
format based on the original a.out format. It is widely used
|
|
|
|
|
in environment where no MMU is available.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
# Set up flat binary type
|
|
|
|
|
choice
|
|
|
|
|
prompt "FLAT Binary type"
|
|
|
|
|
default BR2_BINFMT_FLAT_ONE
|
|
|
|
|
depends on BR2_BINFMT_FLAT
|
|
|
|
|
|
|
|
|
|
config BR2_BINFMT_FLAT_ONE
|
|
|
|
|
bool "One memory region"
|
|
|
|
|
help
|
|
|
|
|
All segments are linked into one memory region.
|
|
|
|
|
|
|
|
|
|
config BR2_BINFMT_FLAT_SHARED
|
|
|
|
|
bool "Shared binary"
|
|
|
|
|
depends on BR2_m68k
|
|
|
|
|
# Even though this really generates shared binaries, there is no libdl
|
|
|
|
|
# and dlopen() cannot be used. So packages that require shared
|
|
|
|
|
# libraries cannot be built. Therefore, we don't select
|
|
|
|
|
# BR2_BINFMT_SUPPORTS_SHARED and therefore force BR2_STATIC_LIBS.
|
|
|
|
|
# Although this adds -static to the compilation, that's not a problem
|
|
|
|
|
# because the -mid-shared-library option overrides it.
|
|
|
|
|
help
|
|
|
|
|
Allow to load and link indiviual FLAT binaries at run time.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2013-09-04 23:35:55 +02:00
|
|
|
endmenu # Target options
|
