Is Supervisor Timer & Supervisor Software interrupt supported on U54 or FU540

I have successfully generated Machine timer and machine software interrupt, but writing software for S-mode I couldn’t find any way to generate a Supervisor timer/software interrupt.

According to RISC-V documentation, to generate an interrupt in Supervisor mode, the appropriate bits needs to be set in interrupt & exception delegation register “mideleg”, which I did, interrupt needs to be enabled in SIE (supervisor interrupt enable register) which I also did. I double checked that the delegation is supported by writing all 1s to “mideleg”. But I couldn’t find any register in U54 manual for generation of Supervisor timer/software interrupt. Writing to MSIP or generates a machine mode software interrupt not supervisor software interrupt. Can supervisor software interrupt be generated in S mode to S mode (delegated) or am I missing something in interrupt generation.

I also saw Uboot code, and observed it relies on Supervisor-binary interface (SBI) provided by openSBI to generate machine mode IPIs by using ecall, even it doesn’t SSI (supervisor software interrupt).


This is also a question I really want to figure out, for me the only way to trriger a S mode time/software interrupt is to set bit in mip

Hi @Phantom0308 I am working on an OS port. Here are some of my findings related to this problem.

Uboot code don’t generate supervisor timer or supervisor software, it relies on openSBI bootloader for that interfaced, I debugged Uboot as well. What I have been successful is in generating Supervisor mode exceptions/traps like faults, UserMode ECall gets routed to supervisor mode, but Timer/Software don’t routed, except for setting sip bit.

For external interrupts, some other details are, the Qemu model has U54 core which has same interrupt enable register for MS-mode in PLIC, even the external mode interrupts don’t get routed to S mode they go to Machine mode directly for Qemu. Even if they are delegated.

But unlike QEMU the Unleashed board has U54-C000 core, which is slightly different from U54, it has separate interrupt enables for M & S mode in PLIC. On hardware board the external interrupts do go to S mode (if they are deleted, and appropriate setting are done in plic).

cc: @jimw/@Krste

Maybe there are some bugs in Qemu …
I insist that the way to generate the S mode time/software interrupt is to set bits in m/sip, because for these interrupts came from CLINT, which will only cause a machine mode interrupt.
It’s true that with delegated, interrupt will directly go to the correspond mode, but since mtime/mtimecmp is a machine mode csr, it will generate a M mode time interrupt, and there is no S mode timer, so you need to set bit in m/sip to generate a S mode time interrupt.
When “mret”, you will jump to the address in stvec directly with delegated.

1 Like

Yup, and that’s exactly what I did to solve that, should have posted my solution earlier :slight_smile:
Regarding Qemu model it doesn’t implement supervisor external interrupt, (SEIP bit) is hardwired to zero, hence it can’t be emulated.

With the use of MSIP/MTIP bit, once can completely emulate supervisor timer/supervisor software interrupt, and that’s how I made it work. And openSBI/uboot both does the same thing, e.g. here is how they emulate timer interupt.
Pseudo code:
M mode timer handler:
mask MTIE bit (so machine timer interrupt will not come)
set STIP bit (so supervisor timer interrupt will come) (kind of like emulating timer interrupt)
exit using mret
Now we will jump to supervisor interrupt handler, and same logic goes for MSIP (supervisor software interrupt emulation).

Pseudo code:
M mode timer handler:
mask MTIP bit (so machine timer interrupt will not come)
set STIP bit (so supervisor timer interrupt will come) (kind of like emulating timer interrupt)
exit using mret

Line 2, MTIP -> MTIE
My handler looks like following:

void timer_interrupt() {
    clear_csr(mie, MIP_MTIP);
    set_csr(mip, MIP_STIP);

I’m not sure MTIP bits in mip, when a time interrupt happens …