rust-embedded / riscv

Low level access to RISC-V processors

RISC-V crates

This repository contains various crates useful for writing Rust programs on RISC-V microcontrollers:

• riscv: CPU registers access and intrinsics
• riscv-pac: Common traits to be implemented by RISC-V PACs
• riscv-peripheral: Interfaces for standard RISC-V peripherals
• riscv-rt: Startup code and interrupt handling
• riscv-semihosting: Semihosting for RISC-V processors

This project is developed and maintained by the RISC-V team.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Code of Conduct

Contribution to this crate is organized under the terms of the Rust Code of Conduct, the maintainer of this crate, the RISC-V team, promises to intervene to uphold that code of conduct.

riscv's Issues

`riscv-rt`: LLVM raises spurious errors in release mode for instructions of ISA extensions (e.g., M or E)

I found this problem first in daniestevez/galileo-osnma#23, but the following self-contained example replicates the problem: https://github.com/daniestevez/riscv/tree/debug-mul-build/riscv-rt/test-build

When this example is built with cargo build --release, I get the following:

   Compiling proc-macro2 v1.0.78
   Compiling unicode-ident v1.0.12
   Compiling syn v1.0.109
   Compiling riscv-rt v0.12.0 (/home/daniel/riscv/riscv-rt)
   Compiling riscv v0.11.0 (/home/daniel/riscv/riscv)
   Compiling embedded-hal v1.0.0
   Compiling critical-section v1.1.2
   Compiling test-build v0.1.0 (/home/daniel/riscv/riscv-rt/test-build)
   Compiling panic-halt v0.2.0
   Compiling quote v1.0.35
   Compiling riscv-rt-macros v0.2.1 (/home/daniel/riscv/riscv-rt/macros)
error: instruction requires the following: 'M' (Integer Multiplication and Division) or 'Zmmul' (Integer Multiplication)
mul t0, t2, t0
^
error: instruction requires the following: 'M' (Integer Multiplication and Division) or 'Zmmul' (Integer Multiplication)
mul t0, t2, t0
^
    Finished release [optimized] target(s) in 2.11s

Despite the error, an executable is produced.

If I build without --release instead, I get:

   Compiling proc-macro2 v1.0.78
   Compiling unicode-ident v1.0.12
   Compiling syn v1.0.109
   Compiling riscv-rt v0.12.0 (/home/daniel/riscv/riscv-rt)
   Compiling riscv v0.11.0 (/home/daniel/riscv/riscv)
   Compiling critical-section v1.1.2
   Compiling embedded-hal v1.0.0
   Compiling test-build v0.1.0 (/home/daniel/riscv/riscv-rt/test-build)
   Compiling panic-halt v0.2.0
   Compiling quote v1.0.35
   Compiling riscv-rt-macros v0.2.1 (/home/daniel/riscv/riscv-rt/macros)
    Finished dev [unoptimized + debuginfo] target(s) in 2.51s

Supervisor level ISA (Page system) support

RISC-V's privileged documents defined supervisor paging based virtual memory systems: Sv32, Sv39 and Sv48. Repository rcore-os/riscv raised one implementation example of these page sytems (may still need to be tailored). This is exteremely useful when developing an operating system for RISC-V cores. (An example of RISC-V OS is rcore with toturial here)

rust cross compile to riscv64gc

I want help, please.
(0)This is my rustc:
rustc 1.34.0 (91856ed52 2019-04-10)

(1) I have installed riscv64gc-unknown-none-elf.
`hyb:~/Rust/riscv64$ rustup show
Default host: x86_64-unknown-linux-gnu

installed targets for active toolchain

armv7-unknown-linux-gnueabihf
riscv64gc-unknown-none-elf
x86_64-unknown-linux-gnu

active toolchain

stable-x86_64-unknown-linux-gnu (default)
rustc 1.34.0 (91856ed52 2019-04-10)
`
(2) This is my ~/.cargo/config

[target.riscv64gc-unknown-none-elf] linker="riscv64-unknown-elf-gcc"

(3) Then, i run this command
cargo build --target=riscv64gc-unknown-none-elf

(4)But it shows this:
Compiling riscv64 v0.1.0 (/home/hyb/Rust/riscv64) error[E0463]: can't find crate for std| = note: theriscv64gc-unknown-none-elf` target may not be installed

error: aborting due to previous error

For more information about this error, try rustc --explain E0463.
error: Could not compile riscv64.

To learn more, run the command again with --verbose.
`
I want to know why? linker or std or rustc version?

`riscv-rt`: Machine + Supervisor mixed executable

As far as I understand the crates can be compiled with S-mode support, but in that case the assumption will be that it starts and always runs in S-mode.
Is the following use-case supported or any plans for it to be supported:

1. The execution starts in M-mode, certain M-only setup is done (like PMP config etc)
2. The privilege level drops to S-mode for a regular execution flow
3. ECALLs from S-mode are served in M-mode

Release time

It's been months of lots of changes, and I think it is time to pack a new release for all the crates in this workspace.

I would love to have #164 merged so we can make a release for all the crates at once. What do you think, @rust-embedded/riscv ?

If we are all OK with this, I'll set up a PR with proper version numbers and, once it is merge to master, I can publish the releases

linking with `rust-lld` failed: no memory region specified for section '.eh_frame', on Ubuntu 16 i686

I was trying to build some demo projects, by following this article.
Got these bugs:

$ rustup target add riscv32imac-unknown-none-elf
info: component 'rust-std' for target 'riscv32imac-unknown-none-elf' is up to date
~/Desktop/rust-sipeed-longan-nano-master$ rustup default nightly
info: using existing install for 'nightly-i686-unknown-linux-gnu'
info: default toolchain set to 'nightly-i686-unknown-linux-gnu'

nightly-i686-unknown-linux-gnu unchanged - rustc 1.49.0-nightly (1773f60ea 2020-11-08)

~/Desktop/rust-sipeed-longan-nano-master$ rustup target add riscv32imac-unknown-none-elf
info: component 'rust-std' for target 'riscv32imac-unknown-none-elf' is up to date
/Desktop/rust-sipeed-longan-nano-master$ rustup target add riscv32imac-unknown-none-elf
info: component 'rust-std' for target 'riscv32imac-unknown-none-elf' is up to date
oceanfish81@gollvm:/Desktop/rust-sipeed-longan-nano-master$ cargo --verbose build
Compiling r0 v0.2.2
Running rustc --crate-name r0 /home/oceanfish81/.cargo/registry/src/github.com-1285ae84e5963aae/r0-0.2.2/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=c85b5ab54aceb5f9 -C extra-filename=-c85b5ab54aceb5f9 --out-dir /home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps --target riscv32imac-unknown-none-elf -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/debug/deps --cap-lints allow -C link-arg=-Tlink.x
Compiling panic-abort v0.3.1
Running rustc --crate-name panic_abort /home/oceanfish81/.cargo/registry/src/github.com-1285ae84e5963aae/panic-abort-0.3.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=37322ac1e75fee7c -C extra-filename=-37322ac1e75fee7c --out-dir /home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps --target riscv32imac-unknown-none-elf -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/debug/deps --cap-lints allow -C link-arg=-Tlink.x
Compiling rust-sipeed-longan-nano v0.1.0 (/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master)
Running rustc --crate-name rust_sipeed_longan_nano --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=2df4b3c694b8dfb5 -C extra-filename=-2df4b3c694b8dfb5 --out-dir /home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps --target riscv32imac-unknown-none-elf -C incremental=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/incremental -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/debug/deps --extern panic_abort=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libpanic_abort-37322ac1e75fee7c.rlib --extern r0=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libr0-c85b5ab54aceb5f9.rlib -C link-arg=-Tlink.x
warning: unnecessary parentheses around assigned value
--> src/main.rs:8:25
|
8 | const rcu_apb2en: u32 = (0x4002_1000 + 0x18);
| ^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
|
= note: #[warn(unused_parens)] on by default

warning: unnecessary parentheses around assigned value
--> src/main.rs:10:25
|
10 | const gpioa_ctl0: u32 = (0x4001_0800 + 0x0);
| ^^^^^^^^^^^^^^^^^^^ help: remove these parentheses

warning: unnecessary parentheses around assigned value
--> src/main.rs:11:25
|
11 | const gpioa_data: u32 = (0x4001_0800 + 0xc);
| ^^^^^^^^^^^^^^^^^^^ help: remove these parentheses

warning: unused import: panic_abort
--> src/main.rs:13:5
|
13 | use panic_abort;
| ^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default

warning: constant rcu_apb2en should have an upper case name
--> src/main.rs:8:7
|
8 | const rcu_apb2en: u32 = (0x4002_1000 + 0x18);
| ^^^^^^^^^^ help: convert the identifier to upper case: RCU_APB2EN
|
= note: #[warn(non_upper_case_globals)] on by default

warning: constant gpioa_ctl0 should have an upper case name
--> src/main.rs:10:7
|
10 | const gpioa_ctl0: u32 = (0x4001_0800 + 0x0);
| ^^^^^^^^^^ help: convert the identifier to upper case: GPIOA_CTL0

warning: constant gpioa_data should have an upper case name
--> src/main.rs:11:7
|
11 | const gpioa_data: u32 = (0x4001_0800 + 0xc);
| ^^^^^^^^^^ help: convert the identifier to upper case: GPIOA_DATA

error: linking with rust-lld failed: exit code: 1
|
= note: "rust-lld" "-flavor" "gnu" "-L" "/home/oceanfish81/snap/rustup/common/rustup/toolchains/nightly-i686-unknown-linux-gnu/lib/rustlib/riscv32imac-unknown-none-elf/lib" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.19pbfx1e7ppiz22i.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.1gxn96a4ynn6krtc.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.1rrq47tcmo7r1d7q.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.2oywxm1qwyrau2j5.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.36wqpyrxaht0bqyw.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.4g879aqcx3v63xcn.rcgu.o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5.hpztk5fc5xtxkyj.rcgu.o" "-o" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/rust_sipeed_longan_nano-2df4b3c694b8dfb5" "--gc-sections" "-L" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps" "-L" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/debug/deps" "-L" "/home/oceanfish81/snap/rustup/common/rustup/toolchains/nightly-i686-unknown-linux-gnu/lib/rustlib/riscv32imac-unknown-none-elf/lib" "-Bstatic" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libr0-c85b5ab54aceb5f9.rlib" "--start-group" "/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libpanic_abort-37322ac1e75fee7c.rlib" "/home/oceanfish81/snap/rustup/common/rustup/toolchains/nightly-i686-unknown-linux-gnu/lib/rustlib/riscv32imac-unknown-none-elf/lib/librustc_std_workspace_core-1bd0d3673780d693.rlib" "/home/oceanfish81/snap/rustup/common/rustup/toolchains/nightly-i686-unknown-linux-gnu/lib/rustlib/riscv32imac-unknown-none-elf/lib/libcore-5aec724f1f867fb1.rlib" "--end-group" "/home/oceanfish81/snap/rustup/common/rustup/toolchains/nightly-i686-unknown-linux-gnu/lib/rustlib/riscv32imac-unknown-none-elf/lib/libcompiler_builtins-deaf2d068ddf18c0.rlib" "-Tlink.x" "-Bdynamic"
= note: rust-lld: error: no memory region specified for section '.eh_frame'

error: aborting due to previous error; 7 warnings emitted

error: could not compile rust-sipeed-longan-nano

Caused by:
process didn't exit successfully: rustc --crate-name rust_sipeed_longan_nano --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=2df4b3c694b8dfb5 -C extra-filename=-2df4b3c694b8dfb5 --out-dir /home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps --target riscv32imac-unknown-none-elf -C incremental=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/incremental -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps -L dependency=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/debug/deps --extern panic_abort=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libpanic_abort-37322ac1e75fee7c.rlib --extern r0=/home/oceanfish81/Desktop/rust-sipeed-longan-nano-master/target/riscv32imac-unknown-none-elf/debug/deps/libr0-c85b5ab54aceb5f9.rlib -C link-arg=-Tlink.x (exit code: 1)

`riscv-peripheral`: add standard peripherals

• PLIC
• (A)CLINT
• CLIC

`riscv-rt`: nightly builds fail with `single-hart` feature: linker needs `default_mp_hook` symbol

Looks now nightly now fails to compile single-hart examples, as _mp_hook is not defined and default_mp_hook is feature-gated. I guess we could just remove the feature gate, default_mp_hook is a very lightweight function.

How to use mcause::read()

I've got my Rust code reading the mcause register, but I cannot sprintln! because it doesn't have a core:fmt:binary trait. How do you match the the mcause contents to the trap enum to get a string?

Why are `asm::fence` and `asm::fence_i` unsafe?

I don't think they can result in any ill-defined states or UB, can they? (Unlike, say, cache invalidation of writeback caches.)

cc @dreiss

"cannot link object files with different floating-point ABI" rustc 1.56.0-nightly (2021-08-06)

It seems that the latest nightly build has the same issue as #69.

output:

  = note: rust-lld: error: /.../riscv64gc-unknown-none-elf/debug/deps/libriscv-c8056877110d3c7c.rlib(riscv.o): cannot link object files with different floating-point ABI

error: could not compile `project` due to previous error

rustup show:

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (overridden by '/home/o8/code/poctx/rust-toolchain')
rustc 1.56.0-nightly (5ad7389bd 2021-08-06)

`riscv-rt`: Can you have two versions in the build tree at the same time?

Is it possible to use two different 0.x versions of riscv-rt together in the same dependency tree at the same time? My guess was no, because of the linker scripts.

Would it make sense to specify the links field in the cargo.toml to indicate this?

The MTIP bit in mip register is read-only

In the riscv-privileged manual, it is said that "The MTIP bit (in mip) is read-only and is cleared by writing to the memory-mapped machine-mode timer compare register."
But in the riscv crate, there is an interface like this:

use riscv::register::mip;
use riscv_rt::entry;

#[entry]  
fn main() {
    mip::set_mtimer();
}

We can write the code mip::set_mtimer() to set the 7th bit, the MTIP bit, of the mip register, which does not permitted in riscv-privileged manual.
Is there some reason for the existence of mip::set_mtimer()? If not, I suggest remove it.
Thanks.

Failure to build due to unreachable code

I can't build this crate - I get an error (because all warnings are treated as errors) that there is unreachable code. Am I using the wrong version of something, perhaps?

jakobw@ubuntu:~/riscv/riscv$ xargo build --verbose
+ "rustc" "--print" "sysroot"
+ RUSTFLAGS="--sysroot /home/jakobw/riscv/riscv-rust-toolchain/build/xargo/HOST"
+ "cargo" "build" "--verbose"
   Compiling bare-metal v0.1.1
     Running `rustc --crate-name bare_metal /home/jakobw/riscv/riscv-rust-toolchain/build/cargo/registry/src/github.com-1ecc6299db9ec823/bare-metal-0.1.1/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=accd5f10bbaec4a8 -C extra-filename=-accd5f10bbaec4a8 --out-dir /home/jakobw/riscv/riscv/target/debug/deps -L dependency=/home/jakobw/riscv/riscv/target/debug/deps --cap-lints allow --sysroot /home/jakobw/riscv/riscv-rust-toolchain/build/xargo/HOST`
   Compiling riscv v0.1.4 (file:///home/jakobw/riscv/riscv)
     Running `rustc --crate-name riscv src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=2042a6c9fb86ef8e -C extra-filename=-2042a6c9fb86ef8e --out-dir /home/jakobw/riscv/riscv/target/debug/deps -L dependency=/home/jakobw/riscv/riscv/target/debug/deps --extern bare_metal=/home/jakobw/riscv/riscv/target/debug/deps/libbare_metal-accd5f10bbaec4a8.rlib --sysroot /home/jakobw/riscv/riscv-rust-toolchain/build/xargo/HOST`
error: unreachable expression
  --> src/register/misa.rs:30:9
   |
30 | /         match value {
31 | |             1 => MXL::XLEN32,
32 | |             2 => MXL::XLEN64,
33 | |             3 => MXL::XLEN128,
34 | |             _ => unreachable!(),
35 | |         }
   | |_________^
   |
note: lint level defined here
  --> src/lib.rs:10:9
   |
10 | #![deny(warnings)]
   |         ^^^^^^^^
   = note: #[deny(unreachable_code)] implied by #[deny(warnings)]

error: aborting due to previous error

error: Could not compile `riscv`.

Caused by:
  process didn't exit successfully: `rustc --crate-name riscv src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=2042a6c9fb86ef8e -C extra-filename=-2042a6c9fb86ef8e --out-dir /home/jakobw/riscv/riscv/target/debug/deps -L dependency=/home/jakobw/riscv/riscv/target/debug/deps --extern bare_metal=/home/jakobw/riscv/riscv/target/debug/deps/libbare_metal-accd5f10bbaec4a8.rlib --sysroot /home/jakobw/riscv/riscv-rust-toolchain/build/xargo/HOST` (exit code: 101)

Set Stack Pointer and Return Address

I don't see anything in this crate for setting the stack pointer(x2) or return address(x1). This is required to enter into a lower privilege level (user mode) within a defined memory stack. The assembly should be a simple move instruction. Finally an MRET instruction would be called to enter user mode. I noticed that the MRET instruction was available in this crate in v0.2.0. Is there another way to call it now? Why was it removed?

`riscv-rt`: Using this as a library?

Is it possible to use this as a "just works" library without extra copying/config or is it meant to be used as a template?

move plic definition to riscv crate

Support for riscv32imc.

Hi,
compiling for Xtensa ESP32-C3 result in an error for a missing file:

Caused by:
  process didn't exit successfully: `target/debug/build/riscv-340f5de0c5d11624/build-script-build` (exit status: 101)
   --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /riscv-0.7.0/build.rs:23:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If I modify the code to print out the name of the missing file it says it is the bin/riscv32imc-esp-espidf.a.
In the bin/ folder a binary for riscv32imc is missing.
If I copy the riscv32ic.a to riscv32imc.a the program compiles successfully and it seems to work.

Massimo.

Implementing PMP registers as an array?

Is it a good idea to implement a group of registers as an array or other structure that allows index access?

Useful Scenario:

 impl Region {
     fn to_napot(&self) -> usize {
         if self.size <= 2 {
            self.addr
         } else {
             /*1...11111011111...1*/
             let mask = !(1 << (self.size - 2)); ‣mask: usize
             let mask = (mask << (XLEN-self.size+1)) >> (XLEN-self.size+1);
             self.addr | mask
         }
     }
     fn to_tor(&self) -> (usize, usize) {
         (self.addr, self.addr + self.size)
     }
     // Here we want to access pmp registers by index.
     fn enforce(&self, number: usize) {
         // pmpcfg[number].write(config)
     }
 }

 pub struct MemoryLayout {
     /* at most 16 pmp region is allowed */
     regions: [Region; 16]
 }

Or is there a way to access these register through a i:usize -> pmpcfgi process?
I'm not sure if macro can do this.

RISCV sdk with RUST support

Hello everyone,am trying to build SDK for RISC-V which supports RUST lang,so i can cross compile a file from my x86-linux-machine to RISC-V board(). Am a Newbie,can i get some help please??? i tried to add rust binary and trying to build SDK with rust support. but i couldn't accomplish it.

My goal is to cross-compile a rust file from x86-linux-Machine to RISC-V board. i already have SDK built for RISC-V sources,is it possible to add RUST support to it?

`riscv`: Add missing CSR's

• mpu
• mdelet /mideleg
• perf counters
• senvcfg
• scontext
• mconfigptr
• mtinst
• mtval2
• Machine Configuration registers
• Machine Non-Maskable Interrupt Handling registers
• Machine Counter Setup registers
• Machine Debug/Trace registers
• Machine Dabug Mode registers

`riscv-rt`: Prune unused symbols

I'm trying to optimize my binary size. For this, I override all default functions that I don't need with stubs. However, most of these symbols are still present in my binary. Is there a way to get rid of them?

As far as I can tell, using weak symbols could resolve this, but I don't know much about linking. (Incomplete) list of symbols that I'd like to get rid of:

• __wfi
• __read_mhartid
• __read_mcause
• default_mp_hook
• DefaultExceptionHandler
• DefaultInterruptHandler
• default_setup_interrupts
• default_start_trap

"cannot link object files with different floating-point ABI" (nightly-2021-03-23)

riscv and riscv-rt crates cause a linker error when building with a recent nightly compiler for a hard-float target.

git clone https://github.com/riscv-rust/k210-crates.git --recursive
cd k210-crates
cd k210-example
sed -i .bak -e 's/riscv64imac/riscv64gc/g' .cargo/config
cargo +nightly-2021-03-23 build --release

Output:

error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" [...]
  = note: rust-lld: error: [redacted]/target/riscv64gc-unknown-none-elf/release/deps/libriscv-3f21992281a58781.rlib(riscv.o): cannot link object files with different floating-point ABI
          rust-lld: error: [redacted]/target/riscv64gc-unknown-none-elf/release/deps/libriscv_rt-db1e8f195a4770c0.rlib(riscv-rt.o): cannot link object files with different floating-point ABI


error: aborting due to previous error

error: could not compile `k210-example`

To learn more, run the command again with --verbose.

It appears that this started happening somewhere between nightly-2021-03-10 and nightly-2021-03-23 (inclusive).

• 1.50.0: ok
• nightly-2021-02-19: ok
• nightly-2021-02-23: ok
• nightly-2021-03-09: ok
• nightly-2021-03-23: fail

Replace bors with GitHub merge queues

As mentioned in the WG repository, bors is about to stop working. The embedded WG suggested migrating to GitHub merge queues, and this repo could be an excellent candidate to test how this works.

#132 already updates the current CI workflows and is ready to support merge queues. However, we still need to activate the branch protection rule on the repo and, if everything goes well, remove bors. @rust-embedded/riscv are you OK with this?

Mcounteren Missing

I find it strange that the hpmcounterx registers and time register is implemented but not the mcounteren register. You cannot use the hpmcounters, time, cycle, or instret without enabling them first in mcounteren. I probably could submit a pull request for this if needed.

Why are bare-metal and embedded-hal dependencies of this crate?

Hi!

I'm pretty new to embedded Rust, and I wonder why bare-metal and embedded-hal are dependencies of the riscv crate. I searched for code usages throughout the repo and there is none.

Thanks in advance!

tag the 0.9.0 release

Hey there,

on crates.io, there is a version 0.9.0, and 0.8.1 had been yanked. However, there is no 0.9.0 tag here; could you please tag the corresponding commit? Thanks! :)

`riscv`: All the CSR write operations should be unsafe by default

In general we should assume that writing to CSRs could do something that potentially violates the Rust abstract model.

Macros like write_csr_as and write_csr_as_usize should at least default to unsafe, and maybe have an option to make a safe variant on a CSR by CSR basis.

The `critical_section` implementation is wrong

These two lines is not atomic and will cause problems

riscv/src/critical_section.rs

Lines 11 to 13 in d9c6076

	let was_active = mstatus::read().mie();
	interrupt::disable();
	was_active

and could be replaced by a single csr instruction:

let mut mstatus: usize;
asm!("csrrci {}, 0x300, 0b100", out(reg) mstatus);
core::mem::transmute::<_, Mstatus>(mstatus).mie()

which prevents from being interrupted between reading status and disabling interrupt.

`riscv-rt`: Broken eh_frame relocations on QEMU

Demo repo: https://github.com/dreiss/panic_repro . It's a fairly simple riscv-rt example targeting riscv64 on qemu.

On "rustc 1.78.0-nightly (a84bb95a1 2024-02-13)" or later, the link fails with bad relocations in eh_records:

  = note: rust-lld: error: <internal>:(.eh_frame+0x1c): relocation R_RISCV_32_PCREL out of range: 2147489994 is not in [-2147483648, 2147483647]; references ''
          >>> defined in /home/dreiss/.rustup/toolchains/nightly-2024-02-14-x86_64-unknown-linux-gnu/lib/rustlib/riscv64gc-unknown-none-elf/lib/libcore-2678f83f395a7a3f.rlib(core-2678f83f395a7a3f.core.c4f53ede227ad4d2-cgu.0.rcgu.o)
          
          rust-lld: error: <internal>:(.eh_frame+0x30): relocation R_RISCV_32_PCREL out of range: 2147489980 is not in [-2147483648, 2147483647]; references ''
          >>> defined in /home/dreiss/.rustup/toolchains/nightly-2024-02-14-x86_64-unknown-linux-gnu/lib/rustlib/riscv64gc-unknown-none-elf/lib/libcore-2678f83f395a7a3f.rlib(core-2678f83f395a7a3f.core.c4f53ede227ad4d2-cgu.0.rcgu.o)

...
          rust-lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)

On "rustc 1.78.0-nightly (b381d3ab2 2024-02-12)" or newer, the link succeeds, and debug_frame records for functions in my code are fine, but eh_frame records for functions in libcore are pointing to addresses around 0xffffffff8000ABCD (confirmed with objdump -WFL and llvm-readelf --unwind). This prevents gdb from backtracing up through libcore functions in some cases.

I think the problem is that riscv-rt's linker script is marking the eh_frame section as "(INFO)", which makes it non-allocatable, which puts it at a logical address of 0. Which means any from it to the code (of which there are, of course, many) are (potentially) longer than 2GB, which is not allowed. The new rustc correctly fails. The old one (which is also an older llvm) messes up the relocation due to overflow.

Making eh_frame not defined as "(INFO)" should fix this, but then it will be included in the output binary, which is not ideal for small targets. If unwinding data is not going to be used at runtime, it's probably best to use debug_frame instead of eh_frame, but that cannot be controlled for libcore unless it's being built from source.

`riscv-rt`: Duplicate symbol when linking with Newlib

Hi, I am trying to use a C library that depends on Newlib with rust. This code block seems to generate the abort symbol, but this collides with the libc abort() symbol. Is it possible for the riscv-rt crate to change the name of the symbol to something else?

riscv/riscv-rt/src/asm.rs

Lines 337 to 343 in 27c4faf

	#[rustfmt::skip]
	global_asm!(
	".section .text.abort
	.global abort
	abort: // make sure there is an abort symbol when linking
	j abort"
	);

`riscv-rt`: link.x expected filename pattern

Hi. I'm trying out and mess around with a litex RISC-V CPU. So Im trying to create a demo app in rust that will be later flashed to my board. However, I'm getting this error when cargo building:

[roby@thonkpad app]$ cargo build
   Compiling app v0.1.0 (/home/roby/repos/colorlight-litex-rs/app)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/roby/.vscode/extensions/ms-python.python-2024.4.1/python_files/deactivate/bash:/home/roby/litex/.venv/bin:/home/roby/.vscode/extensions/ms-python.python-2024.4.1/python_files/deactivate/bash:/home/roby/litex/.venv/bin:/home/roby/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/roby/.local/bin:/home/roby/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14/bin/:/home/roby/.local/bin:/home/roby/repos/colorlight-litex-rs/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14/bin/:/home/roby/.local/bin:/home/roby/repos/colorlight-litex-rs/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14/bin/" VSLANG="1033" "rust-lld" "-flavor" "gnu" "/tmp/rustcziagb6/symbols.o" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/app-7b229434c01f8ea5.2tzlhb4lit7ddpd9.rcgu.o" "--as-needed" "-L" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps" "-L" "/home/roby/repos/colorlight-litex-rs/app/target/debug/deps" "-L" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/build/app-8f27186d541e7cc6/out" "-L" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/build/riscv-rt-9b96f2b2dc0c7448/out" "-L" "/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/riscv32i-unknown-none-elf/lib" "-Bstatic" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libriscv_rt-9c044b5575e5e546.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libriscv-73d19da890c4304a.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libembedded_hal-e36c771db9ca8996.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libvoid-ef31d3fb669da9af.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libnb-23280c6da62f7b03.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libnb-83c738390839f5f7.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libbit_field-7fe39e5de6944229.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libbare_metal-e76b1860b26e0b8f.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libr0-88cc9144b6b3efba.rlib" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/libpanic_halt-0a692546002e3952.rlib" "/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/riscv32i-unknown-none-elf/lib/librustc_std_workspace_core-9f69ce70624d65cd.rlib" "/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/riscv32i-unknown-none-elf/lib/libcore-1a2ac84839ac4606.rlib" "/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/riscv32i-unknown-none-elf/lib/libcompiler_builtins-5b7e64a4538a2719.rlib" "-Bdynamic" "-z" "noexecstack" "-L" "/home/roby/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/riscv32i-unknown-none-elf/lib" "-o" "/home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/deps/app-7b229434c01f8ea5" "--gc-sections" "-Tmemory.x" "-Tlink.x"
  = note: rust-lld: error: /home/roby/repos/colorlight-litex-rs/app/target/riscv32i-unknown-none-elf/debug/build/riscv-rt-9b96f2b2dc0c7448/out/link.x:58: expected filename pattern
          >>>     (*(.trap));
          >>>     ^
          

error: could not compile `app` (bin "app") due to 1 previous error

Cargo.toml

[dependencies]
riscv-rt = "0.9.0"
panic-halt = "0.2.0"
litex-pac = { path = "../litex-pac" }

main.rs

#![no_std]
#![no_main]

extern crate panic_halt;

use riscv_rt::entry;

#[entry]
fn main() -> ! {
    loop { }
}

.cargo/config

[target.riscv32i-unknown-none-elf]
rustflags = [
  "-C", "link-arg=-Tmemory.x",
  "-C", "link-arg=-Tlink.x",
]

[build]
target = "riscv32i-unknown-none-elf"

build.rs

use std::env;
use std::fs;
use std::path::PathBuf;

fn main() {
    let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());

    // Put the linker script somewhere the linker can find it.
    fs::write(out_dir.join("memory.x"), include_bytes!("memory.x")).unwrap();
    println!("cargo:rustc-link-search={}", out_dir.display());
    println!("cargo:rerun-if-changed=memory.x");
    println!("cargo:rerun-if-changed=build.rs");
}

rustup version

[roby@thonkpad app]$ rustup -V
rustup 1.27.0 (bbb9276d2 2024-03-08)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.77.0 (aedd173a2 2024-03-17)`

Can I provide anything more in order to get help?
Thank you

`riscv-rt`: Pre initialization trap handling

At the moment, the trap handler is initialized rather late in the boot procedure (it is more or less the last thing to happen before jumping to main). However, traps may happen before this, and they will not be handled appropriately (as far as I can tell, my CPU lands in a reset loop).

The most prominent situation in which this may happen is when I accidentally run the software compiled with multiplication instructions on a machine without them, because of these lines: https://github.com/rust-embedded/riscv-rt/blob/master/asm.S#L99-L110

I see multiple different approaches to improve the current situation:

• Simply hardcode the non-mul branch in the asm.S. Since the factor against we are multiplying is rather low (it's the number of harts of the machine), the run time overhead shouldn't hit that hard.
• Going one step further, I suggest compiling asm.S for the rv32i and rv64i targets only. Most of these extensions aren't needed anyways during initialization.
• Alternatively, define a pre-Rust trap handler which is initialized first in _start. Once the Rust runtime is ready, default_setup_interrupts will override it to the actual implementation.

`riscv-rt`: Implement FPU initialization

`riscv-rt`: Linker relocation issue (QEMU / OpenSBI)

I am experimenting with the RISC-V ISA via QEMU emulation, and I am having trouble figuring out how to link in the _heap_size symbol appropriately, so that I can follow through with heap allocation. I followed the riscv-rt documentation closely. I am attempting to use QEMU with OpenSBI, but I am not experienced with linker configuration. Here is my memory layout specification:

MEMORY
{
    RAM : ORIGIN = 0x80200000, LENGTH = 0x8000000
    FLASH : ORIGIN = 0x20000000, LENGTH = 16M
}

REGION_ALIAS("REGION_TEXT", RAM);
REGION_ALIAS("REGION_RODATA", RAM);
REGION_ALIAS("REGION_DATA", RAM);
REGION_ALIAS("REGION_BSS", RAM);
REGION_ALIAS("REGION_HEAP", RAM);
REGION_ALIAS("REGION_STACK", RAM);

I understand that to mean that there is 16M of reserved flash memory at the beginning of the address space (OpenSBI), followed by RAM address space. I would expect all of the memory regions to fit within RAM since the FLASH space is reserved by QEMU OpenSBI firmware.

I have the following example program:

#![no_std]
#![no_main]

extern crate panic_halt;

mod uart;
mod print;

use riscv_rt::entry;

use uart::Uart;

extern "C" {
    static _heap_size: u8;
}

#[entry]
fn __start() -> ! {
    let heap_size = unsafe { &_heap_size as *const u8 as usize };
    println!("hello world");
    println!("heap size = {}", heap_size);
    loop {}
}

The problem is that the linker cannot relocate _heap_size provided by riscv-rt and I do not understand why. I tried changing the code model to medium:

relocation R_RISCV_PCREL_HI20 out of range: -524800 is not in [-524288, 524287]; references _heap_size

Raw instruction functions are unsafe footguns

Except wfi, they are effectively impossible to use safely: Rust can move values arbitrarily between registers (or memory!) behind the scenes, so conforming to an ABI is impossible; to do so, one would need to specify the argument and return registers in the asm block itself.

I vote to merely delete these functions (again, except wfi).

See also #10

`riscv-rt`: Assembly algorithm for RAM init incompatible with upcoming RVE extension (future proofing)

The RAM init function is incompatible with (as of yet, unratified) RV32E base ISA.

riscv/riscv-rt/src/asm.rs

Lines 147 to 158 in f5a2da9

	// Copy .data from flash to RAM
	la t0, _sdata
	la t2, _edata
	la t1, _sidata
	bgeu t0, t2, 2f
	1: ",
	#[cfg(target_arch = "riscv32")]
	"lw t3, 0(t1)
	addi t1, t1, 4
	sw t3, 0(t0)
	addi t0, t0, 4
	bltu t0, t2, 1b",

The algorithm uses temporaries t0--t3 to copy data from from flash to RAM. However, the RV32E removes registers x16--x31, which includes t3 / x28, therefore making this algorithm unavailable on RVE.

Proposals for a solution

1. We could pick another register in range x0--x16 in place of t3 to make the code compatible between RVI and RVE
2. We could #[cfg(riscve)] the algorithm to use another register on RV32E.

create a release for the atomicity things

Could you please tag another release? We would like to bump d1-pac in oreboot, which depends on critical sections.

See also:
oreboot/oreboot#635
duskmoon314/aw-pac#18

RFC: Platform-specific exception codes

Are there any plans to provide support for platform specific extensions in riscv crate?
Reading through RISC-V Privileged Architectures specification I see that there are cases where, for example, a 3.1.15 Machine Cause Register has exception codes allocated for platform and custom use.

Was wondering if it would be possible to extend enums Interrupt and Exception from outside of the riscv crate itself.
The best I could came up thus far is adding "PlatformSpecific1-32" fields to Interrupt and creating a user-defined enum PlatformInterrupt with conversion between (TryFrom<Interrupt> for PlaftormInterrupt) where applicable. (same goes for Exception)

`riscv`: Support more fence variants

The default fence instruction with no parameters is the strongest form of barrier. But it also takes an optional set of flags to give fine-grained control over exactly what operations the fence is a barrier for, and in which direction.

I see two design choices here:

• just let the caller specify an arbitrary set of flags (somehow), or
• have a set of canned variants for the common cases (like Linux's rmb/wmb/...)

(These aren't exclusive of course.)

Thoughts?

cc @dreiss

`sip` register set / clear functions

There are many functions for the sie register to set and clear bits but nothing for the sip register which can only be read
I don't know why but it would be super useful (for example if you want to clear the STIP bit to acknowledge a supervisor timer interrupt

RVXXI registers

Is there a reason why RVXXI registers are not available? If this is just an issue of implementing it, I will gladly do it

FCSR operations generally cannot be used from Rust

This crate seems to provide operations that can change the floating-point rounding mode and read the accrued exceptions flags. These operations generally cannot be used soundly from Rust; see rust-lang/stdarch#1478 for more explanation.

It would be good to clarify in the documentation when and how exactly these functions are meant to be used. As things stand, calling set_rounding_mode() will be immediate UB in almost all contexts, and read().fflags() will return an unreliable value.

`riscv`: align assembly functions with `cortex-m` crate

Motivated by #179 (and #180), I took a look on how the cortex-m crate deals with assembly instructions, and most of them are safe and use options to avoid the compiler from using the stack etc.

@rust-embedded/riscv what do you think about updating our assembly functions to follow the same fashion as in cortex-m? @rust-embedded/cortex-m any advice on this?

`riscv`: Linking fails when using this crate as a dependency

I'm attempting to compile a rust crate using this library (targeting a bare-metal build on rv32imac), and I get this error during the linking step:

ld: error: target/riscv32imac-unknown-none-elf/debug/libcrate.a(riscv.o): conflicting priv spec version (major/minor/revision).
ld: error: target/riscv32imac-unknown-none-elf/debug/libcrate.a(riscv.o): conflicting priv spec version (major/minor/revision).
ld: failed to merge target specific data of file target/riscv32imac-unknown-none-elf/debug/libcrate.a(riscv.o)

This error is caused by this crate specifically, which I know because it only started when I imported this crate, and I can build fine with other crates linked in, it is specifically this crate as a dependency that causes this error to appear. Is this behavior something known about? I can't seem to find anything helpful in online search results for this error message.

`riscv`: Pub macros for non-standard CSRs

I'm using Rust on a RISC-V processor that includes some non-standard CSRs. It would be nice if the macros this crate uses to define CSR functions were exported so I could use them to define my own CSR functions.

`riscv`: `interrupt::free()` for Supervisor Mode

I've noticed that there is no equivalent for interrupt::free() for S mode, and I think it is worth adding to this crate. I see two options:

1. Add a new function
2. Put it under a cfg

Are there any opinions on which way to go with this?

`riscv-rt`: Implement support for hardware interrupt dispatching

Currently there is a single interrupt entry point. RISCV CPU's also have a hardware dispatching mode.