MMU was Re: Contribute to a project under GSOC 2018

Sat Mar 17 07:59:45 UTC 2018

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/1boKGnnzQGCzxIVqBVMWvK7OFJTvWK
> zWDXj1EvuEuq5o/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/7ed6b426fccfb203dd96be9b7591b3
> 744f1f.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
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >
> >>> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180317/645b8cc2/attachment-0002.html>