Hello Dr. Bloom, I have contacted to the past contributors, Peter and I will discuss PowerPC and further support, next week, in the meantime, I am going through PowerPC code and how I can build with the existing system a new bsp code for MMU/MPU support. I will complete my application next week.
In the meantime, any suggestions from your side are most welcome. On Wed, Mar 22, 2017 at 8:57 PM, Gedare Bloom <ged...@rtems.org> wrote: > > > On Wed, Mar 22, 2017 at 11:13 AM, Abhimanyu Rawat < > h2015...@pilani.bits-pilani.ac.in> wrote: > >> Indeed, PowerPC code is somewhat developed, would you recommend if there >> are some specific features in PowerPC that I should revisit? As this is >> little confusing as some work has been done on exception handler, page >> tables, cache already, so what should I target next and what to modify >> first? Past developer of the PowerPC support might help if you would >> connect me to? >> ᐧ >> >> I've CC'd some of the folks who previously worked on this topic. So > perhaps they have input for you. > > I think the important thing is that when we design a framework that it is > flexible enough to accommodate the many varieties of memory management > hardware. > > >> *Closing with thank you and warm Regards,* >> >> *Abhimanyu Rawat* >> *M.E. Computer Science, * >> *CS/IS Department, BITS Pilani, Pilani Campus* >> *Email - h2015...@pilani.bits-pilani.ac.in >> <h2015...@pilani.bits-pilani.ac.in> / abhimanyura...@yahoo.com >> <abhimanyura...@yahoo.com>* >> *Phone. 08930399302 (call/Whatsapp), 09466899302* >> >> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ >> >> On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom <ged...@rtems.org> wrote: >> >>> >>> >>> On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat < >>> h2015...@pilani.bits-pilani.ac.in> wrote: >>> >>>> >>>> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom <ged...@rtems.org> wrote: >>>> >>>>> Please prefer to try to keep general GSoC / RTEMS project discussions >>>>> on the mailing list. Direct e-mail is ok but inefficient in many cases and >>>>> should only be preferred for communciations of a personal or private >>>>> matter. >>>>> >>>>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat < >>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>> >>>>>> >>>>>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom <ged...@rtems.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat < >>>>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>>>> >>>>>>>> Hello Dr. Bloom, >>>>>>>> >>>>>>>> Sorry for writing after a big gap( was busy with a product >>>>>>>> integration), although I found time to go through the pointers you put >>>>>>>> together for me, thanks they were really helpful in getting an idea >>>>>>>> about >>>>>>>> the project and how to process everything in time. >>>>>>>> >>>>>>>> Gaps are normal and acceptable (until you are getting paid for work >>>>>>> :)). You should also expect to have gaps in responses from developers on >>>>>>> the mailing list, since we are also generally volunteering. >>>>>>> >>>>>>> >>>>>>>> I noticed that all the existing work on MMU is not moving very fast >>>>>>>> like other supporting components for RTEMS, last year too no one was >>>>>>>> selected to do MMU project #2904. I know only one guy applied but the >>>>>>>> proposal was not quite promising. But trust me, all that doesn't make >>>>>>>> it >>>>>>>> any less desirable for me to take it. Now, I have a few questions: >>>>>>>> >>>>>>>> I would not recommend judging the priority/value of a proposed >>>>>>> project based on whether or not it was done in the past. Definitely >>>>>>> discuss >>>>>>> with mentors, etc. This project area is a good, long-term investment for >>>>>>> RTEMS, but it does move slowly. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom <ged...@rtems.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat < >>>>>>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>>>>>> >>>>>>>>>> Hello folks, >>>>>>>>>> >>>>>>>>>> I am Abhimanyu Rawat, a Computer Science Masters degree student >>>>>>>>>> from BITS Pilani Campus, India. I found Memory Protection project >>>>>>>>>> #2904 <https://devel.rtems.org/ticket/2904> very interesting and >>>>>>>>>> vital for the the RTEMS. Among the lots of projects listed on the >>>>>>>>>> ideas >>>>>>>>>> page, Memory Protection draws me to RTEMS as it's a very challenging >>>>>>>>>> project and I would thoroughly enjoy working on it. I am a really >>>>>>>>>> enthusiastic person who would like to contribute to the project. I >>>>>>>>>> have >>>>>>>>>> previous experience in C, C++ and Python etc. At present I am an >>>>>>>>>> intern at >>>>>>>>>> EMC ^2 where I am working on DataDomain Operating system, building >>>>>>>>>> configuration tool for the latest DDOS software update. I have also >>>>>>>>>> lead a >>>>>>>>>> BITS-Stanford inter-university project, where my team worked on >>>>>>>>>> Django >>>>>>>>>> based project with an inbuilt authorization tool + chat application >>>>>>>>>> etc. I >>>>>>>>>> usually help my friends with their projects as well. >>>>>>>>>> >>>>>>>>>> When does your internship complete, and when does your school >>>>>>>>> year begin again? >>>>>>>>> >>>>>>>>> >>>>>>>>>> As required, I went through the initial brief about the project >>>>>>>>>> and I think it would be a valuable addition to RTEMS. Also, I have >>>>>>>>>> completed the https://devel.rtems.org/wiki/GSoC/GettingStarted, and >>>>>>>>>> configured and Built RTEMS for SPARC/erc32. Subsequently, I have the >>>>>>>>>> snapshot of the terminal showing my name and the GSOC text as >>>>>>>>>> pictured >>>>>>>>>> here >>>>>>>>>> <https://devel.rtems.org/attachment/wiki/GSoC/GettingStarted/SPARC-SIS-HelloWorld-Modded.png>. >>>>>>>>>> Kindly tell me how selectively pointed towto send the proof of the >>>>>>>>>> terminal and the diff file as required. >>>>>>>>>> >>>>>>>>>> Send to me by email is fine. >>>>>>>>> >>>>>>>>> >>>>>>>>>> It would be great if you can give me some pointers about the >>>>>>>>>> structure of the project and the direction I should pursue. >>>>>>>>>> >>>>>>>>>> Have a look at the current approach taken to provide low-level >>>>>>>>> support for the MMUs in the ARM bsps. You can find this looking in the >>>>>>>>> source tree via c/src/lib/libbsp/arm/* with most of the relevant >>>>>>>>> parts in >>>>>>>>> the shared subdirectory there, where each BSP defines a table of >>>>>>>>> statically-configured MMU initialization. >>>>>>>>> >>>>>>>> >>>>>>>> You selectively pointed towards the c/src/lib/libbsp/arm/* shared >>>>>>>> subdirectory where some BSP's has low level code for MMU >>>>>>>> configuration, I >>>>>>>> found ome cache code too. And trying digging deep to build a common >>>>>>>> understanding of different BSP MMU code. The code initally is quite >>>>>>>> hard to >>>>>>>> understand but as a unit what task is taking place is I can understand >>>>>>>> like, data cache and line cleaing etc. Therefore I would request you to >>>>>>>> provide me a documented code review or process guide( if >>>>>>>> available) so that I can develop something to test the MMU code >>>>>>>> changes/patches, otherwise I will have to brute force the search. As >>>>>>>> from >>>>>>>> this point I want to move fast and reflect the my progress. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I recommend that you start by writing a blog post about your >>>>>>> understanding of what is implemented there. Look in the other BSPs to >>>>>>> see >>>>>>> what, if any, MMU code they have. >>>>>>> >>>>>>> Sure, setting up a medium blog to write about the bsp underlying >>>>>> code related to memory related operations. >>>>>> >>>>>>> Cache cleaning/invalidating is often tied with MMU state changes. >>>>>>> >>>>>>> >>>>>>>> This is where the prior work has pretty much left off. Remaining >>>>>>>>> items in this project area include: >>>>>>>>> * Making a uniform approach to MMU/MPU setup across architectures >>>>>>>>> >>>>>>>> It seems nice to have a low level design which can point out the >>>>>>>> mutual modules such as initialising the registers, stack and memory >>>>>>>> lines >>>>>>>> etc. For this I think underying functionality have to be completed >>>>>>>> first or >>>>>>>> complete the remaining pieces in existing code and then move bottom up. >>>>>>>> >>>>>>>> >>>>>>> The underlying functionality exists for at least cp15-based ARM. >>>>>>> Providing the functionality for another BSP family would be a good >>>>>>> place to >>>>>>> start. >>>>>>> >>>>>>> >>>>>>>> * Supporting dynamic changes to MMU/MPU configurations >>>>>>>>> * Leveraging dynamic MMU/MPU enforcement to create a mid-level >>>>>>>>> memory management layers. Various proposals have been designed and >>>>>>>>> implemented in the past that can be studied. >>>>>>>>> >>>>>>>> When you say dynamic changes, it means application level memory >>>>>>>> proection, space quota management etc. ? I know you should be having a >>>>>>>> full >>>>>>>> list, so l am willing to hear all that and then decide which work >>>>>>>> should be >>>>>>>> done first and how I propose to do it. >>>>>>>> >>>>>>>> >>>>>>> Dynamic here means the MMU entries can be changed at run-time after >>>>>>> initialization. This is a building block for implementing higher-level >>>>>>> services such as application-level memory protection and kernel-level >>>>>>> APIs >>>>>>> for memory management. >>>>>>> >>>>>>> >>>>>>>> * Creating generally useful memory protection schemes such as >>>>>>>>> per-task stack protection that can be enabled by applications with >>>>>>>>> simple >>>>>>>>> "switch it on" type of logic. >>>>>>>>> >>>>>>>> * Creating an application-layer interface for memory protection >>>>>>>>> management at a finer granularity / with more application-level logic >>>>>>>>> to >>>>>>>>> control than the "generally useful" approaches would need. >>>>>>>>> >>>>>>>>> Ok this is exciting stuff that can be pushed first, the memory >>>>>>>> block or segement(or whatever you say to a chunk but mostly I went >>>>>>>> through >>>>>>>> thesis material online which denotes it as in different terms/name ) >>>>>>>> access >>>>>>>> related control can be hacked together to provide the enclaved type of >>>>>>>> execution for the application task. We can discuss more about it and >>>>>>>> how >>>>>>>> much existing code base so far support this proposed project area. >>>>>>>> >>>>>>>> I prefer memory region to refer to a generic "Base+Offset" >>>>>>> contiguous area of memory. We have discussed terminology quite often in >>>>>>> the >>>>>>> past. Reach out to Hesham to get some more details. >>>>>>> >>>>>> >>>>>>> We can't do application-level memory protection without a good >>>>>>> understanding of the intermediate layers. We can start to design an API, >>>>>>> but the API is not mergeable until there is a generic layer that is not >>>>>>> tightly bound to the BSP or even CPU layers. >>>>>>> >>>>>> >>>>>> In case of arm-cp15 it's underlying fucntionality are far more >>>>>> developed(i.e. initialization, interrupt handling, underlying tlb update >>>>>> after fage faults etc.) than the rest of the bsp's, so I think we can >>>>>> start >>>>>> to design an API for application-level memory protection. This way we can >>>>>> have atleast one fully functional bsp for arm-cp 15, whose prototype can >>>>>> we >>>>>> can later use to speed up the development You think it can be a good >>>>>> proposal or shall I go with other bsp underlying support first? >>>>>> >>>>>>> >>>>>>> >>>>>> I'm concerned that any mid-level/high-level framework built on top of >>>>> the existing low-level support for arm-cp15 will be too rigid to work with >>>>> less feature-ful BSPs/MMU/MPU combinations. It would be good to have >>>>> another one or two kinds of MMU/MPU supported so that the upper layers can >>>>> be more thoughtfully designed. >>>>> >>>>> >>>> I agree with your approach of having more than one type of bsp's with >>>> MMU/MPU support, so which one should I take on ? I mean I can work on >>>> AT91RM9200 of ARM family, or you would suggest other archiitecture >>>> like(PowerPC) ? >>>> >>>> PowerPC should be good. That was one of the targets worked on >>> previously, so it should not be too difficult. >>> >>> >>>> I look forward, to hear what is your take on them, and last but not the >>>>>>>> least, thanks for the warm reply, it already makes me feel home with >>>>>>>> the >>>>>>>> community. >>>>>>>> >>>>>>>> >>>>>>> Overall, I look forward to working with the community and improving >>>>>>>>>> my skills by actively contributing to the project(in long run also). >>>>>>>>>> >>>>>>>>>> *Closing with thank you and warm Regards,* >>>>>>>>>> >>>>>>>>>> *Abhimanyu Rawat* >>>>>>>>>> *M.E. Computer Science, * >>>>>>>>>> *CS/IS Department, BITS Pilani, Pilani Campus* >>>>>>>>>> *Email - h2015...@pilani.bits-pilani.ac.in >>>>>>>>>> <h2015...@pilani.bits-pilani.ac.in> / abhimanyura...@yahoo.com >>>>>>>>>> <abhimanyura...@yahoo.com>* >>>>>>>>>> *Phone. 08930399302 (call/Whatsapp), 09466899302* >>>>>>>>>> >>>>>>>>>> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ >>>>>>>>>> ᐧ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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
