<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 11"><meta name="Originator" content="Microsoft Word 11"><link rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cxur%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml"><style>
<!--
/* Font Definitions */
@font-face
{font-family:ËÎÌå;
panose-1:2 1 6 0 3 1 1 1 1 1;
mso-font-alt:SimSun;
mso-font-charset:134;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
{font-family:"\@ËÎÌå";
panose-1:2 1 6 0 3 1 1 1 1 1;
mso-font-charset:134;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:3 135135232 16 0 262145 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
mso-pagination:none;
font-size:10.5pt;
mso-bidi-font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:ËÎÌå;
mso-font-kerning:1.0pt;}
/* Page Definitions */
@page
{mso-page-border-surround-header:no;
mso-page-border-surround-footer:no;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style>
<p class="MsoNormal"><span lang="EN-US">One of the item I put in rtems wishing list
has something in common to this is proposal. However, I just want to put MMU
and page system to RTEMS memory management. This proposal is more focus on divide
user mode and supervisor mode.</span></p>
<p class="MsoNormal"><span lang="EN-US">I think this will be a tough job for only
one or two people. Also, if we want to implement this mode, lots of driver/BSP
might need to change when user what to put data from App to HW. And, how to support
both non-MMU and MMU processor is another problem.</span></p>
<br><br><div class="gmail_quote">2008/4/28 Metge Jean-Jacques <<a href="mailto:jean-jacques.metge@cnes.fr">jean-jacques.metge@cnes.fr</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear all,<br>
<br>
I would like to re-open a july 2007 discussion about time and space<br>
partitionnig with RTEMS (see below).<br>
Based on my past experience of ARINC653 development in aeronautics<br>
domain, I really think, as Joel wrote in july 2007, that space community<br>
(at least), which is an important user community of RTEMS products,<br>
could get a big added-value from splitting RTEMS in 2 separate layers :<br>
- 1 low level and very light layer (let's call it "RTEMS level 1"),<br>
usually called "hypervisor", running in supervisor mode, aiming at<br>
creating robust partitions in the sense of ARINC653 standard (ie<br>
dedicated memory zones, dedicated I/O zones and appropriate time slices,<br>
with appropriate protections and monitoring). This supervisor should<br>
rely on a hardware MMU, meaning that appropriate hardware function<br>
should be specifically developed for the LEON processor<br>
- 1 medium level layer (let's call it "RTEMS level 2"), sometimes called<br>
"partition OS", running in user mode, to be hosted, if requested by one<br>
or several users, in one or several of the created partitions.(*)<br>
<br>
(*) The upper layer being the software applications themselves.<br>
Note that a the decision to use or not RTEMS layer 2 as partition OS is<br>
totally let to any user, which may prefer to develop its own basic<br>
software or to adapt its own usual OS on top of RTEMS level 1.<br>
<br>
In order to concretly progress on this ambitious topic (I think), my<br>
current idea would be to :<br>
- first, develop a new "2-layers RTEMS" prototype (to be ran on ground,<br>
on an existing LEON board prototype), to be derived from an existing<br>
RTEMS version for LEON, in order to validate the concept<br>
- in a second step, develop, on the basis on this prototype, a new RTEMS<br>
open source version, compatible with LEON processor, and compatible with<br>
software development standards applicable to space on board software.<br>
<br>
Does anybody feels some interest with this exercise ?<br>
Does anybody already works on this idea and could be ready to provide<br>
some helps and/or to exchange some technical views ?<br>
<br>
Thank you by adavance for your attention.<br>
<br>
Regards<br>
<br>
Jean-Jacques<br>
<br>
========================================================================<br>
========<br>
<br>
<br>
<br>
RFC - Memory Partitioning<br>
<br>
* Date: Tue, 24 Jul 2007 10:19:08 -0500<br>
* From: joel.sherrill at <a href="http://oarcorp.com" target="_blank">oarcorp.com</a> (Joel Sherrill)<br>
* Subject: RFC - Memory Partitioning<br>
<br>
Robert S. Grimes wrote:<br>
> I've been thinking about this for a while too. I haven't anything too<br>
> concrete to suggest at this time, but I don't want to see your post<br>
die<br>
> on the vine. I do have some observations about the nature of the<br>
> proposed beast...<br>
><br>
> One thought is that this move could result in the POSIX API becoming<br>
> more in line with other implementations, if each "partition" could act<br>
> as a "process" in the proposed RTEMS. This would allow developers the<br>
> usual choices of multi-process, multi-threaded (I like to think of<br>
RTEMS<br>
> "tasks", in traditional API-speak, as "threads"), or combinations.<br>
><br>
><br>
I think you proposed using a hypervisor to put each<br>
RTEMS "process" inside its own container. Then you could<br>
get ARINC separation. Without reading the standard, could<br>
we implement an ARINC 653 manager that each RTEMS<br>
application runs inside of?<br>
> Another thought is that truly hard-real-time activities could run in a<br>
> suitably "high priority" partition, using such things as the rate<br>
> monotonic scheduler, and softer code then could run in other<br>
partitions.<br>
><br>
> I certainly would not want to eliminate the current model of RTEMS,<br>
> especially wrt low overhead, high performance on "smaller" systems,<br>
> especially those without MMU. A rather simple-minded idea could be to<br>
> think of such systems as "single partition" systems, which might lead<br>
to<br>
> a useful guiding principle: In the proposed new RTEMS, a single<br>
> partition looks, acts, feels, sounds, smells, etc. like a traditional<br>
> RTEMS system.<br>
><br>
I think this is the way to go. Writing trap interfaces<br>
for god knows how many services, dealing with the<br>
known memory issues (e.g. copying buffers, mapping<br>
memory, etc.), and who knows what else will be a significant<br>
undertaking.<br>
<br>
Approaching the problem by writing an ARINC 653 hypervisor<br>
will be more definable and give more value in the end to<br>
the RTEMS Experience. :)<br>
<br>
I think this approach would have extremely high value for<br>
the community and I would like to see it as a project.<br>
If there is interest, users from the space and aviation<br>
communities should be able to help sponsor this.<br>
<br>
> Just my $0.02, adjusted for inflation...<br>
><br>
My opinion's value is about the same. :)<br>
> -Bob<br>
><br>
> Charles Steaderman wrote:<br>
><br>
>> RFC<br>
>><br>
>> Memory Partitioning Support in RTEMS<br>
>><br>
>> Goals:<br>
>> Provide task level code and memory partitioning for RTEMS. The short<br>
>> term goal would be for a project that contains functionality to be<br>
FAA<br>
>> certified at different certification levels (background data<br>
>> collection and storage certified to FAA Level C, and user interface<br>
>> non-certified).<br>
>><br>
>> Proposed Strategy:<br>
>> Based upon some research into commercial partitioned embedded OSes<br>
>> (Integrity, Nucleus Secure, etc), I would like to suggest the<br>
>> following strategy for enhancing RTEMS. First, to provide separation<br>
>> from the kernel, I would propose that all RTEMS kernel calls be<br>
>> accessed via a TRAP or SWI. In this way, the kernel code can be<br>
mapped<br>
>> into a non-accessable memory area in order to provide protection from<br>
>> userland tasks. Second, I would propose that task creation and<br>
context<br>
>> switching become memory region aware. Task creation would need to be<br>
>> supplied memory regions and access permissions and those permissions<br>
>> would need to be updated on a context switch (MMU registers). In<br>
>> addition, each task could have its own private memory heap for<br>
dynamic<br>
>> memory allocation. This would mean that memory allocation would need<br>
>> to be told whether the allocation should come from the local or<br>
global<br>
>> heap.<br>
>><br>
>> I am sure that there is a large number of issues that I have<br>
>> overlooked, but I would like to get people thinking about<br>
partitioning<br>
>> in RTEMS. In much the same way that desktop operating systems have<br>
>> benefitted from process protectsion (Win9x vs. WinNT or OS 9 vs. OS<br>
>> X), I think that given the present and future state of embedded<br>
>> hardware, embedded systems could benefit from the same robustness.<br>
One<br>
>> advantage that I believe the proposed solution has is that the code<br>
>> resides in a single address space, rather than virtual memory spaces.<br>
>> Perhaps this will cause problems with library calls and shared code,<br>
>> but perhaps there is a novel solution that we could employ.<br>
>><br>
>> Thank you for your time and consideration.<br>
>><br>
>> - Charlie<br>
>><br>
>> _______________________________________________<br>
>> rtems-users mailing list<br>
>> rtems-users at <a href="http://rtems.com" target="_blank">rtems.com</a><br>
>> <a href="http://rtems.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://rtems.rtems.org/mailman/listinfo/rtems-users</a><br>
>><br>
>><br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> rtems-users at <a href="http://rtems.com" target="_blank">rtems.com</a><br>
> <a href="http://rtems.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://rtems.rtems.org/mailman/listinfo/rtems-users</a><br>
><br>
<br>
<br>
<br>
* References:<br>
* RFC - Memory Partitioning <msg00084.html><br>
* From: charlies at <a href="http://poliac.com" target="_blank">poliac.com</a> (Charles Steaderman)<br>
* RFC - Memory Partitioning <msg00086.html><br>
* From: rsg at <a href="http://alum.mit.edu" target="_blank">alum.mit.edu</a> (Robert S. Grimes)<br>
* Prev by Date: RFC - Memory Partitioning <msg00086.html><br>
* Next by Date: GameBoy Advance BSP <msg00088.html><br>
* Previous by thread: RFC - Memory Partitioning <msg00086.html><br>
* Next by thread: RTEMS and I2C APIs <msg00111.html><br>
* Index(es):<br>
* Date <date1.html><br>
Thread<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a><br>
<a href="http://rtems.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://rtems.rtems.org/mailman/listinfo/rtems-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Thanks & Best Regards!<br><br>Ray, Xu