131: fix a typo r=romancardenas a=OccupyMars2025



Co-authored-by: OccupyMars2025 <31559413+OccupyMars2025@users.noreply.github.com>

127: Add FENCE.I instruction r=almindor a=rmsyn



Co-authored-by: rmsyn <rmsynchls@gmail.com>

128: Add FENCE instruction r=almindor a=rmsyn



Co-authored-by: rmsyn <rmsynchls@gmail.com>

123: Added clippy to the CI workflow r=almindor a=romancardenas

I've been working with this crate for a while and noticed that it didn't include clippy as part of the CI process. This PR checks that clippy does not trigger any warning for new contributions. I also ran `cargo clippy --fix` to "fix" the crate.

If you think this is useful, I can adapt other repos (e.g., riscv-rt or e310x). Cheers!

Co-authored-by: Román Cárdenas <rcardenas.rod@gmail.com>

122: release v0.10.1 with critical section bug r=dkhayes117 a=almindor

Release the critical section bugfix from #121 

Co-authored-by: Ales Katona <ales@katona.me>

121: fix critial section implementation r=dkhayes117 a=tfx2001

It should be `0b1000` rather than `0b100`. `Bit 2` is a reserved bit, and `Bit 3` is `MIE` that needs to be cleared.

![image](https://user-images.githubusercontent.com/19427212/212855746-7df197f1-5582-4844-a58e-6c7269d03b22.png

)


Co-authored-by: tfx2001 <tfx2001@outlook.com>

120: release v0.10.0 r=almindor a=almindor

Fixed #119 

Co-authored-by: Ales Katona <ales@katona.me>

117: fix atomicity of critical section, fixes #116 r=dkhayes117 a=almindor

This changes `SingleHartCriticalSection::acquire` to be done in an atomic way.

Fixes #116

NOTE: no changelog since it fixes a small bug on unreleased change

Co-authored-by: Ales Katona <ales@katona.me>

110: Add critical-section 1.0 implementation, fix multicore unsoundness. r=almindor a=Dirbaio

~~Requires #109~~

This adds a [critical-section](https://github.com/rust-embedded/critical-section) implementation for single-core chips, based on disabling all interrupts.

`interrupt::free` is is unsound on multicore systems because it only disables interrupts in the
current core. For multicore chips, a chip-specific critical section implementationis needed instead. Unsoundness is fixed by not returning the `CriticalSection` token.

This is a breaking change.

This is the riscv equivalent of https://github.com/rust-embedded/cortex-m/pull/447 and https://github.com/rust-embedded/cortex-m/pull/448





Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

This is unsound on multi-hart because it only disables interrupts in the
current hart. For multi-hart chips, a chip-specific critical section implementation
is needed instead.

Unsoundness is fixed by not returning the `CriticalSection` token.

This is a breaking change.

113: bump version to v0.9.0 due to breaking changes r=Disasm a=almindor

As per discussion on https://github.com/rust-embedded/riscv/pull/112

 we want to release `v0.9.0` and yank `v0.8.1` since the removals were a breaking change.

Co-authored-by: Ales Katona <ales@katona.me>

112: Propose to release a version `riscv` v0.8.1 r=almindor a=luojia65

The `riscv` crate includes an important fix (https://github.com/rust-embedded/riscv/pull/107

) where the RustSBI community would leverage the use of. However, the latest release v0.8.0 did not include this fix. In this pull request we want to propose to release a new version of `riscv` crate to include at least this fix, so that RustSBI community would write correct implemenations based on this crate.

Notes to `CHANGELOG.md`: the release date `2022-10-06` can always be changed.

r? `@Disasm` 

Co-authored-by: luojia65 <me@luojia.cc>

109: Update to edition 2021. r=Disasm a=Dirbaio

This shouldn't be a breaking change since Edition 2021 came out in
Rust 1.56, and MSRV is already higher than that (Rust 1.59)

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>

This shouldn't be a breaking change since Edition 2021 came out in
Rust 1.56, and MSRV is already higher than that (Rust 1.59)

108: fix: clearify that mip.{MSIP, MTIP} are read-only r=almindor a=luojia65

closes #62

In RISC-V privileged specification, it says:

> Bits mip.MTIP and mie.MTIE are the interrupt-pending and interrupt-enable bits for machine timer interrupts. MTIP is read-only in mip, and is cleared by writing to the memory-mapped machine-mode timer compare register.
>
> Bits mip.MSIP and mie.MSIE are the interrupt-pending and interrupt-enable bits for machine-level software interrupts. MSIP is read-only in mip, and is written by accesses to memory-mapped control registers, which are used by remote harts to provide machine-level interprocessor interrupts.

indicated by the specification, mip.MSIP and mip.MTIP bits are read-only. This pull request clearifies this by removing {set, clear}_{msoft, mtimer} functions from mip module of riscv crate.

Co-authored-by: luojia65 <me@luojia.cc>

closes #62

107: fix reading marchid and mimpid r=Disasm a=orangecms

It seems to have been a copy-paste error.
We ran into a very nasty bug in oreboot on the Allwinner D1 (C906) where
an errata patch in Linux relies on those two being zero.

Signed-off-by: Daniel Maslowski <info@orangecms.org>

Co-authored-by: Daniel Maslowski <info@orangecms.org>

It seems to have been a copy-paste error.
We ran into a very nasty bug in oreboot on the Allwinner D1 (C906) where
an errata patch in Linux relies on those two being zero.

Signed-off-by: Daniel Maslowski <info@orangecms.org>

105: Add extra documentation for `delay` r=almindor a=Joeyh021

Took me a minute or two to figure out what value exactly to pass to `McycleDelay::new`, so figured I'd make a quick PR to add a note for anyone else that hits the same confusion as I did. Also added a doc line for the `delay` module while I was at it, as it was missing one.

Co-authored-by: Joey Harrison <joeyh021@icloud.com>