Proposal to Add S-Mode Support to RISC-V FreeRTOS Demo and Port Layer

Kernel
1

Hello FreeRTOS Community,

I’ve been working on adding Supervisor Mode (S-mode) support to the RISC-V FreeRTOS demo for the QEMU virt board and would like to propose upstreaming these changes. Before submitting, I’m seeking feedback to ensure my changes align with FreeRTOS’s goals.

Work Done:

1.Portable Layer (portable/GCC/RISC-V):
Extended the port to support S-mode by adding traps and interrupt handling.
Kept backward compatibility with the existing M-mode implementation.
2.Demo (FreeRTOS/Demo/RISC-V-Qemu-virt_GCC):
Modified the demo for QEMU virt, enabling support for S-mode.
Tested the changes in both Supervisor and Machine modes using QEMU virt.

Questions:
1.Is there broader interest in official S-mode support for FreeRTOS, or should this enhancement remain specific to the QEMU virt demo?
2.Are there any additional testing or validation steps I should consider to ensure the changes meet community standards?

Thanks.

2

I’m using RISC-V in current and for next projects. So I definitely interested in more deep support of RISC-V architecture. But I think suprevisor mode is useful, along with memory protecting unit, only in large systems with different kinds of memories and with different execution rights.
The usage of different modes of execution is valuable where your system should execute third party code and the same time to be safe.
Personally I’m didn’t get such development level where I need use additional mode with FreeRTOS. @Premchand_Pawar can you describe some scenarios when S-mode may be useful?

3

I’d suggest to upstream your port and demo to the community supported ports and demos repositories:

As @Nikolay-Po asked, it would be interesting to know your use case.

4

When I was looking into FreeRTOS support for RISC V, I realized that, support is currently available only for M-Mode and not for S-Mode and hence tried enabling support to run FreeRTOS support in S-Mode. This will enable / help in running FreeRTOS in S-Mode on larger systems where its needed. Agree to your comment that, S-Mode is largely useful for larger systems with various memories along with MPU and may not be for QEMU Virt board. FYI, I used QEMU Virt GCC as my Demo / Test platform.

5

I may just be contaminated by something I’ve been looking at recently but is your proposal is to enable tasks to run in S-Mode or enable the port to run in S-mode (e.g. on top of an hypervisor)?

FWIW, there is some value in either of them:

If you are running task in S-mode (or U-mode), one could use the RISC-V PMPs to do some basic memory isolation.

If you are enabling a FreeRTOS to run in S-mode, I know that people have thought about replacing several uCs (some of which may run FreeRTOS) by a bigger processor running a hypervisor.