kumquat-buildroot/arch/Config.in.riscv

157 lines
3.1 KiB
Plaintext
Raw Normal View History

# RISC-V CPU ISA extensions.
config BR2_RISCV_ISA_RVI
bool
config BR2_RISCV_ISA_RVM
bool
config BR2_RISCV_ISA_RVA
bool
config BR2_RISCV_ISA_RVF
bool
config BR2_RISCV_ISA_RVD
bool
config BR2_RISCV_ISA_RVC
bool
config BR2_RISCV_ISA_RVV
bool
choice
prompt "Target Architecture Variant"
default BR2_riscv_g
config BR2_riscv_g
bool "General purpose (G)"
select BR2_RISCV_ISA_RVI
select BR2_RISCV_ISA_RVM
select BR2_RISCV_ISA_RVA
select BR2_RISCV_ISA_RVF
select BR2_RISCV_ISA_RVD
help
General purpose (G) is equivalent to IMAFD.
config BR2_riscv_custom
bool "Custom architecture"
select BR2_RISCV_ISA_RVI
endchoice
if BR2_riscv_custom
comment "Instruction Set Extensions"
config BR2_RISCV_ISA_CUSTOM_RVM
bool "Integer Multiplication and Division (M)"
select BR2_RISCV_ISA_RVM
config BR2_RISCV_ISA_CUSTOM_RVA
bool "Atomic Instructions (A)"
select BR2_RISCV_ISA_RVA
config BR2_RISCV_ISA_CUSTOM_RVF
bool "Single-precision Floating-point (F)"
select BR2_RISCV_ISA_RVF
config BR2_RISCV_ISA_CUSTOM_RVD
bool "Double-precision Floating-point (D)"
depends on BR2_RISCV_ISA_RVF
select BR2_RISCV_ISA_RVD
config BR2_RISCV_ISA_CUSTOM_RVC
bool "Compressed Instructions (C)"
select BR2_RISCV_ISA_RVC
config BR2_RISCV_ISA_CUSTOM_RVV
bool "Vector Instructions (V)"
select BR2_RISCV_ISA_RVV
select BR2_ARCH_NEEDS_GCC_AT_LEAST_12
endif
choice
prompt "Target Architecture Size"
default BR2_RISCV_64
config BR2_RISCV_32
bool "32-bit"
arch: rework MMU option handling and move to "Target architecture" menu The MMU option is currently located in the "Toolchain" menu, but it doesn't make sense as it's really architecture related. In addition, the selection of MMU has an impact on the choice of binary format available, which is visible in the architecture menu. Therefore, this commit moves the MMU option into the architecture menu. However, if we simply move it in arch/Config.in, it means that we would have the following order of options: Target architecture Target architecture variant ABI MMU Binary format But really, the MMU option should be right below the Target architecture variant, and the available ABIs derived from that. The variant and ABI are arch-specfic, and defined in the per-arch Config.in fragments; a Kconfig option can have only one prompt defined, even under conditions, and appears at the place in the menu where its prompt was defined. So, there is no (easy) possibility to have a generic option appear where we want it. Since in fact only 2 architectures show a visible prompt for the MMU option (RISC-V and Xtensa), we move this option in arch/Config.in.riscv and arch/Config.in.xtensa. Some walkthrough the commit: - BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are removed as they are no longer needed - BR2_USE_MMU becomes a hidden boolean - All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY now select BR2_USE_MMU directly. - Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU. - All defconfigs that used "# BR2_USE_MMU is not set" are switched to using the new option. All in all, this simplifies things quite a bit, and allows to have a good option ordering in the Target architecture menu. This commit might raise a concern in terms of backward compatibility with existing configurations. The only configurations that will be broken by this change are RISC-V noMMU (which was very recently introduced) and Xtensa noMMU (which we can probably agree is not such a widely popular configuration). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> [yann.morin.1998@free.fr: - expand further why we need per-arch MMU options ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-26 18:39:51 +02:00
select BR2_USE_MMU
config BR2_RISCV_64
bool "64-bit"
select BR2_ARCH_IS_64
endchoice
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_RISCV_USE_MMU
bool "MMU support"
default y
depends on BR2_RISCV_64
select BR2_USE_MMU
help
Enable this option if your RISC-V core has a MMU (Memory
Management Unit).
choice
prompt "Target ABI"
default BR2_RISCV_ABI_ILP32D if !BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVD
default BR2_RISCV_ABI_ILP32F if !BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVF
default BR2_RISCV_ABI_ILP32 if !BR2_ARCH_IS_64
default BR2_RISCV_ABI_LP64D if BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVD
default BR2_RISCV_ABI_LP64F if BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVF
default BR2_RISCV_ABI_LP64 if BR2_ARCH_IS_64
config BR2_RISCV_ABI_ILP32
bool "ilp32"
depends on !BR2_ARCH_IS_64
config BR2_RISCV_ABI_ILP32F
bool "ilp32f"
depends on !BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVF
config BR2_RISCV_ABI_ILP32D
bool "ilp32d"
depends on !BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVD
config BR2_RISCV_ABI_LP64
bool "lp64"
depends on BR2_ARCH_IS_64
config BR2_RISCV_ABI_LP64F
bool "lp64f"
depends on BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVF
depends on BR2_USE_MMU
config BR2_RISCV_ABI_LP64D
bool "lp64d"
depends on BR2_ARCH_IS_64 && BR2_RISCV_ISA_RVD
endchoice
config BR2_ARCH
default "riscv32" if !BR2_ARCH_IS_64
default "riscv64" if BR2_ARCH_IS_64
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
config BR2_NORMALIZED_ARCH
default "riscv"
config BR2_ENDIAN
default "LITTLE"
config BR2_GCC_TARGET_ABI
default "ilp32" if BR2_RISCV_ABI_ILP32
default "ilp32f" if BR2_RISCV_ABI_ILP32F
default "ilp32d" if BR2_RISCV_ABI_ILP32D
default "lp64" if BR2_RISCV_ABI_LP64
default "lp64f" if BR2_RISCV_ABI_LP64F
default "lp64d" if BR2_RISCV_ABI_LP64D
config BR2_READELF_ARCH_NAME
default "RISC-V"
# vim: ft=kconfig
# -*- mode:kconfig; -*-