RFC - Time & space partitioning with RTEMS
rayx.cn at gmail.com
Mon Apr 28 16:41:48 UTC 2008
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
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.
2008/4/28 Metge Jean-Jacques <jean-jacques.metge at cnes.fr>:
> Dear all,
> I would like to re-open a july 2007 discussion about time and space
> partitionnig with RTEMS (see below).
> Based on my past experience of ARINC653 development in aeronautics
> domain, I really think, as Joel wrote in july 2007, that space community
> (at least), which is an important user community of RTEMS products,
> could get a big added-value from splitting RTEMS in 2 separate layers :
> - 1 low level and very light layer (let's call it "RTEMS level 1"),
> usually called "hypervisor", running in supervisor mode, aiming at
> creating robust partitions in the sense of ARINC653 standard (ie
> dedicated memory zones, dedicated I/O zones and appropriate time slices,
> with appropriate protections and monitoring). This supervisor should
> rely on a hardware MMU, meaning that appropriate hardware function
> should be specifically developed for the LEON processor
> - 1 medium level layer (let's call it "RTEMS level 2"), sometimes called
> "partition OS", running in user mode, to be hosted, if requested by one
> or several users, in one or several of the created partitions.(*)
> (*) The upper layer being the software applications themselves.
> Note that a the decision to use or not RTEMS layer 2 as partition OS is
> totally let to any user, which may prefer to develop its own basic
> software or to adapt its own usual OS on top of RTEMS level 1.
> In order to concretly progress on this ambitious topic (I think), my
> current idea would be to :
> - first, develop a new "2-layers RTEMS" prototype (to be ran on ground,
> on an existing LEON board prototype), to be derived from an existing
> RTEMS version for LEON, in order to validate the concept
> - in a second step, develop, on the basis on this prototype, a new RTEMS
> open source version, compatible with LEON processor, and compatible with
> software development standards applicable to space on board software.
> Does anybody feels some interest with this exercise ?
> Does anybody already works on this idea and could be ready to provide
> some helps and/or to exchange some technical views ?
> Thank you by adavance for your attention.
> RFC - Memory Partitioning
> * Date: Tue, 24 Jul 2007 10:19:08 -0500
> * From: joel.sherrill at oarcorp.com (Joel Sherrill)
> * Subject: RFC - Memory Partitioning
> Robert S. Grimes wrote:
> > I've been thinking about this for a while too. I haven't anything too
> > concrete to suggest at this time, but I don't want to see your post
> > on the vine. I do have some observations about the nature of the
> > proposed beast...
> > One thought is that this move could result in the POSIX API becoming
> > more in line with other implementations, if each "partition" could act
> > as a "process" in the proposed RTEMS. This would allow developers the
> > usual choices of multi-process, multi-threaded (I like to think of
> > "tasks", in traditional API-speak, as "threads"), or combinations.
> I think you proposed using a hypervisor to put each
> RTEMS "process" inside its own container. Then you could
> get ARINC separation. Without reading the standard, could
> we implement an ARINC 653 manager that each RTEMS
> application runs inside of?
> > Another thought is that truly hard-real-time activities could run in a
> > suitably "high priority" partition, using such things as the rate
> > monotonic scheduler, and softer code then could run in other
> > I certainly would not want to eliminate the current model of RTEMS,
> > especially wrt low overhead, high performance on "smaller" systems,
> > especially those without MMU. A rather simple-minded idea could be to
> > think of such systems as "single partition" systems, which might lead
> > a useful guiding principle: In the proposed new RTEMS, a single
> > partition looks, acts, feels, sounds, smells, etc. like a traditional
> > RTEMS system.
> I think this is the way to go. Writing trap interfaces
> for god knows how many services, dealing with the
> known memory issues (e.g. copying buffers, mapping
> memory, etc.), and who knows what else will be a significant
> Approaching the problem by writing an ARINC 653 hypervisor
> will be more definable and give more value in the end to
> the RTEMS Experience. :)
> I think this approach would have extremely high value for
> the community and I would like to see it as a project.
> If there is interest, users from the space and aviation
> communities should be able to help sponsor this.
> > Just my $0.02, adjusted for inflation...
> My opinion's value is about the same. :)
> > -Bob
> > Charles Steaderman wrote:
> >> RFC
> >> Memory Partitioning Support in RTEMS
> >> Goals:
> >> Provide task level code and memory partitioning for RTEMS. The short
> >> term goal would be for a project that contains functionality to be
> >> certified at different certification levels (background data
> >> collection and storage certified to FAA Level C, and user interface
> >> non-certified).
> >> Proposed Strategy:
> >> Based upon some research into commercial partitioned embedded OSes
> >> (Integrity, Nucleus Secure, etc), I would like to suggest the
> >> following strategy for enhancing RTEMS. First, to provide separation
> >> from the kernel, I would propose that all RTEMS kernel calls be
> >> accessed via a TRAP or SWI. In this way, the kernel code can be
> >> into a non-accessable memory area in order to provide protection from
> >> userland tasks. Second, I would propose that task creation and
> >> switching become memory region aware. Task creation would need to be
> >> supplied memory regions and access permissions and those permissions
> >> would need to be updated on a context switch (MMU registers). In
> >> addition, each task could have its own private memory heap for
> >> memory allocation. This would mean that memory allocation would need
> >> to be told whether the allocation should come from the local or
> >> heap.
> >> I am sure that there is a large number of issues that I have
> >> overlooked, but I would like to get people thinking about
> >> in RTEMS. In much the same way that desktop operating systems have
> >> benefitted from process protectsion (Win9x vs. WinNT or OS 9 vs. OS
> >> X), I think that given the present and future state of embedded
> >> hardware, embedded systems could benefit from the same robustness.
> >> advantage that I believe the proposed solution has is that the code
> >> resides in a single address space, rather than virtual memory spaces.
> >> Perhaps this will cause problems with library calls and shared code,
> >> but perhaps there is a novel solution that we could employ.
> >> Thank you for your time and consideration.
> >> - Charlie
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.com
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> * References:
> * RFC - Memory Partitioning <msg00084.html>
> * From: charlies at poliac.com (Charles Steaderman)
> * RFC - Memory Partitioning <msg00086.html>
> * From: rsg at alum.mit.edu (Robert S. Grimes)
> * Prev by Date: RFC - Memory Partitioning <msg00086.html>
> * Next by Date: GameBoy Advance BSP <msg00088.html>
> * Previous by thread: RFC - Memory Partitioning <msg00086.html>
> * Next by thread: RTEMS and I2C APIs <msg00111.html>
> * Index(es):
> * Date <date1.html>
> rtems-users mailing list
> rtems-users at rtems.com
Thanks & Best Regards!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users