Sir, I have read following papers and have gained a good knowledge of RTEMS and RTEMS memory management. https://dl.acm.org/ft_gateway.cfm?id=2597459&type=pdf http://adsabs.harvard.edu/full/2005ESASP.602E..26S http://ieeexplore.ieee.org/abstract/document/4958736/
I would like to begin with the code part to gain a good understanding of that too. I request you to please guide me how should I proceed. Thanks and Regards Abhinav Jain On Fri, Apr 6, 2018 at 11:12 PM, Abhinav Jain <jainab.2...@gmail.com> wrote: > Sir, > I have gone through a research paper(attached with the mail) Analysis and > Improvement of RTEMS Memory Management by Hongwei Li and Chanhong Yin, > Changzhou, China. > This paper has provided me a good knowledge of RTEMS memory management but > this is an old paper(2009). > I will be obliged if you can provide me some more resources so that I can > gain some more knowledge and can get more ideas about designing the MMU > support. > > Thanks and Regards > Abhinav Jain > > On Wed, Apr 4, 2018 at 12:47 AM, Abhinav Jain <jainab.2...@gmail.com> > wrote: > >> Sir, >> >> I have gone through https://homes.cs.washington.edu/~levy/opal/opal- >> tocs.pdf, where the protection approach in Opal Operating System is >> provided. As per my understanding of the paper, I have tried to extract the >> memory protection part and have written a blog on it: >> http://ajrealtime.blogspot.in/2018/04/sharing-and- >> protection-in-single.html. >> Opal is a single-address-space operating system, and in this paper, a >> detailed description of protection is provided which I found quite useful >> for getting a good idea which can be implemented in RTEMS too. >> I request you to please have a look at the write-up written by me after >> understanding this paper and also please guide me what should be my next >> step to proceed with the project. >> >> Thanks and Regards >> Abhinav Jain >> >> On Sat, Mar 24, 2018 at 12:36 AM, Abhinav Jain <jainab.2...@gmail.com> >> wrote: >> >>> 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/1boKGnnzQGCzxIVqBVMWvK7OF >>> JTvWKzWDXj1EvuEuq5o/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
