MMU was Re: Contribute to a project under GSOC 2018

Fri Apr 13 17:31:29 UTC 2018

Sir,

I have read following papers and have gained a good knowledge of RTEMS and
RTEMS memory management.
https://dl.acm.org/ft_gateway.cfm?id=2597459&type=pdf
http://adsabs.harvard.edu/full/2005ESASP.602E..26S
http://ieeexplore.ieee.org/abstract/document/4958736/

I would like to begin with the code part to gain a good understanding of
that too. I request you to please guide me how should I proceed.

Thanks and Regards
Abhinav Jain

On Fri, Apr 6, 2018 at 11:12 PM, Abhinav Jain <jainab.2009 at gmail.com> wrote:

> Sir,
> I have gone through a research paper(attached with the mail) Analysis and
> Improvement of RTEMS Memory Management by Hongwei Li and Chanhong Yin,
> Changzhou, China.
> This paper has provided me a good knowledge of RTEMS memory management but
> this is an old paper(2009).
> I will be obliged if you can provide me some more resources so that I can
> gain some more knowledge and can get more ideas about designing the MMU
> support.
>
> Thanks and Regards
> Abhinav Jain
>
> On Wed, Apr 4, 2018 at 12:47 AM, Abhinav Jain <jainab.2009 at gmail.com>
> wrote:
>
>> Sir,
>>
>> I have gone through https://homes.cs.washington.edu/~levy/opal/opal-
>> tocs.pdf, where the protection approach in Opal Operating System is
>> provided. As per my understanding of the paper, I have tried to extract the
>> memory protection part and have written a blog on it:
>> http://ajrealtime.blogspot.in/2018/04/sharing-and-
>> protection-in-single.html.
>> Opal is a single-address-space operating system, and in this paper, a
>> detailed description of protection is provided which I found quite useful
>> for getting a good idea which can be implemented in RTEMS too.
>> I request you to please have a look at the write-up written by me after
>> understanding this paper and also please guide me what should be my next
>> step to proceed with the project.
>>
>> Thanks and Regards
>> Abhinav Jain
>>
>> On Sat, Mar 24, 2018 at 12:36 AM, Abhinav Jain <jainab.2009 at gmail.com>
>> wrote:
>>
>>> Sir,
>>>
>>> I have researched about the current MMU support available in RTEMS and I
>>> have mentioned about it in the proposal. Also as per your guidance, I have
>>> omitted the idea of developing memory protection for architectures not
>>> having MMU, rather I will give my full focus to developing MMU support for
>>> RISC -V architecture.
>>> I request you to please review the proposal and guide me if some changes
>>> are to be made to this, or if I should work on some other architecture. I
>>> am researching more about the difference in MMU in RISC -V and PowerPC and
>>> ARM, for which the MMU support is already available in RTEMS.
>>>
>>> https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OF
>>> JTvWKzWDXj1EvuEuq5o/edit?usp=sharing
>>>
>>> Thanks and Regards
>>> Abhinav Jain
>>>
>>>
>>> On Sat, Mar 17, 2018 at 1:29 PM, Abhinav Jain <jainab.2009 at gmail.com>
>>> wrote:
>>>
>>>> Sir,
>>>>
>>>> Thanks for the guidance and feedback. I have shared the draft proposal
>>>> through GSoC application. I will make the changes as per your suggestions
>>>> and will add the details mentioned by you.
>>>>
>>>> Thanks and Regards
>>>> Abhinav Jain
>>>>
>>>> On Sat, Mar 17, 2018 at 12:47 AM, Gedare Bloom <gedare at rtems.org>
>>>> wrote:
>>>>
>>>>> 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/1boKGnnzQGCzxIVqBVMWvK7OF
>>>>> JTvWKzWDXj1EvuEuq5o/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/7ed6b426fccfb203dd96be
>>>>> 9b7591b3744f1f.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/doc
>>>>> ument/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/Usin
>>>>> g_an_MPU_to_Enforce_Spatial_Separation.pdf
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >> https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be
>>>>> 9b7591b3744f1f.pdf
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >> https://www.researchgate.net/publication/221033285_A_New_App
>>>>> roach_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/20180413/7d34a65c/attachment-0002.html>