Open qushaoru opened 10 months ago
By convention, register names starting with letter 'm' belong to the Machine (M) mode of RISC-V processor. Such registers are not accessible from other modes. In particular, Linux processes run in User (U) mode, and similar register is called ustatus. M-mode is running Supervisor Binary Interface (SBI): OpenSBI. I don't know if SBI provides U-mode applications a method to read mstatus.
"I have attempted to access the ustatus control register in user mode with the following code:
inline unsigned long int read_ustatus() {
unsigned long int value;
__asm__ volatile ("csrr %0, ustatus" : "=r" (value));
return value;
}
I have also tried to write a simple Linux driver module to read the mstatus control register:
static int hello_init(void)
{
printk("Hello kernel world!\n");
printk("mstatus: %lu\n", read_mstatus());
printk("Read CSR PASS!\n");
return 0;
}
...
module_init(hello_init);
However, both of these solutions still result in the error message as shown above. Can this rule out privilege-level issues? Or is it possible that this microarchitecture lacks the implementation of the ustatus control register, and the driver module executed through 'insmod hello.ko' isn't running in the kernel mode of Linux? Additionally, is it possible that this error message could be due to me not including the correct compilation options?"
is it possible that this microarchitecture lacks the implementation of the ustatus control register
I recommend to try 64b1 config (Rocket Chip) instead of 64y1 (BOOM). Rocket Chip is the original RISC-V reference implementation, the most accurate and stable, while BOOM is an experimental implementation of superscalar RISC-V, it appears incomplete and not 100% stable.
Also, ustatus looks accessible OK in the debugger. So, it is more likely a software issue.
'insmod hello.ko' isn't running in the kernel mode of Linux?
It is running in the kernel mode. However, the Linux kernel runs in RISC-V Supervisor (S) mode, and the register name is sstatus.
is it possible that this error message could be due to me not including the correct compilation options?
I don't know. I don't own GCC :)
If accessing the ustatus control register through a debugger, is the program actually running directly on bare metal, rather than running on Linux system? Or has it been confirmed that an application can directly read the ustatus control register on a 64b1 configuration (Rocket Chip) with Linux system?
I tried to run the debugger, ustatus in not accessible, sstatus and mstatus work OK. As I understand, a while ago ustatus became part of optional RISC-V N extension, then both the N extension and the register were removed. The latest specs don't mention ustatus.
thank you very much, I get it. However, I have one more question. Is the current Linux system in this project not supporting the 'perf' tool, or is it that the hardware architecture doesn't support the control registers for tracking hardware performance metrics? I noticed in /patches/linux.config
there is the following code related to enabling the PMU:
CONFIG_RISCV_PMU=y
CONFIG_RISCV_PMU_LEGACY=y
CONFIG_RISCV_PMU_SBI=y
However, when I log into the operating system, I encounter the situation where 'perf: command not found' occurs.
To install perf:
sudo apt update
sudo apt upgrade
sudo apt install linux-perf
However, I don't know how much of perf functionality is supported by RISC-V.
Got it, understood. You previously mentioned that the Linux system running in RISC-V S privilege mode. In that case, which privilege mode do U-Boot and OpenSBI run in? Also, when U-Boot hands over CPU control to the Linux kernel, which privilege mode is the system in at that moment?
OpenSBI runs in M-mode, U-Boot and Linux kernel - S-mode.
when U-Boot hands over CPU control to the Linux kernel, which privilege mode is the system
S-mode.
Understood, I see. Thank you very much. I have another question regarding rocket64y1. Does this core implement mhpmcounter3-mhpmcounter31 according to the RISC-V instruction set? I've observed a phenomenon where writing 0xffffffff to the mcounteren register results in reading a value of 0x00000007. If the mhpmcounters are implemented, which performance events are supported for recording?
Does this core implement mhpmcounter3-mhpmcounter31 according to the RISC-V instruction set?
For BOOM implementation details, you better ask BOOM developers at riscv-boom.
ok, thanks
Hello, Sorry for bothering you. I'm a student who has just started learning the RISC-V instruction set. After setting up the environment you provided (program the rocket64y1 bitstream into the VC707 board and running the Linux system), I wanted to read the control register 'mstatus' through inline assembly in C language. I'm using the g++ compiler directly from apt-get on the Linux system, without adding any compiler options (g++ ./main.cpp -o main). The inline assembly code is as follows:
However, when I run this program as the root user, I encounter the following error message (I have confirmed that the error is generated by the code above):
Could you please advise me on how to resolve this issue?