<div dir="auto">Sir,<div dir="auto"><br></div><div dir="auto">Thanks a lot for the guidance. I will study the documents provided by you and will try to find more about this to increase my knowledge about Memory support. </div><div dir="auto">I will start preparing a draft proposal as per the template provided on the RTEMS GSoC page.</div><div dir="auto"><br></div><div dir="auto">Thanks and Regards</div><div dir="auto">Abhinav Jain</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 6, 2018 10:25 PM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain <<a href="mailto:jainab.2009@gmail.com">jainab.2009@gmail.com</a>> wrote:<br>
> Sir,<br>
><br>
> Thanks for your time and consideration. I was discussing this project with<br>
> Gedare Sir and he guided me, how to proceed.<br>
> I am studying various things before proceeding with the code part but for<br>
> now, I request you to please guide me what should be my next steps to work<br>
> on this project under GSOC'18.<br>
><br>
> Thanks and Regards<br>
> Abhinav Jain<br>
><br>
> On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary <<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" <<a href="mailto:jainab.2009@gmail.com">jainab.2009@gmail.com</a>> wrote:<br>
>> ><br>
>> > Sir/Madam,<br>
>> ><br>
>> > I am Abhinav Jain, a second-year engineering student from Delhi, India.<br>
>> > I<br>
>> > have been working in Linux Kernel Development, I have been writing small<br>
>> > drivers and have a good knowledge of the operating system.<br>
>> > I have been studying about Memory Protection project(ticket #2904) for<br>
>> > around a month and found it really interesting. I studied about POSIX,<br>
>> > MMU<br>
>> > support in various other architecture and the memory protection APIs in<br>
>> > various operating systems.I have been discussing the same on the mailing<br>
>> > list.<br>
>> > I also solved an issue (#2522) around a week ago to gain some hands-on<br>
>> > code.<br>
>> ><br>
</div>-ENOPATCH<br>
<div class="quoted-text"><br>
>> ><br>
>> > Welcome aboard.<br>
>> ><br>
>> ><br>
>> > I would like to work on the Memory Protection project under GSOC 2018,<br>
>> > so I<br>
>> > request you to please guide me regarding the steps to be followed.<br>
>> ><br>
>> ><br>
>> > Gedare conceived of what's there be so I cc'ed him. My recollection is<br>
>> > that<br>
>> > there were specific things he wanted to change and when that was<br>
>> > addressed,<br>
>> > providing support for arenas on multiple architecture is desirable<br>
>> ><br>
>> +1<br>
>><br>
>> There might be an opportunity to port RTEMS to RISC-V's Supervisor<br>
>> Mode which will need MMU support (currently it only runs on M-Mode<br>
>> which doesn't have MMU). Both QEMU and Spike simulators support<br>
>> S-Mode.<br>
>><br>
</div>Start to develop a draft proposal if you have not yet, starting with<br>
our template. A successful proposal must contain a sound design and<br>
good plan, which you will need a lot of time and feedback to develop.<br>
<br>
Don't read too much about 64-bit processor architectures and their<br>
needs, since we have limited support there. The first issue to resolve<br>
is what kind of BSP-level interface should we provide over MMU/MPU<br>
hardware, and then what can we do to use that BSP layer to provide<br>
upper-layer services such as managed memory regions, better mmap()<br>
support, "arena" allocators, etc. There are three views here:<br>
1. no mmu/mpu is available or it is not desired by end users.<br>
2. mmu/mpu are available, but should only be manipulated statically/boot-time.<br>
3. mmu/mpu are available, and can be changed dynamically.<br>
<br>
Managing #3 is the hardest, but accommodating 1 and 2 in any system<br>
design is important. Another important concern is mmu/mpu with limited<br>
numbers of entries. Right now, we exist mainly in #1, and #2 is only<br>
used to setup a linear 1:1 memory map with all permissions enabled<br>
when the MMU/MPU can't be turned off. A few projects exist here and<br>
there to also restrict permissions to thread stacks with a hook in the<br>
context switch to change the mpu/mmu state.<br>
<br>
Since RTEMS has no multi-process model, the existing solutions in<br>
general-purpose commodity OS do not apply, but you should still be<br>
familiar with how they work for sure. It would also be good for you to<br>
review the solutions in the commodity RTOS domain, e.g. what does<br>
vxworks, safertos, threadx, etc., provides in this field.<br>
<br>
Some relevant citations to get more relevant background:<br>
<br>
<a href="https://highintegritysystems.com/downloads/white_papers/Using_an_MPU_to_Enforce_Spatial_Separation.pdf" rel="noreferrer" target="_blank">https://highintegritysystems.<wbr>com/downloads/white_papers/<wbr>Using_an_MPU_to_Enforce_<wbr>Spatial_Separation.pdf</a><br>
<br>
<a href="https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf" rel="noreferrer" target="_blank">https://pdfs.semanticscholar.<wbr>org/3c92/<wbr>7ed6b426fccfb203dd96be9b7591b3<wbr>744f1f.pdf</a><br>
<br>
<a href="https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_Partitioning_in_On-Board_Spacecraft_Software" rel="noreferrer" target="_blank">https://www.researchgate.net/<wbr>publication/221033285_A_New_<wbr>Approach_to_Memory_<wbr>Partitioning_in_On-Board_<wbr>Spacecraft_Software</a><br>
<div class="elided-text"><br>
<br>
<br>
<br>
>> ><br>
>> ><br>
>> > Thanks and Regards<br>
>> > Abhinav Jain<br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > devel mailing list<br>
>> > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > devel mailing list<br>
>> > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Hesham<br>
><br>
><br>
</div></blockquote></div><br></div>