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
Fri Mar 29 17:50:11 UTC 2013


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/20130329/898d5bb4/attachment-0001.html>


More information about the devel mailing list