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/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/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
