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? ᐧ
*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
