2018-09-12 12:22:54 +02:00
|
|
|
#
|
|
|
|
|
# Configure the GCC_TARGET_ARCH variable and append the
|
|
|
|
|
# appropriate RISC-V ISA extensions.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_riscv),y)
|
|
|
|
|
|
2018-10-21 21:12:01 +02:00
|
|
|
ifeq ($(BR2_RISCV_64),y)
|
2018-09-12 12:22:54 +02:00
|
|
|
GCC_TARGET_ARCH := rv64i
|
2018-10-21 21:12:01 +02:00
|
|
|
else
|
|
|
|
|
GCC_TARGET_ARCH := rv32i
|
2018-09-12 12:22:54 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_RISCV_ISA_RVM),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)m
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_RISCV_ISA_RVA),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)a
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_RISCV_ISA_RVF),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)f
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_RISCV_ISA_RVD),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)d
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_RISCV_ISA_RVC),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)c
|
|
|
|
|
endif
|
2023-06-09 19:46:42 +02:00
|
|
|
ifeq ($(BR2_RISCV_ISA_RVV),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)v
|
|
|
|
|
endif
|
2018-09-12 12:22:54 +02:00
|
|
|
|
arch/Config.in.riscv: enable Zicsr and Zifencei standalone extensions with gcc >= 12
Since gcc 12, the default RISC-V ISA spec version was bump to 20191213 [1].
This bump introduces a major compatibility issue: support for the csr read/write
(csrr*/csrw*) instructions and fence.i instruction has been separated
from the "I" extension, becoming two standalone extensions: Zicsr and
Zifencei. gcc now has specific -march suffixes to enable those
extensions (_zicsr and _zifencei). If they are not used and code that
uses these instructions is built, one would get errors such as
unrecognized opcode "csrr" (or "fence.i").
For example, without Zifencei we can't build the opensbi
bootloader[2]:
opensbi-1.0/lib/sbi/sbi_tlb.c: Assembler messages:
opensbi-1.0/lib/sbi/sbi_tlb.c:190: Error: unrecognized opcode `fence.i', extension `zifencei' required
As a workaround, the opensbi build system has been patched [3] to use
-march=rv64imafdc_zicsr_zifencei when needed. This workaround doesn't
work in Buildroot due to the local patch
0001-Makefile-Don-t-specify-mabi-or-march.patch which removes -march
from CFLAGS.
In the context of Buildroot, we have decided for now to assume that
all RISC-V cores that are Linux capable will implement the Zicsr and
Zifencei extensions: it is in fact the case today ase these extensions
were part of the I extension, that all cores support. OpenSBI and
Linux are making the same assumption (see [5]).
Therefore, when gcc >= 12, the -march value gets appended with
_zicsr_zifencei.
[1] https://gcc.gnu.org/gcc-12/changes.html
[2] https://github.com/riscv-software-src/opensbi/blob/v0.9/lib/sbi/sbi_tlb.c#L173
[3] https://github.com/riscv-software-src/opensbi/commit/5d53b55aa77ffeefd4012445dfa6ad3535e1ff2c
[4] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4
[5] http://lists.busybox.net/pipermail/buildroot/2022-July/646698.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Mark Corbin <mark@dibsco.co.uk>
[Thomas: add comment in .mk file, rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-07-23 15:35:24 +02:00
|
|
|
# Starting from gcc 12.x, csr and fence instructions have been
|
|
|
|
|
# separated from the base I instruction set, and special -march
|
|
|
|
|
# suffixes are needed to enable their support. In Buildroot, we assume
|
|
|
|
|
# all RISC-V cores that support Linux implement those instructions, so
|
|
|
|
|
# we unconditionally enable those extensions.
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_12),y)
|
|
|
|
|
GCC_TARGET_ARCH := $(GCC_TARGET_ARCH)_zicsr_zifencei
|
|
|
|
|
endif
|
|
|
|
|
|
2018-09-12 12:22:54 +02:00
|
|
|
endif
|
