WL jolkaczad at
Mon Mar 12 10:27:02 UTC 2012

Thanks for the tip. At first glance, Pok looks like the appropriate
solution for the "Partition Management Kernel" which encompasses the
"Partition Scheduler & Dispatcher" and "Inter-Partition Communication"
layers (using AIR terminology). I also like the AADL modelling
language Pok uses to ease and validate system configuration. Getting
instances of RTEMS to run on top of that and implementing the
intra-partition ARINC 653 APEX API look like two distinct tasks, I'd
like to confirm whether one of them would be in the scope of a single
student summer project, maybe someone else has already looked into
that? In the meantime I'll check out the AIR SPARC BSP you mentioned.

Also, why was ITRON support dropped?

On Mon, Mar 12, 2012 at 6:48 AM, Joel Sherrill
<joel.sherrill at> wrote:
> While ARINC 653 support is desirable, it is an extremely large project that is beyond a single student. The (recently removed) ITRON support took a class of approximately 20 students to construct as a semester project. Even it was incomplete.
> ARINC 653 requires API support for inside a partition, between partitions, and a partition manager. Pok appears to be the best truly free alternative to build a solution with.  If you are interested in ARINC 653, I would recommend looking at Pok which is available today and getting RTEMS BSPs that are able to run as guests in the partitions.
> The AIR SPARC BSP developed last year would also be a starting point but we would lile x86 and PowerPC BSPs for Pok as well.
> I am cc'ing the author of Pok.
> --joel
> WL <jolkaczad at> wrote:
>>I'm looking into the task involving writing an API which will support
>>the partition-internal services of ARINC-653 as a GSoC project. I went
>>through some of the reading material linked on the wiki, but still
>>have a couple questions. First of all I'd like to take a look at the
>>specification to start reading and prepare a bit, especially since the
>>AIR report mentioned that some aspects of the API mapping were found
>>more complex than anticipated. Is there a copy available for RTEMS
>>developers (I know it costs over $200, but don't know what the license
>>on it is), or would I have to obtain it myself? Also, is the code
>>developed by the AIR taskforce as a proof of concept implementation or
>>at least its documentation publicly available, would be good as a
>>starting point.
>>rtems-users mailing list
>>rtems-users at

More information about the users mailing list