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