MMU was Re: Contribute to a project under GSOC 2018

[Abhinav Jain]

Sir,

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.
I will start preparing a draft proposal as per the template provided on the
RTEMS GSoC page.

Thanks and Regards
Abhinav Jain







On Mar 6, 2018 10:25 PM, "Gedare Bloom" <gedare at rtems.org> wrote:

On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain <jainab.2009 at gmail.com> wrote:
> Sir,
>
> Thanks for your time and consideration. I was discussing this project with
> Gedare Sir and he guided me, how to proceed.
> I am studying various things before proceeding with the code part but for
> now, I request you to please guide me what should be my next steps to work
> on this project under GSOC'18.
>
> Thanks and Regards
> Abhinav Jain
>
> On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary <heshamelmatary at gmail.com
>
> wrote:
>>
>> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill <joel at rtems.org> wrote:
>> >
>> >
>> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" <jainab.2009 at gmail.com> wrote:
>> >
>> > Sir/Madam,
>> >
>> > I am Abhinav Jain, a second-year engineering student from Delhi, India.
>> > I
>> > have been working in Linux Kernel Development, I have been writing
small
>> > drivers and have a good knowledge of the operating system.
>> > I have been studying about Memory Protection project(ticket #2904) for
>> > around a month and found it really interesting. I studied about POSIX,
>> > MMU
>> > support in various other architecture and the memory protection APIs in
>> > various operating systems.I have been discussing the same on the
mailing
>> > list.
>> > I also solved an issue (#2522) around a week ago to gain some hands-on
>> > code.
>> >
-ENOPATCH

>> >
>> > Welcome aboard.
>> >
>> >
>> > I would like to work on the Memory Protection project under GSOC 2018,
>> > so I
>> > request you to please guide me regarding the steps to be followed.
>> >
>> >
>> > Gedare conceived of what's there be so I cc'ed him. My recollection is
>> > that
>> > there were specific things he wanted to change and when that was
>> > addressed,
>> > providing support for arenas on multiple architecture is desirable
>> >
>> +1
>>
>> There might be an opportunity to port RTEMS to RISC-V's Supervisor
>> Mode which will need MMU support (currently it only runs on M-Mode
>> which doesn't have MMU). Both QEMU and Spike simulators support
>> S-Mode.
>>
Start to develop a draft proposal if you have not yet, starting with
our template. A successful proposal must contain a sound design and
good plan, which you will need a lot of time and feedback to develop.

Don't read too much about 64-bit processor architectures and their
needs, since we have limited support there. The first issue to resolve
is what kind of BSP-level interface should we provide over MMU/MPU
hardware, and then what can we do to use that BSP layer to provide
upper-layer services such as managed memory regions, better mmap()
support, "arena" allocators, etc. There are three views here:
1. no mmu/mpu is available or it is not desired by end users.
2. mmu/mpu are available, but should only be manipulated
statically/boot-time.
3. mmu/mpu are available, and can be changed dynamically.

Managing #3 is the hardest, but accommodating 1 and 2 in any system
design is important. Another important concern is mmu/mpu with limited
numbers of entries. Right now, we exist mainly in #1, and #2 is only
used to setup a linear 1:1 memory map with all permissions enabled
when the MMU/MPU can't be turned off. A few projects exist here and
there to also restrict permissions to thread stacks with a hook in the
context switch to change the mpu/mmu state.

Since RTEMS has no multi-process model, the existing solutions in
general-purpose commodity OS do not apply, but you should still be
familiar with how they work for sure. It would also be good for you to
review the solutions in the commodity RTOS domain, e.g. what does
vxworks, safertos, threadx, etc., provides in this field.

Some relevant citations to get more relevant background:

https://highintegritysystems.com/downloads/white_papers/
Using_an_MPU_to_Enforce_Spatial_Separation.pdf

https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3
744f1f.pdf

https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_
Partitioning_in_On-Board_Spacecraft_Software




>> >
>> >
>> > Thanks and Regards
>> > Abhinav Jain
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Hesham
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180307/e2e0fac3/attachment.html>