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/7ed6b426fccfb203dd96be9b7591b3 744f1f.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
