MMU was Re: Contribute to a project under GSOC 2018

Fri Mar 16 22:53:21 UTC 2018

On Mar 16, 2018 2:17 PM, "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.

Pok is a free ARINC 653 RTOS

https://github.com/pok-kernel/pok

ARINC 653 requires time and space separation. Pok has ports to three
architectures on the main site above. It would likely be a good source
reference for MMU handling. It will be static after initialization.

--joel

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/20180316/bf2e028e/attachment-0002.html>