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

Peng Fan van.freenix at gmail.com
Sat Mar 30 01:42:11 UTC 2013 

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/20130330/1bc1c327/attachment-0001.html>

More information about the devel mailing list