The issue #3337 states that the RTEMS kernel is running in M (Machine) Mode. This implementation focuses on providing the optionality to run in S (Supervisor) Mode.
The above project had a mandatory task to run on any RISC-V BSP.
To try and implement the above feature, the kernel must be able to switch to Supervisor mode.
The hardware vendors provide the SBI ABI running in M mode. Thus, RTEMS should use this to run the kernel in S mode.
To implement this on QEMU, we are loading the external SBI layer (OpenSBI) so that RTEMS can use its calls for privileged services. This can be done by creating wrapper classes for the BSPs.
Next possible implementation
Adding functional boot for S-mode.
Timer interrupt: The BSPs generally program the timer directly, so that should be changed.
Interrupt control bits: Ensuring interrupt enable/disable works in both modes.
These are my current reasonings for this project. I will be updating on the this in further posts.
Looking forward to guidance from mentors and community members.
I’m not sure about other platforms, but the QEMU PolarFire platform can load S-mode binaries using the -kernel option and implicitly has OpenSBI running in M-mode. This is how the Linux kernel is tested on that platform.
I expect that I will finish this work before the GSoC application period. It would be best for you to scope out something else. You could look for a project that relies on having the S-Mode support available, or there are lots of other risc-v projects that could be taken on I’m sure.
Assuming that the S-mode work is done before the application period and that @gedare’s work doesn’t already encompass it, a good task might be creating a S-mode BSP variant for the polarfire BSPs (beaglevfire and mpfs64imafdc).
Okay , So I just went through stuff and came up with some options. I can work on the issue #5137 I went through it briefly and I felt it could be added and done as a GSOC project and parallely do some tasks mentioned in the list.
Or,
The second one, which @opticron suggested if it can be done as GSOC project then I am up for it . The only concern for me on this is how do I start or cope up with @gedare work .
I am okay with both , I just need your guidance on this.
Is that in the context of DTS-native development instead of how we currently do it where we keep the DTS around, but also keep a converted FDT that must be regenerated manually?
@opticorn I am currently understanding the DTS to DTB to FDT flow.
Just need 3-4 days to sketch out the plan.But isnt the manual regeneration of FDT leads to more errors.?.So further I will check on this.
I went through the issue and it seems much more interesting. Can this issue be added to GSOC list? I had my semester finals this week so could not upload a detailed post on this issue
.
Yes, I have added it to the official list. I estimate it as a medium, although that is a rough guess. You’ll have to do a bit of research to scope out the project yet, since it was described at a high level so far.
So i will have abandon it . Is there any way where I can work under you and can it be considered for GSOC.?