A Well Defined Framework Design and Implementation for RTEMS MMU(Peng Fan -Gsoc2013 proposal) (van.freenix at gmail.com)

Gedare Bloom gedare at rtems.org
Tue Apr 9 16:30:33 UTC 2013 

Please be sure to coordinate your efforts with Hesham so that you don't
both propose too much overlap. Also, make sure neither of your
proposals/projects is dependent on the other one. More inline below:


On Sun, Apr 7, 2013 at 11:38 PM, Peng Fan <van.freenix at gmail.com> wrote:

> Hi,
> I have draw a graph to show the basic idea , not software framework. The
> graph is following the text. The graph can also be accessed from here<https://docs.google.com/drawings/d/1vexi53qy0fR9JPujzi02erKy0S8246sVqXtPwWGJ48s/edit?usp=sharing>
> .
>
> I want to implement both static mapping and dynamic mapping. Both supports
> dynamic attributes.
> Everything in the framework can be configured depending on what is needed
> in the development.
> MMU/MPU can be disabled or enabled.If enabled, you can choose
> coarse-grained mem block or fine-grained mem block.
> MPU only supports coarse-grained mem block, such as Region in ARM MPU.
>
> I think the static mapping is best done at the lower level, at least for
now. Later we can consider some way for application developers to modify
the static mapping within the bounds supported by the HW and the linkcmds.


> The 2nd level page table is also  supported if fine-grained mem block
> enabled. This may incur tlb miss.
> I have a few questions about 2nd level page.In the mailing list, I found
> this:
>
> "
>
> Yes I overlooked that point.. The "Why" factor.
>
> The number of pages that can be used at one time is a concern for
> creating either static or dynamic use of MMU. Using big pages allows
> to have a finite number of pages and well-defined "zones" of memory.
> Big pages also typically map onto the MMU's TLB directly. Small pages
> may permit greater flexibility over the memory mapping, but lets a
> developer shoot their foot by using more pages than the TLB can
> support and thus induce page faults. We must avoid page faults.
>
> On Tue, Aug 7, 2012 at 3:32 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de <http://www.rtems.org/mailman/listinfo/rtems-devel>> wrote:
> >* I don't think 2nd level MMU support makes sense for a real-time operating*>* system.*>
>
> "
> why 2nd level MMU support makes no sense?vxworks supports 2nd level.QNX
> has long offered complete memory protection.
> is the time is indefinite because tlb miss?
> If the page faults that caused by tlb miss is the reason, I think this can
> be handled by low level code.Sure, no swapping.
> 2nd level is a must in fine-grained mem block, I think.
> If I want to protect the private data of the process of only KBs, MBs'
> protection is too big. If another process's private data is
> also contained in the MBs, this may incur errors.
> Anyhow, all is configurable, fine or coarse-grained, dynamic or static
> mapping, mmu enable or disable.
> any comments? Thanks.
>
In a real-time system, the overhead to handle a TLB miss is problematic. We
cannot allow a TLB miss to happen in application code. So, the TLB needs to
be pre-filled with all of the valid mappings. Even with dynamic changes, we
should limit the overhead of flushing/filling the MMU/MPU structures and
align the costs with well-defined boundaries preferably in a non-realtime
task, such as during initialization or dynamic linking. Architectures that
support selective modification of the MMU/MPU can support dynamic changes
in a context switch, but if a dynamic change on some MMU requires flushing
the TLB or (worse) the cache, then I don't think anyone will find the
dynamic changes tenable for a realtime application.

-Gedare



> [image: 内嵌图片 4]
> Regards,
> Peng.
>
> 2013/3/30 Peng Fan <van.freenix at gmail.com>
>
>> Hi,
>> The doc is just for learning  and I'll put the reference sources there.I
>> am not intended to volatile any international copyright laws and hope it
>> may not.
>> I am still thinking about how to design the framework and I'll put it in
>> another doc.
>>
>> Regards,
>> Peng.
>>
>>
>>
>> 2013/3/30 Gedare Bloom <gedare at rtems.org>
>>
>>> I have some concern about where your information has come from on these
>>> design notes. Please be sure not to violate any international copyright
>>> laws in your work. It would be best if you can point to official vxworks
>>> documentation or reference sources.
>>>
>>> -Gedare
>>>
>>>
>>> On Fri, Mar 29, 2013 at 1:50 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>>> This is pretty good. Please note that we do not want to copy the design
>>>> (unless it is good!), and definitely none of the code! While you're looking
>>>> at this, maybe including what some other open RTOSs support would be a good
>>>> idea.
>>>>
>>>> What we need to get to is a set of requirements for MMU/MPU management.
>>>> Then we can work on an RTEMS design to satisfy those requirements.
>>>>
>>>> -Gedare
>>>>
>>>>
>>>> On Fri, Mar 29, 2013 at 9:02 AM, Peng Fan <van.freenix at gmail.com>wrote:
>>>>
>>>>> I have write a simple document of mmu of vxworks.I hope it maybe
>>>>> useful for the design of rtems mmu.
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1-f9bb_3H14SZr9d8GvA5KJGOcP8l2QjIwxTYkMMHTGU/edit?usp=sharing
>>>>>
>>>>> Anyone can comments.There might be some errors and thanks for your
>>>>> pointing it out.
>>>>>
>>>>> Regards,
>>>>> Peng
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Gedare Bloom <gedare at rtems.org>
>>>>> Date: 2013/3/27
>>>>> Subject: Re: A Well Defined Framework Design and Implementation for
>>>>> RTEMS MMU(Peng Fan -Gsoc2013 proposal) (van.freenix at gmail.com)
>>>>> To: Peng Fan <van.freenix at gmail.com>
>>>>> Cc: Joel Sherrill <joel.sherrill at gmail.com>
>>>>>
>>>>>
>>>>> Please consider sending your thoughts to rtems-devel mailing list.
>>>>>
>>>>>
>>>>> On Wed, Mar 27, 2013 at 12:55 AM, Peng Fan <van.freenix at gmail.com>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The following is a few of my thoughts.
>>>>>>
>>>>>>  1.The mmu management part of section 3.8
>>>>>> 1.1
>>>>>>     The following is based on dynamic MMU management.
>>>>>> 1.1.1
>>>>>>     a section is big block memory that is mapped to a task's address
>>>>>> space.The map is done when the task allocates the section. a segment is
>>>>>> allocated from a section. The protection level is on the section level.
>>>>>> right? I am confused with Partion of 3.8.3 that why protection is on the
>>>>>> partition level.I think Partition should be a fine-grained  memory within
>>>>>> the coarse-grained section.
>>>>>>
>>>>> Section may be some architecture-dependent feature. The focus of the
>>>>> document I sent was the MMU support for M68851 and M68030. We want to
>>>>> consider many more CPUs and MMU/MPU combinations.
>>>>>
>>>>>  A partition is a different construct than a region. Try not to
>>>>> conflate the two ideas.
>>>>>
>>>>> A region lets a task allocate segments. The point of 3.8.2 is that the
>>>>> region does not need to be mapped into each task's address space, only the
>>>>> allocating task needs to have access to the entire region. Any other tasks
>>>>> that share the region can be given access to only the requested segments.
>>>>>
>>>>> A partition lets a task allocate buffers. The entire partition is
>>>>> mapped into a task's address space, and every task sharing the partition
>>>>> will have access to all of the buffers allocated from it.
>>>>>
>>>>>
>>>>>
>>>>>> 1.1.2
>>>>>>    In the current implementation of rtems, different tasks can get
>>>>>> region or partition buffer from a region or partition?
>>>>>> I am not sure about this. a section is owned to a task. Thus, can
>>>>>> different tasks get buffer from regions allocated from section?Maybe it's
>>>>>> not thread safe. Maybe an attribute shoule be added to section to indicate
>>>>>> whether it's a section can be shared by different tasks or it's owned only
>>>>>> by
>>>>>> one task.
>>>>>>
>>>>>> There is no idea of ownership or protection in RTEMS right now. RTEMS
>>>>> implements a single address space. You can read the current documentation
>>>>> at
>>>>> http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/index.html
>>>>>
>>>>> How best to deal with ownership of memory ranges remains an open
>>>>> question.
>>>>>
>>>>>
>>>>>> 1.2
>>>>>> About MPU related.
>>>>>> You said Some developers maybe want a better way to create the static
>>>>>> mapping but do not care about dynamic,especially on systems without a true
>>>>>> mmu but just using a mpu. I think the static mapping related data structure
>>>>>> should be defined in the Mid level,the mapping table just like mem_map
>>>>>> should be static defined in Low level.The static mapping related interfaces
>>>>>> should not be exposed to application but application wants to change the
>>>>>> attributes of the static mapping. The high level api in my opinion is
>>>>>> exposed only to application layer just like the rtems's C manual listed.
>>>>>>
>>>>>> Sure, but we still need to provide a way to modify or configure the
>>>>> static mapping without a user needing to modify the BSP code. Although, I'm
>>>>> not entirely sure how feasible it is to provide an alternate static mapping
>>>>> without changing some BSP files like the linker script (linkcmds).
>>>>>
>>>>>
>>>>>> 2.  About "page"
>>>>>> The page in my proposal should be the same with the section in 1.1.1.
>>>>>> I just have no good words to express my meaning. I searched the mailing
>>>>>> list and I found TLB related problems. Maybe fine-grained mem block should
>>>>>> be allocated through region or partition but not two-level page tables.
>>>>>> Because TLB fault should be handled carefully especially for MIPS in low
>>>>>> level code,  if two level page tables are implemented.
>>>>>>
>>>>>> Discuss this with Hesham and ask for access to his prior documents.
>>>>> We went back and forth about this issue. The main problem is that different
>>>>> architectures define different terminology, e.g. section, page, segment,
>>>>> and so forth.
>>>>>
>>>>> I don't think we should right now implement any interfaces that rely
>>>>> on page tables. Instead we should translate the capabilities of different
>>>>> MMU/MPU hardware to support static and dynamic memory mappings/protection.
>>>>>
>>>>>
>>>>>> 3. About VxVMI
>>>>>> I am still reading the docs and code to give myself a basic framework
>>>>>> of vxworks'MMU design.I'll give my feedback about this soon.
>>>>>>
>>>>> OK. I'm not really that familiar with it myself, so a report would be
>>>>> helpful to me.
>>>>>
>>>>>
>>>>>>
>>>>>> 4. About the platform
>>>>>> what I have now are only a pandaboard(omap4460) and a s3c6410
>>>>>> development board,but there are no rtems bsp for this.which platform do you
>>>>>> suggest me to use? If needed, I may port it to qemu to facilitate debugging.
>>>>>>
>>>>>> Use a simulator. For powerpc we have MMU support working on psim,
>>>>> which is based in GDB. I don't know how many of the other GDB simulators
>>>>> implement MMU features in their simulators. Hesham I think had gumstix with
>>>>> skyeye sort of working, but I think he said the Skyeye does not really
>>>>> implement the MMU. I think Qemu would be useful, if you can find the right
>>>>> cpu/BSP in RTEMS to use on Qemu. You'd have to ask on rtems-users about
>>>>> what BSPs people might be using on Qemu.
>>>>>
>>>>> The advantage of a simulator is that it makes it easier for others to
>>>>> try out your work and give feedback.
>>>>>
>>>>> I would also encourage you to try using the Panda board with the BSP
>>>>> support provided by a student from last year's GSOC, Xi Yang
>>>>> hiyangxi at gmail.com whose code I don't think has been merged yet, but
>>>>> provides OMAP support so that RTEMS can run on the small MCUs and
>>>>> interoperate with Linux on the main processor. It would be great if you can
>>>>> try to get that platform to work, as it would give another verification for
>>>>> us that the BSP support works. Right now, only Xi has tested it. You'll
>>>>> have to contact him for more details.
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Peng
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/3/26 Peng Fan <van.freenix at gmail.com>
>>>>>>
>>>>>>> Thanks for your reply. I'll read the documents listed in the mail
>>>>>>> and search through the mailing lists.
>>>>>>> The picture in the proposal maybe is not so clear.Anyhow, I will
>>>>>>> read the docs first. Thanks again.
>>>>>>>
>>>>>>>
>>>>>>> 2013/3/26 Joel Sherrill <joel.sherrill at gmail.com>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 25, 2013 at 11:47 AM, Gedare Bloom <gedare at rtems.org>wrote:
>>>>>>>>
>>>>>>>>> A clean room implementation of VxVMI would be a good place to
>>>>>>>>> start, albeit with RTEMS-branded interface names; but a clear relationship
>>>>>>>>> between the two can make someone's porting job (or adding to OSAL) easier.
>>>>>>>>> You can also look for info about RTP "Real-Time Processes".. I'm not
>>>>>>>>> convinced they are "Real-time" but that is another VxWorks artifact that
>>>>>>>>> might inform design decisions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> For better or worse, we get compared to VxWorks. :(
>>>>>>>>
>>>>>>>> VxVMI at least gives a concrete example of what capabilities are
>>>>>>>> useful.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mon, Mar 25, 2013 at 12:28 PM, Joel Sherrill <
>>>>>>>>> joel.sherrill at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 25, 2013 at 10:25 AM, Gedare Bloom <gedare at rtems.org>wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> You can search through rtems-devel mailing list for some various
>>>>>>>>>>> conversations we have had related to memory protection / MMU support.
>>>>>>>>>>> (Somehow I think you can make Google search only in the rtems-devel mailing
>>>>>>>>>>> list archive, but I don't recall offhand the Google-fu required to make
>>>>>>>>>>> that work.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> MMU site:www.rtems.org/pipermail/rtems-devel/
>>>>>>>>>>
>>>>>>>>>> With "site:" you can restrict the search to a domain or a
>>>>>>>>>> starting path.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>  It may also make sense to divide the low-level/mid-level work
>>>>>>>>>>> to be done between you and Hesham. For example, you might identify if there
>>>>>>>>>>> are any MIPS or X86 targets that could benefit from the low-level MMU
>>>>>>>>>>> implementation. I believe Hesham will focus on the ARM and PowerPC.
>>>>>>>>>>>
>>>>>>>>>>> Please note that not all MMU will support the notion of paging.
>>>>>>>>>>> We need to have a good idea of the requirements for high-level MMU support.
>>>>>>>>>>> Some developers maybe want a better way to create the static mapping but do
>>>>>>>>>>> not care about dynamic, especially on systems without a true MMU but just
>>>>>>>>>>> using an MPU. Others might want the dynamic support, but only some of the
>>>>>>>>>>> time.
>>>>>>>>>>>
>>>>>>>>>>> Another place to look is at the original documentation for RTEMS
>>>>>>>>>>> specifications. Although ORKID did not provide for MMU management, RTEID
>>>>>>>>>>> did so, and I am attaching the relevant documentation set here. See section
>>>>>>>>>>> 3.8 MMU Management for some ideas. This documentation gives some ideas
>>>>>>>>>>> about how to use an MMU with the Regions and Partitions services, and
>>>>>>>>>>> provides some high-level interface definitions that might be useful for how
>>>>>>>>>>> we think about dynamic MMU management.
>>>>>>>>>>>
>>>>>>>>>>> Other sources of information include... other RTOSes. A quick
>>>>>>>>>> Google turned up this
>>>>>>>>>> which gives some insight:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.uio.no/studier/emner/matnat/fys/FYS4220/h11/undervisningsmateriale/laboppgaver-rt/vxworks_architecture_supplement_6.2.pdf
>>>>>>>>>>
>>>>>>>>>> VxVMI is Wind River's product in this domain. Any references to
>>>>>>>>>> this product
>>>>>>>>>> will help formulate use cases. I found this by Paul Chen who I
>>>>>>>>>> have actually worked
>>>>>>>>>> with on a standards effort:
>>>>>>>>>>
>>>>>>>>>> http://ftp.ruigongye.com/200804/wp_vxworks_vxvmi.pdf
>>>>>>>>>>
>>>>>>>>>> Here are a couple of man pages for their vmlib()
>>>>>>>>>>
>>>>>>>>>> http://www.vxdev.com/docs/vx55man/vxworks/ref/vmLib.html
>>>>>>>>>> http://www.vxdev.com/docs/vx55man/vxworks/ref/vmShow.html
>>>>>>>>>>
>>>>>>>>>> And the manual.
>>>>>>>>>>
>>>>>>>>>> http://www.vxdev.com/docs/vx55man/vxworks/guide/c-vm.html
>>>>>>>>>>
>>>>>>>>>> VxVMI is AFAIK the base set of capabilities we need to have to
>>>>>>>>>> be competitive.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -Gedare
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Mar 24, 2013 at 11:09 PM, Peng Fan <
>>>>>>>>>>> van.freenix at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi joel,Gedare.
>>>>>>>>>>>>      I have just finished a draft of my proposal.Hope you can
>>>>>>>>>>>> give me some advice.
>>>>>>>>>>>>      I have contacted Heshman.He said that he intends to
>>>>>>>>>>>> enhance low-level/Mid-level APIs.
>>>>>>>>>>>>      Thus I think I may work on high-level API design.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 在 2013年3月25日上午11:04，Peng Fan (Google 云端硬盘) <
>>>>>>>>>>>> van.freenix at gmail.com>写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> 我与您共享了一个项。
>>>>>>>>>>>>>  [image: 文档] A Well Defined Framework Design and
>>>>>>>>>>>>> Implementation for RTEMS MMU(Peng Fan -Gsoc2013 proposal)<https://docs.google.com/document/d/1lZINtGmSw5HFgdmvAQM0b2B1aAvervFoIZNAArGIAig/edit?usp=sharing>
>>>>>>>>>>>>> Google 云端硬盘：在同一位置创建、共享和保存您的所有资料。 [image: Google 云端硬盘的徽标]<https://drive.google.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130409/864bfe52/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flow.png
Type: image/png
Size: 41467 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130409/864bfe52/attachment-0001.png>

More information about the devel mailing list