MMU was Re: Contribute to a project under GSOC 2018

Fri Mar 16 19:17:34 UTC 2018

high-level comments:

* add citations to relevant literature that you used for inspiration.
* start to write a design plan for the bsp-level framework you envision.
* it would be a good idea to review the existing mmu support in RTEMS.
* link to this google doc as your "Draft" from your GSoC application,
and also upload an initial "Final" pdf, which you can continue to
revise.

Gedare

On Fri, Mar 16, 2018 at 2:48 PM, Abhinav Jain <jainab.2009 at gmail.com> wrote:
> Sir,
>
> I have prepared a draft proposal for GSoC 2018 as suggested by you.
> I request you to please guide me whether I have made it correctly or not,
> whether I have written some big plans or more things can be included.
>
> The link for the Proposal is:
> https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing
>
> Thanks and Regards
> Abhinav Jain
>
> On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain <jainab.2009 at gmail.com>
> wrote:
>>
>> Sir,
>>
>> Thanks for the guidance. I am studying ARM architecture and trying to find
>> out the difference in it's architecture from other ones, I am trying to
>> understand what can be the minimum changes to the existing framework to get
>> it working on other architectures.
>>
>> Thanks and Regards
>> Abhinav Jain
>>
>>
>> On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> The framework exists in the rtems source code, underneath
>>> c/src/lib/libbsp/arm.
>>>
>>> Start with the GSoC template, adjust the dates, start adding details.
>>> When you have a draft you can invite comments for review.
>>>
>>> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain <jainab.2009 at gmail.com>
>>> wrote:
>>> > Sir,
>>> >
>>> > The description of the RoadRunner OS is mentioned in the document
>>> > provided
>>> > by you,
>>> >
>>> > https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf
>>> > The link (http://ieeexplore.ieee.org/document/7509439/?part=1) which I
>>> > mentioned in the previous mail deals with memory management scheme for
>>> > the
>>> > MMU-less embedded systems.
>>> > If there is already a framework for ARM MMU, I will try to extend it to
>>> > other architectures as much as possible, I read about various
>>> > architectures
>>> > in past couple of days.
>>> > I request you to please provide the link to the available framework so
>>> > that
>>> > I can study that and proceed with its enhancement if possible. Also, I
>>> > request you to please guide me for my GSoC proposal.
>>> >
>>> > Thanks and Regards
>>> > Abhinav Jain
>>> >
>>> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>> >>
>>> >> Abhinav,
>>> >>
>>> >> Send me the linked article. Does it describe the RoadRunner OS
>>> >> approach? I am not familiar with it.
>>> >>
>>> >> Note that there is a basic framework for ARM MMU in place already.
>>> >> Adoption/adaptation of it to other architectures is preferred versus
>>> >> replacing it, unless absolutely necessary.
>>> >>
>>> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain <jainab.2009 at gmail.com>
>>> >> wrote:
>>> >> > Sir,
>>> >> >
>>> >> > I studied the documents provided by you in the previous mail, also I
>>> >> > read a
>>> >> > document from http://ieeexplore.ieee.org/document/7509439/?part=1.
>>> >> > As told by you in the previous mail that the first issue to be
>>> >> > solved is
>>> >> > to
>>> >> > provide a BSP-level framework for MMU/MPU hardware, after reading
>>> >> > the
>>> >> > memory
>>> >> > protection in roadrunner operating system, I think that with some
>>> >> > changes,
>>> >> > the same concept can be implemented in the RTEMS for memory
>>> >> > protection.
>>> >> > I request you to please guide me whether I am right in the approach
>>> >> > or I
>>> >> > have to think differently.
>>> >> >
>>> >> >
>>> >> > Thanks and Regards
>>> >> > Abhinav Jain
>>> >> >
>>> >> >
>>> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain
>>> >> > <jainab.2009 at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> 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/7ed6b426fccfb203dd96be9b7591b3744f1f.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
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >
>>> >
>>> >
>
>