gsoc2013-patch and questions

[Peng Fan]

2013/3/22 Gedare Bloom <gedare at rtems.org>

> I am CC'ing the student who worked on this last year. I think he might
> also be planning to submit a proposal about the MMU support again this
> year. You two should attempt to coordinate if possible to avoid having
> overlapping proposals. It may be possible that there is enough work
> for two MMU related projects, but that would need to be handled with
> care.
>
> Thanks.I will coordinate with Hesham.

>
> On Fri, Mar 22, 2013 at 9:01 AM, Peng Fan <van.freenix at gmail.com> wrote:
> > I have a few questions about "mmu support".
> > I read the low level code about mmu  of arm. The map table is statically
> set
> > in mem_map, and the initialization code is mmu_init.
> This code has not been updated with any results from past GSoC, which
> did some work with the ARM MMU. I don't know how much of what was done
> in the past will be kept. You do have the basic idea of what is in
> place, though.
>
> > All the code realated to mmu is here? If so, thus the flexibility is not
> so
> > good. Because when application want to allocate a mem block,
> > the attributes can not be modified.
> Correct. Right now, each CPU or BSP implements its own MMU handling
> just enough to make use of the physical memory. Since RTEMS is a
> "single address space" operating system, the MMU does not strictly
> need to do more than the bare minimum required to make the
> architecture usable. For systems that require virtual memory, the
> common solution is to make a one-to-one mapping between virtual and
> physical memory.
>
> > The goal of the mmu support is to implemented a well defined framework in
> > which  middle level  APIs  exposed to application developers, a two level
> > table implementation  and low level APIs(a common interface that can be
> > called from middle level apis, I am not sure ). We can use these middle
> > level  APIs to give each mem block its own attributes.
> You have the right idea. Our current thinking is to figure out the
> low-level infrastructure and fill in the implementations for a few
> BSPs, for example some more ARM or PowerPC BSPs. Then we can think
> about how applications or libraries might be able to use such
> low-level support to make useful memory-related services.
>
> The immediate goal that I see is to unify the various approaches to
> MMU/MPU management (initialization with a static map, support for
> dynamic changes) in the lowest level. Then we will have a clearer
> picture of what kind of higher-level services are even possible to
> provide.
>
Just my current thoughts.
1. Define the attributes ;define data structures related to each task
2. Define the high level API
3. Define the low level API ( step 2 and 3 may begin simultaneously )
4. Implement the map between high and low
It may be not so simple though. I think I should dig into the  mem and task
related code.
Is this the right way? Thanks.


> > I am not definitely sure what I think is right.Maybe it's totally wrong.I
> > just want to give myself a clear understanding.
> > Thanks for your reply.
> >
> >
> > 2013/3/22 Peng Fan <van.freenix at gmail.com>
> >>
> >> Hi all,
> >>         I followed the "GSoC_Getting_Started" , modified init.c of the
> >> hello sample and used "git diff master mybranch" to get the      patch.
> >>        I am new to gsoc,so there maybe something wrong with what I have
> >> done.I hope you can point it out.I will appreciate your help.I am
> interested
> >> in "mmu support" and "improvements on smp support" listed on the "Open
> >> projects" page. I am reading the mmu code written in gsoc2012. In the
> code,
> >> it uses 1MB section as a unit.Is it coases-grained or too large? why
> not use
> >> 4kB page as a fine-grained unit?
> >>       Anyone can give me some advice about who should i contact about
> the
> >> proposal?Thanks very much.
> >>
> >
> >
> >
> > _______________________________________________
> > rtems-devel mailing list
> > rtems-devel at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130323/95bc893d/attachment-0001.html>