Adds DCSR.MPRVEN bit support, as specified in RISC-V External Debug Support Version 1.0.0-rc4
(https://github.com/riscv/riscv-debug-spec/releases/tag/1.0.0-rc4, see 4.9.1 Debug Control and Status).
This bit allows to enable hardware virtual address translation when memory access
is initiated by the debugger (see 4.1 Debug Mode, clause 2).
This change:
* Increases debug specification coverage, allows more detailed testing of external debuggers with Spike.
* Decreases the number of required abstract commands to read virtual memory thus improving the user experience.
Commit's changes:
* Added MPRVEN field to DCSR register
* Updated debug_rom.S to turn off MPRVEN on memory access
To avoid unwanted address translation while debug_rom.S executed
DCSR.MPRVEN bit has to be cleared before and restored after access.
Signed-off-by: Farid Khaydari <f.khaydari@syntacore.com>
The macro require_vsm4_constraints defines EGS once again (shadowing
the definition of this constant, since it introduces a new scope). This
renders the original definition as "unused", causing warning during
compilation.
The implementation of SMAIA and SSAIA extensions incurs
a significant performance penalty.
Better check whether EXT_SSAIA is enabled before accessing the
considered CSR's
Cf.
commit # ddc025a80d
commit # a6708d5588
Since 92e4f02 moved logging logic into store_slow_path function it has
been logging stores even if actually_store parameter is false. Because
of that logging is broken for all atomic instructions. Function "amo" calls
store_slow_path with nullptr argument and actually_store equal to false
while callee uses reg_from_bytes independently from actually_store value
All of that causes dereferencing of nullptr. This commit logs memory
access only if it actually happened
Previously cache block size had to be initialized via special
set_chache_blocksz setter function and was uninitialized if you didn't
call it. In this commit I move initialization of the block size to the
mmu_t's constructor. The configuration of this member goes through cfg_t
struct.
These are the changes:
- Zvkg (vghsh.vv, vgmul.vv)
- vl must be a multiple of EGS=4. (spec p.13)
- Check alignment of vd, vs1, vs2 with lmul
- Zvksh (vsm3c.vi, vsm3me.vv)
- vstart, vl must be multiple of EGS=4 (spec p.17)
- Check alignment of vd, vs1, vs2 with lmul
- Zvksed (vsm4k.[vi,vs,vv])
- vstart, vl must be multiple of EGS=4 (spec p.16)
- Check alignment of vd, vs1, vs2 with lmul
- For vsm4r.vs, check overlap between vs2 and vd (spec p.7)
- Zvbb (vwsll.[vv,vx,vi])
- Check alignment of vd, vs1, vs2 with lmul (for widening instructions)
- Check overlap between vs2 and vd
- Zvkned
- vstart, vl must be multiple of EGS=4 (spec p.14)
- Check alignment of vd, vs1, vs2 with lmul
- For vaes*.vs, check overlap between vs2 and vd (spec p.7)
- Zvknh
- Check alignment of vd, vs1, vs2 with lmul
Prior to this commit when calling processor_t's constructor xlen was
explicitly initialized with zero (hence get_xlen and get_const_xlen both
returned zero). Later the value of xlen was being corrected in the first reset
call. Which made it impossible to use xlen on custom extension registration
(before first reset). This patch initializes xlen with the correct value
from the start.