riscv-rt: Support rv32e
#178
Conversation
hegza
force-pushed
the
rve
branch
2 times, most recently
from
959971b to
9991925
Compare
|
Eh, curiously enough, something like the original problem re-surfaces if built with
|
|
Latest commit fixes the issue with |
|
By disabling |
|
FPGA testing done. riscv-rt is capable of running a led blinker on an Ibex-type RV32EMC 🥳 |
|
Looks good to me!! @hegza Should we leave it as WIP until you can test it further? |
|
I think it's up to you whether you can accept the incremental support for In time, I am likely to test some emc interrupts based on my fork at http://github.com/soc-hub-fi/pulpissimo-riscv/ which is a port of riscv-rt for Ibex. Ibex does not support direct-mode interrups so vectored must be the default. If there's anything minor regarding code style I'd like to address it. |
|
The main issue I see is that the official Rust toolchain does not support these targets yet, so it is not possible to keep a simple CI to check that we don't break anything in the future. |
|
Yeah I'd agree with that. I think it's a valid idea to wait for the official toolchain to catch up, then add the CI checks, then merge. |
hegza
force-pushed
the
rve
branch
7 times, most recently
from
983d9ae to
feebe40
Compare
As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE is to reduce the number of integer registers to 16 (x0-x15). This requires also a separate calling convention that seems a little underspecified. Somebody on the internet said these are also implied: - 2 callee saved registers instead of 12 - 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes This patch does the following: - Disable start of program load-to-zero for x16--x31 for RVE, since these do not exist on RVE - Force & assert the stack pointer is 4-byte aligned on RVE - Configure the trap handler to only caller-save a0--a5 and t0--t2 instead of a0--a7 and t0--t6 on RVE - Disable a6--a7 (x16--x17) and t3--t6 (x28--x31) for RVE in the TrapFrame struct, since these do not exist on RVE This may not be all that is required for RVE support, but this is at least the minimal amount of changes that makes riscv-rt link on RVE, allowing further testing.
The LLVM spurious error affects us too :)
I presume these are required if there happens to be any C or M instructions in the binary. At least the "rv32em" variant here is required for our rv32emc if -Fsingle-hart is disabled.
RVE does not support registers x16--x31, including t3 (x28). I replaced the use of t3 in the flash algorithm with a5 (x15) to make it compile.
BLUF
riscv-rtfails to link onriscv32emc. GCC complains about "mis-matched ISA string to merge 'i' and 'e'". This PR changes riscv-rt such that it does link onriscv32emc, by removing accesses to registers that don't exist on RVE.Contents
As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE is to reduce the number of integer registers to 16 (x0-x15). This requires also a separate calling convention that seems a little underspecified.
Somebody on the internet said these are also implied by the respective
ilp32ecalling convention:This PR does the following:
TrapFramestruct, since these do not exist on RVEWIP
The latest
riscv-rtmaster branch fails to compile whencodegen-units > 1in Cargo.toml'[profile.*].But I think that is unrelated to the issue at hand. Perhaps worthy of its own issue.
I think this patch might not be all that is required for RVE support, but this is at least the minimal amount of changes that makes riscv-rt link on RVE, allowing further testing.
FPGA testing pending. I won't be able to test the interrupts yet, but I should be able to confirm the runtime works otherwise.Done.Extra context
We're building an RV32EMC in the lab. It's not supported by latest Rust, so we're rolling our own toolchain https://github.com/soc-hub-fi/rust-rv32emc-docker 😃