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/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing Thanks and Regards Abhinav Jain On Sat, Mar 17, 2018 at 1:29 PM, Abhinav Jain <jainab.2...@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 <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/1boKGnnzQGCzxIVqBVMWvK7OF >> JTvWKzWDXj1EvuEuq5o/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/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 <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/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.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/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@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
