On Sat, Mar 25, 2017 at 6:07 AM, Gedare Bloom <ged...@rtems.org> wrote:
> Work on shaping your proposal document and start to plan the work you > would do during the summer. This is the best way for me to collaborate is > if you begin writing out your ideas in sufficient detail that I can > understand and provide feedback based on where you are at. > +1 > > On Fri, Mar 24, 2017 at 11:26 AM, Abhimanyu Rawat < > h2015...@pilani.bits-pilani.ac.in> wrote: > >> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ᐧ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> ᐧ >>>>>> >>>>> >>>>> >>>> >>> >> > -- Hesham
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
