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>

104: Fix asm::delay not clobbering count register r=dkhayes117 a=adamgreig

I noticed that a small example using two `asm::delay()` calls worked fine in debug mode but not in release mode. Eventually `@jamesmunns` spotted that the count register wasn't being reloaded between calls:

```
    # loads a2 with real_cyc
    400001ce:	02faf637          lui	a2,0x2faf
    400001d2:	0816061b          addiw	a2,a2,129
    # turn on led
    400001d6:	c10c              sw	a1,0(a0)
    # count down (delay impl)
    400001d8:	167d              addi	a2,a2,-1
    400001da:	fe7d              bnez	a2,400001d8 <.LBB0_8+0x30>
    # turn off led
    400001dc:	00052023          sw	zero,0(a0) # 2000000 <.Lline_table_start0+0x1fff7a4>
    # count down again (delay impl, note a2 not reloaded)
    400001e0:	167d              addi	a2,a2,-1
    400001e2:	fe7d              bnez	a2,400001e0 <.LBB0_8+0x38>
    # loop back to start
    400001e4:	bfcd              j	400001d6 <.LBB0_8+0x2e>
```

By changing the register spec to `inout`, Rust knows the register is modified and reloads it next time. I added the nomem and nostack options too since the instructions don't touch memory or stack, to match the cortex-m impl. This change fixes codegen for my example:


```
    400001ce:	02faf637          lui	a2,0x2faf
    400001d2:	0816061b          addiw	a2,a2,129
    400001d6:	c10c              sw	a1,0(a0)
    400001d8:	86b2              mv	a3,a2
    400001da:	16fd              addi	a3,a3,-1
    400001dc:	fefd              bnez	a3,400001da <.LBB0_8+0x32>
    400001de:	00052023          sw	zero,0(a0) # 2000000 <.Lline_table_start0+0x1fff779>
    400001e2:	86b2              mv	a3,a2
    400001e4:	16fd              addi	a3,a3,-1
    400001e6:	fefd              bnez	a3,400001e4 <.LBB0_8+0x3c>
    400001e8:	b7fd              j	400001d6 <.LBB0_8+0x2e>

```

Co-authored-by: Adam Greig <adam@adamgreig.com>

103: Fix release year in changelog r=almindor a=Disasm



Co-authored-by: Vadim Kaushan <admin@disasm.info>

102: Prepare v0.8.0 release r=almindor a=Disasm



Co-authored-by: Vadim Kaushan <admin@disasm.info>