The xPack GNU RISC-V Embedded GCC Frequently Asked Questions
My device is not supported. Will it ever be?
The answer depends on several factors.
If there are compelling reasons, it may be considered. For instance, if it is a highly successful commercial device, we might add it to the list. Please double-check the latest release and, if your device is not listed there, submit a feature request in the project's GitHub Discussions.
However, if it is a non-standard device or utilises vendor-specific extensions, the likelihood is minimal. In such cases, please use the toolchains provided by the vendor.
Why do I get unrecognized opcode csrr?
Starting with GCC 12.x, the compiler implements the new RISC-V ISA, which introduces an incompatibility issue
The solution is to add _zicsr and/or _zifencei to the
-march option, e.g. -march=rv32imac becomes
-march=rv32imac_zicsr_zifencei.
There are two RISC-V toolchains, riscv64-unknown-elf-gcc and
riscv32-unknown-elf-gcc (or riscv64-none-elf-gcc and
riscv32-none-elf-gcc); you have only one. How can you generate
32 and 64-bit code?
All RISC-V GCC toolchains, if built correctly, are able to generate
both 32/64-bit code, based on -march and -mabi. Thus a single
version is enough for all use cases.
Why riscv-none-elf-gcc and not riscv-none-eabi-gcc, as Arm uses?
For the moment RISC-V does not define an EABI (Embedded ABI) and uses the
same Unix ABI for embedded applications too, thus -eabi- would not be
accurate.
Nix also provides reproducible builds, why not utilise it?
The concise answer is… "because of Windows".
Nix is a remarkable project that carefully controls versions down to individual libraries. However, it relies on file links, which are either unavailable or unreliable on Windows.
As a result, Nix is currently only available on GNU/Linux and, with some limitations, on macOS. Additionally, mastering the Nix language requires considerable effort.