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 <ged...@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.2...@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.2...@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 <ged...@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.2...@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 <ged...@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.2...@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.2...@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" <ged...@rtems.org> > wrote: > >>> >> >> > >>> >> >> On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain > >>> >> >> <jainab.2...@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 > >>> >> >> > <heshamelmat...@gmail.com> > >>> >> >> > wrote: > >>> >> >> >> > >>> >> >> >> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill < > j...@rtems.org> > >>> >> >> >> wrote: > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" > >>> >> >> >> > <jainab.2...@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@rtems.org > >>> >> >> >> > http://lists.rtems.org/mailman/listinfo/devel > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > > >>> >> >> >> > _______________________________________________ > >>> >> >> >> > devel mailing list > >>> >> >> >> > devel@rtems.org > >>> >> >> >> > http://lists.rtems.org/mailman/listinfo/devel > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> -- > >>> >> >> >> Hesham > >>> >> >> > > >>> >> >> > > >>> >> >> > >>> >> >> > >>> >> > > >>> > > >>> > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
