<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/22 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am CC'ing the student who worked on this last year. I think he might<br>
also be planning to submit a proposal about the MMU support again this<br>
year. You two should attempt to coordinate if possible to avoid having<br>
overlapping proposals. It may be possible that there is enough work<br>
for two MMU related projects, but that would need to be handled with<br>
care.<br><br></blockquote><div>Thanks.I will coordinate with Hesham. <br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
On Fri, Mar 22, 2013 at 9:01 AM, Peng Fan <<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>> wrote:<br>
> I have a few questions about "mmu support".<br>
> I read the low level code about mmu of arm. The map table is statically set<br>
> in mem_map, and the initialization code is mmu_init.<br>
</div>This code has not been updated with any results from past GSoC, which<br>
did some work with the ARM MMU. I don't know how much of what was done<br>
in the past will be kept. You do have the basic idea of what is in<br>
place, though.<br>
<div><br>
> All the code realated to mmu is here? If so, thus the flexibility is not so<br>
> good. Because when application want to allocate a mem block,<br>
> the attributes can not be modified.<br>
</div>Correct. Right now, each CPU or BSP implements its own MMU handling<br>
just enough to make use of the physical memory. Since RTEMS is a<br>
"single address space" operating system, the MMU does not strictly<br>
need to do more than the bare minimum required to make the<br>
architecture usable. For systems that require virtual memory, the<br>
common solution is to make a one-to-one mapping between virtual and<br>
physical memory.<br>
<div><br>
> The goal of the mmu support is to implemented a well defined framework in<br>
> which middle level APIs exposed to application developers, a two level<br>
> table implementation and low level APIs(a common interface that can be<br>
> called from middle level apis, I am not sure ). We can use these middle<br>
> level APIs to give each mem block its own attributes.<br>
</div>You have the right idea. Our current thinking is to figure out the<br>
low-level infrastructure and fill in the implementations for a few<br>
BSPs, for example some more ARM or PowerPC BSPs. Then we can think<br>
about how applications or libraries might be able to use such<br>
low-level support to make useful memory-related services.<br>
<br>
The immediate goal that I see is to unify the various approaches to<br>
MMU/MPU management (initialization with a static map, support for<br>
dynamic changes) in the lowest level. Then we will have a clearer<br>
picture of what kind of higher-level services are even possible to<br>
provide.<br></blockquote><div>Just my current thoughts.<br></div><div>1. Define the attributes ;define data structures related to each task<br></div><div>2. Define the high level API<br></div><div>3. Define the low level API ( step 2 and 3 may begin simultaneously )<br>
</div><div>4. Implement the map between high and low<br></div><div>It may be not so simple though. I think I should dig into the mem and task related code.<br></div><div>Is this the right way? Thanks.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> I am not definitely sure what I think is right.Maybe it's totally wrong.I<br>
> just want to give myself a clear understanding.<br>
> Thanks for your reply.<br>
><br>
><br>
> 2013/3/22 Peng Fan <<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>><br>
>><br>
>> Hi all,<br>
>> I followed the "GSoC_Getting_Started" , modified init.c of the<br>
>> hello sample and used "git diff master mybranch" to get the patch.<br>
>> I am new to gsoc,so there maybe something wrong with what I have<br>
>> done.I hope you can point it out.I will appreciate your help.I am interested<br>
>> in "mmu support" and "improvements on smp support" listed on the "Open<br>
>> projects" page. I am reading the mmu code written in gsoc2012. In the code,<br>
>> it uses 1MB section as a unit.Is it coases-grained or too large? why not use<br>
>> 4kB page as a fine-grained unit?<br>
>> Anyone can give me some advice about who should i contact about the<br>
>> proposal?Thanks very much.<br>
>><br>
><br>
><br>
><br>
</div><div><div>> _______________________________________________<br>
> rtems-devel mailing list<br>
> <a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
><br>
</div></div></blockquote></div><br></div></div>