Recent changes to Home

Home modified by Pharos Team

Pharos Team — Fri, 13 Nov 2020 05:58:05 -0000

--- v41
+++ v42
@@ -15,7 +15,7 @@
 - ***channel*** - a zero-copy, extremely fast way for a partition to communicate with another, even on a different CPU core
 -***filters***" - custom made application functions that allow (or not) inter-partition communication

-See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310.
+See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310

 # Objectives

Home modified by Pharos Team

Pharos Team — Fri, 13 Nov 2020 05:56:56 -0000

--- v40
+++ v41
@@ -1,24 +1,21 @@
 # Welcome to Pharos!

 Pharos is a Real-Time Operating System. Is provides the mechanisms typical of RTOSes (multi-threading, fixed-priority preemptive scheduler, semaphores, message queues, etc) but also some functionalities that are rare:
-
- - **partitioning** (think processes in Linux) with memory protection and also time protection
+ 
+  - **partitioning** (think processes in Linux) with memory protection and also time protection
  - inter-partitioning communication/synchronization
  - prioritized nested interrupts
-- **CPU dependent configuration** (while Pharos provides a generic API that is common to all CPUs, we also allow you to configure your application according to the custom CPU capabilities, for example:
-    - some CPUs have an interrupt "wake-up" flag that, if not set, do not awake the CPU if it is in power down
-    - some CPUs have different memory areas (SRAM, SRAM backup, MRAM, FeRAM, SDRAM, etc). In Pharos you can set every variable to the memory area you want. For example, you can** speed-up a task by placing its stack on the SRAM** (instead of SDRAM)
-- multicore implementation under an **RMP** configuration (Real-time Multi-Processing). In short, this means that Pharos is not only lock-free but also **wait-free**, an essential property of real-time systems since it allows to determine worst-case execution time (WCET) independent of the number of cores and, in general, much better WCETs since the cores don't have to wait for each other. Please read more below.
-- **static configuration** - like OSEK operating systems, the configuration of the application (e.g. number of partitions, number of threads, etc) is done at compilation time. Note that not only is the application much quicker in the startup, you can check if you have space for your application right at compilation time (a linker error will occur if you request to much space) instead of having to download it to your system, run it, and then find the error. Although the configuration is static, Pharos **still allows you to dynamically allocate memory** (you have to configure each partition to have a pre-defined memory space from where the dynamic memory comes from)
-- "***lazy load***" - this means that you can setup a partition to be initialized (and started) only during the idle thread. This may reduce the critical startup time of your application since you can define that some partitions are only initialized after the critical ones have started and are running. For example, in aircrafts, the application must start within one second after boot.
-- native support for
-    - **periodic threads** - Pharos enforces the start of each job of a periodic thread after the configured period. A deadline (per thread) is also possible to define and a handler will be called if the deadline is missed. A maximum execution time per job can be set.
-    - **sporadic threads** - Pharos enforces the start of each job of a sporadic thread with a Minimum Inter-Arrival Time (MIT). A thread can be awaken via an event, message, bulk, mutex, etc. A deadline (per thread) is also possible to define and a handler will be called if the deadline is missed. A maximum execution time per job can be set.
-    - **aperiodic threads** - Pharos enforces the maximum execution time per replenishment period of aperiodic threads. That is, if the thread tries to execute for longer than its maximum execution time (during a replenishment period) Pharos will stop it and only make it ready when the next replenishment instant occurs
-- In terms of inter-partition communication, Pharos provides something unique and, we believe, makes the life so much easier for programmers: ***inter-partition calls***.   The original problem arises from the standard driver "read"/"write"/"open"/"close"/etc where casts to the correct arguments are always needed and the system easily becames a mess. With Pharos inter-partition calls, the prototype of the function is whatever you want it to be (an integer, a struct, etc) and the caller is completely aware of it so the code is much easier to read and make sure it is correct (the compiler verifies that the prototype is being complied with)
-- Finally, and most important, Pharos creates inter-partition "***filters***". A huge problem in complex applications with multiple partitions is to make sure a (non-critical) partition does not damage another (critical) partition. With this objective in mind, Pharos created the "filter" functions that can be placed on every inter-partition mechanism (e.g. channel bulks, hw queue, inter-partition calls, resource). These filter are user-defined functions that are executed in the memory context of the callee partition but in the time context (think thread maximum execution time) of the caller partition. Also, they have a special stack where they execute. The filter just returns a success/error for Pharos to determine if the call can continue (or not).
+- **CPU dependent configuration**, while Pharos provides a generic API that is common to all CPUs, we also allow you to configure your application according to the specific CPU capabilities (e.g. interrupt priority)
+- ***RMP*** (Real-time Multi-Processing) - a multicore implementation one step further than AMP, but one step back than SMP
+- **static configuration** - you can, at compile time, state the exact configuration of your app (e.g. which tasks, semaphores, etc)
+- **dynamically memory** - you can still allocate memory dynamically if you really need to
+- "***lazy load***" - this means that you can setup a partition to be initialized later on
+- native support for periodic, sporadic and aperiodic threads with deadline thread execution time monitoring and control
+- ***inter-partition calls*** - custom made functions where one partition may call functions of another partition
+- ***channel*** - a zero-copy, extremely fast way for a partition to communicate with another, even on a different CPU core
+-***filters***" - custom made application functions that allow (or not) inter-partition communication

-The above text was meant to be small and just give an overview of Pharos, but we just got very enthusiastic when thinking about the capabilities of Pharos, sorry for that. 
+See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310.

 # Objectives

@@ -28,19 +25,25 @@
  - safe systems
  - real-time systems

-For the experts that understand the concepts of monolithic and micro-kernel, Pharos is designed following a **micro-kernel** paradigm. This is because security and safety are the most important aspects of Pharos. This means that applications using Pharos should feel confident that security breaches are difficult to occur given the design of Pharos. Also, given the nature of micro-kernels, they are, by design, intrinsically small. This makes them much **easier to test** and give a good confidence that they don't have bugs or exploits. 
+That is, we place security and safety (e.g. memory must protected) as top objectives. Then we consider real-time implications (e.g. determinism). Other objectives like speed, memory occupation are also important, but they are secondary.
+
+# Design
+
+For the experts that understand the concepts of monolithic and micro-kernel, Pharos is designed following a **micro-kernel** paradigm. This is because security and safety are the most important aspects of Pharos. This means that applications using Pharos should feel confident that security breaches are difficult to occur given the design of Pharos. Also, given the nature of micro-kernels, they are, by design, intrinsically small. This makes them much **easier to test** and give a higher confidence that they don't have bugs or exploits. 

 No matter how perfect an OS is, a badly designed application can always produce errors. However, in Pharos a partition that has a inherent security issue will not be allowed to propagate that breach to other partitions (in terms of memory or time). Security is a major driver in placing Pharos as an open-source project: this allows it to be scrutinized by everyone. Security by obscurity is not the way to go (https://en.wikipedia.org/wiki/Security_through_obscurity).

-Qualifying/certifying a piece of software for safety critical systems is a somewhat overwhelming endeavour. A lot of tasks have to be performed, including tests, documentation, verifications, etc. Pharos is not qualified today to any standard. However it is our medium/long term goal to produce qualification artifacts that provide enough confidence that Pharos can be used in critical systems. Today, Pharos source code (you can check it yourself) was developed from the very beginning  according to **MISRA2004/2012**, has a good number of **comments**, the **cyclomatic number **and **nesting level **are not high. Additionally, we also produced a (non open-source) test suite composed by mostly validation tests (although a few unit tests as well). The **test suite** is roughly 3x the size (>**170 KLOCs**) of the source code (which has ~**59KLOCs**). In addition we also keep an up-to-date **user manual** (open-source and you can download it freely from "Files" - https://sourceforge.net/projects/rtospharos/files/). We created also a high-level and low-level requirements documents (non open-source), however these are now outdated and need a revision to be kept on track for the new releases of Pharos. According to the standard that we could certify Pharos to, additional documentation/tests are needed. We are developing Pharos in our free-time, so we currently just don't have the resources to this. If you require certification and are willing to provide us with some resources, we are able to this job ;).
-
 Another objective relates to real-time systems. That is, systems where you want to know that even in the worst overload scenarios your system will behave as expected. With this goal, Pharos provides a fixed-priority preemptive scheduler for single-core and multi-core systems. Real-Time Operating Systems for single-core systems are wide spread and although Pharos does bring some improvements (for example, a very fast clock tick processing routine that only awakes the highest priority thread, as opposed to awakening all the threads that are supposed to - note that Pharos still behaves as expected), Pharos major improvements come in multi-core systems were an "RMP" (Real-time MultiProcessing) design was introduced, as opposed to AMP or SMP. AMP (Assymetric MultiProcessing) is quite suitable for real-time systems since a core does not communicate with another. However, it can be improved by allowing some limited communication. SMP (Symmetric MultiProcessing) is used in systems like Linux/Windows. It is not suited for real-time systems given the overhead that it requires to manage threads from one core to another. For example, the scheduler requires a spin lock (bad idea in real-time systems) to determine which thread to execute on which core. Additionally, if a thread migrates from one core to another, its stack has to be dumped from one L1 cache to another. This overhead, in the worst case (required to calculate the WCET) is extremely bad. In some cases (for example, CPUs without cache snooping), the WCET is so bad that it is probably just better to use one core than multi-core with SMP. So basically Pharos uses RMP design as a midway solution between AMP and SMP. **RMP does not use spin locks nor is thread migration possible**. RMP uses only **wait-free algorithms** (note that it does not even use lock-free algorithms) for inter-core communication. A core can communicate with another via a "heavy weigh queue" (2-copy messages) or via a "channel" (0-copy messages). Note that with a channel, a partition can send a message of up to 1 GiB (depends on the CPU) almost instantly, even from one core to another. 

-In Pharos, applications run in **user mode** (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware **MMU/MPU** if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310
+In Pharos, applications run in **user mode** (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware **MMU/MPU** if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  
+
+# Qualification
+
+Qualifying/certifying a piece of software for safety critical systems is a somewhat overwhelming endeavor. A lot of tasks have to be performed, including tests, documentation, verifications, etc. Pharos is not qualified today to any standard. However it is our medium/long term goal to produce qualification artifacts that provide enough confidence that Pharos can be used in critical systems. Today, Pharos source code (you can check it yourself) was developed from the very beginning  according to **MISRA2004/2012**, has a good number of **comments**, the **cyclomatic number **and **nesting level **are not high. Additionally, we also produced a (non open-source) test suite composed by mostly validation tests (although a few unit tests as well). The **test suite** (> 400 tests) is roughly 3x the size (>**170 KLOCs**) of the source code (which has ~**59KLOCs**). In addition we also keep an up-to-date **user manual** (open-source and you can download it freely from "Files" - https://sourceforge.net/projects/rtospharos/files/). We created also a high-level and low-level requirements documents (non open-source), however these are now outdated and need a revision to be kept on track for the new releases of Pharos. According to the standard that we could certify Pharos to, additional documentation/tests are needed. We are developing Pharos in our free-time, so we currently just don't have the resources to this. If you require certification and are willing to provide us with some resources, we are able to this job ;).

 # License

-Pharos is available in open-source and under an **Apache 2.0 license**. This means that you can freely use on your public/private domain projects as you wish, free of cost. 
+Pharos is available in open-source and under an **Apache 2.0 license**. Among other things, this means that you can freely use on your public/private domain projects as you wish, free of cost. 

 # An overview

@@ -52,7 +55,7 @@
  - partitions cannot access the memory area of each other (unless configured to be able to do so)
  - each thread can be configured to have a maximum execution time 

-In other words, you could have an airbag and infotainement systems running under the same CPU and Pharos will guarantee that the low critical systems interference with the highly critical is under your applications defined limits. For example, the infotainment code will not be able to corrupt the memory area of the airbag. Furthermore, the infotainment could have high priority threads (to provide quick user response) and still Pharos can ensure that the lower priority but highly critical airbag threads will run, no matter what the high priority threads do. We refer this feature as *"thread maximum execution temporal monitoring"*.
+In other words, you could have an airbag and infotainment systems running under the same CPU and Pharos will guarantee that the low critical systems interference with the highly critical is under your applications defined limits. For example, the infotainment code will not be able to corrupt the memory area of the airbag. Furthermore, the infotainment could have high priority threads (to provide quick user response) and still Pharos can ensure that the lower priority but highly critical airbag threads will run, no matter what the high priority threads do. We refer this feature as *"thread temporal execution monitoring"*.

 ## Threads

@@ -64,31 +67,31 @@

 The periodic and sporadic threads have included a maximum time for each job to execute (should correspond to their WCET) and a deadline. If the thread attempts to take more time to execute, Pharos will notify the partition and stop the thread (and resume it when the period or the MIT as elapsed). If the thread deadline is reached, Pharos will call an error handler so that the application detects the fault.

-While a periodic thread is easy to understand, a native support for a sporadic thread might be unknow to most users. Basically, a sporadic thread has the same propreties as a periodic thread except instead of a period it has a MIT (minimum inter-arrival time). A sporadic thread can be activated at any time by a Pharos event, semaphore, message queue, etc. But the thread will be executed respecting its MIT: there must be a minimum time interval between two consecutive activations of the thread. This is similar to a periodic thread instead of a fixed period, there is a minimum "period".
+While a periodic thread is easy to understand, a native support for a sporadic thread might be unknown to most users. Basically, a sporadic thread has the same properties as a periodic thread except instead of a period it has a MIT (minimum inter-arrival time). A sporadic thread can be activated at any time by a Pharos event, semaphore, message queue, etc. But the thread will be executed respecting its MIT: there must be a minimum time interval between two consecutive activations of the thread. This is similar to a periodic thread instead of a fixed period, there is a minimum "period".
 The application defines which type of sporadic thread it wants, based on events, message queues, semaphores, etc. The entry point of the thread corresponds to a function that executes a job (hence there is no need for an infinite loop inside periodic or sporadic threads). The sporadic thread function will receive an argument  corresponding to its type. For example, if it is activated by a message queue, it will get a message sent; if it is activated by an event, it will get the event sent and so on.

 Aperiodic threads, by definition, do not have a maximum time (WCET) nor a deadline. However, since Pharos 2.0.0, aperiodic threads can also have a WCET and an associated "period" (AKA replenishment period) by which the application can limit its execution time. That is, each aperiodic thread has a budget that is replenished at each period. If the thread tries to execute more budget than configured (more time than it is supposed to), Pharos will stop the thread until the next period starts. 

-Using this method the lower priority threads can have a garantee that the higher priority threads will relinquish the CPU and so they will have time to execute (as long as the application configured the maximum execution times of the higher priority threads appropriately).
+Using this method the lower priority threads can have a guarantee that the higher priority threads will relinquish the CPU and so they will have time to execute (as long as the application configured the maximum execution times of the higher priority threads appropriately).

 ## Inter-partition communication/synchronization

 A partition can also communicate and synchronize with other partitions through:

- - message queue - data is copied from one partition to another (slow for big messages)
- - channel - data is sent from one partition to another simply by managing the MMU/MPU (very fast for big messages)
+ - heavy weight message queue - data is copied from one partition to another (slow for big messages)
+ - **channel** - data is sent from one partition to another simply by managing the MMU/MPU (very fast for big messages)
  - resource - used to ensure mutual exclusion. Uses internally a semaphore with priority ceiling algorithm and the calling thread can only execute the mutual exclusion code if it has enough time to fully complete it. 
  - inter-partition calls - a partition can call directly (and safely) a specific function of another partition (with the exact prototype of the function). For example, "configure a UART to 155200 baud rate". 
  - shared section - memory area that is accessible to all partitions
- - io memory - you can define specific memory areas where each partition has access to. For example, you can configure the same area to be accessed in read/write/whatever permissions for two partitions so they can share the region
+ - **io memory** - you can define specific memory areas where each partition has access to. For example, you can configure the same area to be accessed in read/write/whatever permissions for two partitions so they can share the region

-One inovation that Pharos brings (to the best of our knowledge) is the introduction of filters for inter-partition objects. Inter-partition objects are not new themselves, but the way Pharos implements them and the way the application can use them is new (to the best of our knowledge). This mechanism is needed in multiple applications that have a resource (in the abstract sense of the word) that is used by multiple partitions but must be controlled. For example, a CAN driver can be used to transmit/receive messages from any partition. However, it should not be overloaded with messages from a faulty partition. Pharos introduces a  filter function that is invoked before the message is transmitted (to the message queue or channel) or the resource accessed. It is run in the context of the calling thread but with memory permissions and stack of the partition being invoked. For example, suppose partitions A, B and C can send messages to a message queue of partition Z, but partition D cannot send messages to this queue. The code executed in filter for the message queue will have the same memory permissions as partition Z and will run with a stack in partition Z. However Pharos will still account for the time taken in executing the filter to the calling thread. This means that a faulty thread can only damage its own execution time and this will have no impact on partition Z (or any other partition). In this case, the filter code that will check if the message being sent is from partition D and if so, rejects it. The application is free to create more complex filters, such as limit the number of messages per second being sent, reject messages if the CAN queue is approaching its limits, etc.
+One innovation that Pharos brings (to the best of our knowledge) is the introduction of **filters** for inter-partition objects. Inter-partition objects are not new themselves, but the way Pharos implements them and the way the application can use them is new (to the best of our knowledge). This mechanism is needed in multiple applications that have a resource (in the abstract sense of the word) that is used by multiple partitions but must be controlled. For example, a CAN driver can be used to transmit/receive messages from any partition. However, it should not be overloaded with messages from a faulty partition. Pharos introduces a  filter function that is invoked before the message is transmitted (to the message queue or channel) or the resource accessed. It is run in the context of the calling thread but with memory permissions and stack of the partition being invoked. For example, suppose partitions A, B and C can send messages to a message queue of partition Z, but partition D cannot send messages to this queue. The code executed in filter for the message queue will have the same memory permissions as partition Z and will run with a stack in partition Z. However Pharos will still account for the time taken in executing the filter to the calling thread. This means that a faulty thread can only damage its own execution time and this will have no impact on partition Z (or any other partition). In this case, the filter code that will check if the message being sent is from partition D and if so, rejects it. The application is free to create more complex filters, such as limit the number of messages per second being sent, reject messages if the CAN queue is approaching its limits, etc.

 ## Multicore - RMP

 Multicore is supported in RMP (Real-time MultiProcessing) fashion on all the supported multicore CPUs (currently ARM Cortex-A53 and RISC-V). RMP fashion  means that each core can be viewed as running its own separate Pharos but they can communicate between each other via channels or heavy weight queues. Partitions are allocated to one core, including its threads, semaphores, queues, etc. 

-The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms envolved are not only lock-free, they are also wait-free! This makes Pharos scalable across the number of cores. In theory (we did not test since we don't have the hardware), you could have a 1000 core system and the cores will only "talk" to each other as required by your application. No more, no less.
+The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms involved are not only lock-free, they are also **wait-free**! This makes Pharos scalable across the number of cores. In theory (we did not test since we don't have the hardware), you could have a 1000 core system and the cores will only "talk" to each other as required by your application. No more, no less.
 Thus the system is as scalable as your application allows it to be (i.e. if your application has each of the cores talking to the 999 other cores, then it might not be very efficient).

 ## Supported hardware
@@ -112,12 +115,17 @@
 - RISC-V
     - Quad-core RISC-V 64 bit Virt board in qemu (Sv39 MMU)

-Pharos is throughly tested (> 400 tests) and follows a strict quality procedure.
- 
-The next release (3.4.0) is focusing on adding some more features and correcting several bugs. See the ticket system for more information (select the tickets that have a milestone "3.4.0"). We hope to release "3.4.0" soon (< 1 month).
+# Hardware requirements
+Pharos is designed to not take "too much" memory. We run it (with several threads/partitions/etc) on a 256 KiB SRAM board. Pharos itself needs about 20 KiB SRAM (depends on the CPU family). Although it requires some memory (more than other smaller RTOS), we believe it does required much. In compensation for the larger amount of memory, Pharos provides more functionalities, as stated earlier.

-# Hardware requirements
-Pharos is designed to not take "too much" memory. We run it (with several threads/partitions/etc) on a 256 KiB SRAM board. Pharos itself needs about 20 KiB SRAM (depends on the CPU family). Although it requires some memory (more than other smaller RTOS), we believe it does required much and many applications can use Pharos. In compensation for the larger amount of memory, Pharos provides more functionalities, such as memory and time protection, zero-copy memory transfer between partitions (using channels), scalable multi-core applications.
+# Where to start
+
+Although you can navigate in the wiki pages, we suggest that we start with the User Manual. Follow the link https://sourceforge.net/projects/rtospharos/files/, select the folder with the latest version, and download the User Manual. There you have the latest information specific to the corresponding Pharos version. Have fun :)
+
+# Future work
+
+The next release (3.5.0), apart from bug corrections, is focusing on adding  a TCP/IP stack library, which is named RTN (Real-Time Networking). 
+We hope to release it soon (< 3 months).

 # Feedback

Home modified by Pharos Team

Pharos Team — Sun, 29 Mar 2020 11:27:42 -0000

--- v39
+++ v40
@@ -9,7 +9,7 @@
     - some CPUs have an interrupt "wake-up" flag that, if not set, do not awake the CPU if it is in power down
     - some CPUs have different memory areas (SRAM, SRAM backup, MRAM, FeRAM, SDRAM, etc). In Pharos you can set every variable to the memory area you want. For example, you can** speed-up a task by placing its stack on the SRAM** (instead of SDRAM)
 - multicore implementation under an **RMP** configuration (Real-time Multi-Processing). In short, this means that Pharos is not only lock-free but also **wait-free**, an essential property of real-time systems since it allows to determine worst-case execution time (WCET) independent of the number of cores and, in general, much better WCETs since the cores don't have to wait for each other. Please read more below.
-- **static configuration** - like OSEK operating systems, the configuration of the application (e.g. number of partitions, number of threads, etc) is done at compilation time. Note that not only is the application is much quicker in the startup, you can check if you have space for your application right at compilation time (a linker error will occur if you request to much space). Although the configuration is static, Pharos **still allows you to dynamically allocate memory** (you have to configure each partition to have a pre-defined memory space from where the dynamic memory comes from)
+- **static configuration** - like OSEK operating systems, the configuration of the application (e.g. number of partitions, number of threads, etc) is done at compilation time. Note that not only is the application much quicker in the startup, you can check if you have space for your application right at compilation time (a linker error will occur if you request to much space) instead of having to download it to your system, run it, and then find the error. Although the configuration is static, Pharos **still allows you to dynamically allocate memory** (you have to configure each partition to have a pre-defined memory space from where the dynamic memory comes from)
 - "***lazy load***" - this means that you can setup a partition to be initialized (and started) only during the idle thread. This may reduce the critical startup time of your application since you can define that some partitions are only initialized after the critical ones have started and are running. For example, in aircrafts, the application must start within one second after boot.
 - native support for
     - **periodic threads** - Pharos enforces the start of each job of a periodic thread after the configured period. A deadline (per thread) is also possible to define and a handler will be called if the deadline is missed. A maximum execution time per job can be set.
@@ -88,8 +88,9 @@

 Multicore is supported in RMP (Real-time MultiProcessing) fashion on all the supported multicore CPUs (currently ARM Cortex-A53 and RISC-V). RMP fashion  means that each core can be viewed as running its own separate Pharos but they can communicate between each other via channels or heavy weight queues. Partitions are allocated to one core, including its threads, semaphores, queues, etc. 

-The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms envolved are not only lock-free, they are also wait-free! This makes Pharos scalable across the number of cores. In theory (we did not test), you could have a 1000 core system and the cores will only "talk" to each other as required by the application. No more, no less.
- 
+The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms envolved are not only lock-free, they are also wait-free! This makes Pharos scalable across the number of cores. In theory (we did not test since we don't have the hardware), you could have a 1000 core system and the cores will only "talk" to each other as required by your application. No more, no less.
+Thus the system is as scalable as your application allows it to be (i.e. if your application has each of the cores talking to the 999 other cores, then it might not be very efficient).
+
 ## Supported hardware

 The full list of currently supported CPUs is:
@@ -115,6 +116,8 @@

 The next release (3.4.0) is focusing on adding some more features and correcting several bugs. See the ticket system for more information (select the tickets that have a milestone "3.4.0"). We hope to release "3.4.0" soon (< 1 month).

+# Hardware requirements
+Pharos is designed to not take "too much" memory. We run it (with several threads/partitions/etc) on a 256 KiB SRAM board. Pharos itself needs about 20 KiB SRAM (depends on the CPU family). Although it requires some memory (more than other smaller RTOS), we believe it does required much and many applications can use Pharos. In compensation for the larger amount of memory, Pharos provides more functionalities, such as memory and time protection, zero-copy memory transfer between partitions (using channels), scalable multi-core applications.

 # Feedback

Home modified by Pharos Team

Pharos Team — Sun, 29 Mar 2020 11:16:45 -0000

--- v38
+++ v39
@@ -90,7 +90,7 @@

 The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms envolved are not only lock-free, they are also wait-free! This makes Pharos scalable across the number of cores. In theory (we did not test), you could have a 1000 core system and the cores will only "talk" to each other as required by the application. No more, no less.

- ## Supported hardware
+## Supported hardware

 The full list of currently supported CPUs is:

Home modified by Pharos Team

Pharos Team — Sun, 29 Mar 2020 11:04:35 -0000

--- v37
+++ v38
@@ -1,4 +1,4 @@
-Welcome to Pharos!
+# Welcome to Pharos!

 Pharos is a Real-Time Operating System. Is provides the mechanisms typical of RTOSes (multi-threading, fixed-priority preemptive scheduler, semaphores, message queues, etc) but also some functionalities that are rare:

@@ -20,6 +20,8 @@

 The above text was meant to be small and just give an overview of Pharos, but we just got very enthusiastic when thinking about the capabilities of Pharos, sorry for that. 

+# Objectives
+
 Pharos was designed with the following systems in mind:

  - secure systems
@@ -36,7 +38,11 @@

 In Pharos, applications run in **user mode** (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware **MMU/MPU** if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310

-Pharos is available in open-source and under an **Apache 2.0 license**. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.
+# License
+
+Pharos is available in open-source and under an **Apache 2.0 license**. This means that you can freely use on your public/private domain projects as you wish, free of cost. 
+
+# An overview

 We designed Pharos to provide to support mixed-criticality applications. In essence:

@@ -47,6 +53,8 @@
  - each thread can be configured to have a maximum execution time 

 In other words, you could have an airbag and infotainement systems running under the same CPU and Pharos will guarantee that the low critical systems interference with the highly critical is under your applications defined limits. For example, the infotainment code will not be able to corrupt the memory area of the airbag. Furthermore, the infotainment could have high priority threads (to provide quick user response) and still Pharos can ensure that the lower priority but highly critical airbag threads will run, no matter what the high priority threads do. We refer this feature as *"thread maximum execution temporal monitoring"*.
+
+## Threads

 Pharos divides the application into partitions, where each partition is composed by threads, semaphores, message queues, etc. Each partition threads can synchronize/communicate with each other using the standard OS features. Each thread can be:

@@ -63,15 +71,26 @@

 Using this method the lower priority threads can have a garantee that the higher priority threads will relinquish the CPU and so they will have time to execute (as long as the application configured the maximum execution times of the higher priority threads appropriately).

+## Inter-partition communication/synchronization
+
 A partition can also communicate and synchronize with other partitions through:

  - message queue - data is copied from one partition to another (slow for big messages)
  - channel - data is sent from one partition to another simply by managing the MMU/MPU (very fast for big messages)
  - resource - used to ensure mutual exclusion. Uses internally a semaphore with priority ceiling algorithm and the calling thread can only execute the mutual exclusion code if it has enough time to fully complete it. 
+ - inter-partition calls - a partition can call directly (and safely) a specific function of another partition (with the exact prototype of the function). For example, "configure a UART to 155200 baud rate". 
+ - shared section - memory area that is accessible to all partitions
+ - io memory - you can define specific memory areas where each partition has access to. For example, you can configure the same area to be accessed in read/write/whatever permissions for two partitions so they can share the region

 One inovation that Pharos brings (to the best of our knowledge) is the introduction of filters for inter-partition objects. Inter-partition objects are not new themselves, but the way Pharos implements them and the way the application can use them is new (to the best of our knowledge). This mechanism is needed in multiple applications that have a resource (in the abstract sense of the word) that is used by multiple partitions but must be controlled. For example, a CAN driver can be used to transmit/receive messages from any partition. However, it should not be overloaded with messages from a faulty partition. Pharos introduces a  filter function that is invoked before the message is transmitted (to the message queue or channel) or the resource accessed. It is run in the context of the calling thread but with memory permissions and stack of the partition being invoked. For example, suppose partitions A, B and C can send messages to a message queue of partition Z, but partition D cannot send messages to this queue. The code executed in filter for the message queue will have the same memory permissions as partition Z and will run with a stack in partition Z. However Pharos will still account for the time taken in executing the filter to the calling thread. This means that a faulty thread can only damage its own execution time and this will have no impact on partition Z (or any other partition). In this case, the filter code that will check if the message being sent is from partition D and if so, rejects it. The application is free to create more complex filters, such as limit the number of messages per second being sent, reject messages if the CAN queue is approaching its limits, etc.

+## Multicore - RMP
+
 Multicore is supported in RMP (Real-time MultiProcessing) fashion on all the supported multicore CPUs (currently ARM Cortex-A53 and RISC-V). RMP fashion  means that each core can be viewed as running its own separate Pharos but they can communicate between each other via channels or heavy weight queues. Partitions are allocated to one core, including its threads, semaphores, queues, etc. 
+
+The communication between cores is done via interrupts. That is, suppose core 0 wants to send an channel bulk to core 1. To do this, core 0 will trigger an interrupt on core 1. The algorithms envolved are not only lock-free, they are also wait-free! This makes Pharos scalable across the number of cores. In theory (we did not test), you could have a 1000 core system and the cores will only "talk" to each other as required by the application. No more, no less.
+ 
+ ## Supported hardware

 The full list of currently supported CPUs is:

@@ -96,6 +115,11 @@

 The next release (3.4.0) is focusing on adding some more features and correcting several bugs. See the ticket system for more information (select the tickets that have a milestone "3.4.0"). We hope to release "3.4.0" soon (< 1 month).

+
+# Feedback
+
+A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.
+
 Support is available. Please make use of the Ticket system if you found a bug, use the Discussions to place questions or contact us at **rtos.pharos@outlook.com**.

 [[members limit=20]]

Home modified by Pharos Team

Pharos Team — Sat, 21 Mar 2020 17:27:50 -0000

--- v36
+++ v37
@@ -1,20 +1,42 @@
 Welcome to Pharos!

-Pharos is a Real-Time Operating System designed for secure systems. It is intended to by used by (in order of importance):
+Pharos is a Real-Time Operating System. Is provides the mechanisms typical of RTOSes (multi-threading, fixed-priority preemptive scheduler, semaphores, message queues, etc) but also some functionalities that are rare:
+
+ - **partitioning** (think processes in Linux) with memory protection and also time protection
+ - inter-partitioning communication/synchronization
+ - prioritized nested interrupts
+- **CPU dependent configuration** (while Pharos provides a generic API that is common to all CPUs, we also allow you to configure your application according to the custom CPU capabilities, for example:
+    - some CPUs have an interrupt "wake-up" flag that, if not set, do not awake the CPU if it is in power down
+    - some CPUs have different memory areas (SRAM, SRAM backup, MRAM, FeRAM, SDRAM, etc). In Pharos you can set every variable to the memory area you want. For example, you can** speed-up a task by placing its stack on the SRAM** (instead of SDRAM)
+- multicore implementation under an **RMP** configuration (Real-time Multi-Processing). In short, this means that Pharos is not only lock-free but also **wait-free**, an essential property of real-time systems since it allows to determine worst-case execution time (WCET) independent of the number of cores and, in general, much better WCETs since the cores don't have to wait for each other. Please read more below.
+- **static configuration** - like OSEK operating systems, the configuration of the application (e.g. number of partitions, number of threads, etc) is done at compilation time. Note that not only is the application is much quicker in the startup, you can check if you have space for your application right at compilation time (a linker error will occur if you request to much space). Although the configuration is static, Pharos **still allows you to dynamically allocate memory** (you have to configure each partition to have a pre-defined memory space from where the dynamic memory comes from)
+- "***lazy load***" - this means that you can setup a partition to be initialized (and started) only during the idle thread. This may reduce the critical startup time of your application since you can define that some partitions are only initialized after the critical ones have started and are running. For example, in aircrafts, the application must start within one second after boot.
+- native support for
+    - **periodic threads** - Pharos enforces the start of each job of a periodic thread after the configured period. A deadline (per thread) is also possible to define and a handler will be called if the deadline is missed. A maximum execution time per job can be set.
+    - **sporadic threads** - Pharos enforces the start of each job of a sporadic thread with a Minimum Inter-Arrival Time (MIT). A thread can be awaken via an event, message, bulk, mutex, etc. A deadline (per thread) is also possible to define and a handler will be called if the deadline is missed. A maximum execution time per job can be set.
+    - **aperiodic threads** - Pharos enforces the maximum execution time per replenishment period of aperiodic threads. That is, if the thread tries to execute for longer than its maximum execution time (during a replenishment period) Pharos will stop it and only make it ready when the next replenishment instant occurs
+- In terms of inter-partition communication, Pharos provides something unique and, we believe, makes the life so much easier for programmers: ***inter-partition calls***.   The original problem arises from the standard driver "read"/"write"/"open"/"close"/etc where casts to the correct arguments are always needed and the system easily becames a mess. With Pharos inter-partition calls, the prototype of the function is whatever you want it to be (an integer, a struct, etc) and the caller is completely aware of it so the code is much easier to read and make sure it is correct (the compiler verifies that the prototype is being complied with)
+- Finally, and most important, Pharos creates inter-partition "***filters***". A huge problem in complex applications with multiple partitions is to make sure a (non-critical) partition does not damage another (critical) partition. With this objective in mind, Pharos created the "filter" functions that can be placed on every inter-partition mechanism (e.g. channel bulks, hw queue, inter-partition calls, resource). These filter are user-defined functions that are executed in the memory context of the callee partition but in the time context (think thread maximum execution time) of the caller partition. Also, they have a special stack where they execute. The filter just returns a success/error for Pharos to determine if the call can continue (or not).
+
+The above text was meant to be small and just give an overview of Pharos, but we just got very enthusiastic when thinking about the capabilities of Pharos, sorry for that. 
+
+Pharos was designed with the following systems in mind:

  - secure systems
  - safe systems
  - real-time systems

-Secure systems are first and foremost the most important aspect of Pharos. This means that applications using Pharos should feel confident that security breaches are difficult to occur given the design of Pharos. Note that a badly designed application can always overcome the most perfect operating system but in Pharos a partition that has a inherent security issue will not be allowed to propagate that breach to other partitions (in terms of memory or time). The security driver was a major driver in placing Pharos as an open-source project (so that it could be scrutinized by everyone). 
+For the experts that understand the concepts of monolithic and micro-kernel, Pharos is designed following a **micro-kernel** paradigm. This is because security and safety are the most important aspects of Pharos. This means that applications using Pharos should feel confident that security breaches are difficult to occur given the design of Pharos. Also, given the nature of micro-kernels, they are, by design, intrinsically small. This makes them much **easier to test** and give a good confidence that they don't have bugs or exploits. 

-The second most important driver for Pharos regards its intent to be used in safety critical systems. Qualifying/certifying a piece of software for safety critical systems is a somewhat overwhelming endeavour. A lot of tasks have to be performed, including tests, documentation, verifications, etc. Pharos is not qualified today to any standard. However it is our medium/long term goal to produce qualification artifacts that provide enough confidence that Pharos can be used in critical systems. Today, Pharos source code (you can check it yourself) is designed according to MISRA2004/2012, has a good number of comments, the cyclomatic number and nesting level are not high. Additionally, we also produced a (non open-source) test suite composed by mostly validation tests (although a few unit tests as well). The test suite is roughly 3x the size of the source code. In addition we also keep an up-to-date user manual (open-source and you can download it freely from "Files" - https://sourceforge.net/projects/rtospharos/files/). We created also a high-level and low-level requirements documents (non open-source), however these are now outdated and need a revision to be kept on track for the new releases of Pharos. According to the standard that we could certify Pharos to, additional documentation/tests are needed. We are developing Pharos in our free-time, so we currently just don't have the resources to this. If you require certification and are willing to provide us with some resources, we are able to this job ;).
+No matter how perfect an OS is, a badly designed application can always produce errors. However, in Pharos a partition that has a inherent security issue will not be allowed to propagate that breach to other partitions (in terms of memory or time). Security is a major driver in placing Pharos as an open-source project: this allows it to be scrutinized by everyone. Security by obscurity is not the way to go (https://en.wikipedia.org/wiki/Security_through_obscurity).

-Pharos third objective relates to real-time systems. That is, systems where you want to know that even in the worst overload scenarios your system will behave as expected. With this goal, Pharos provides a fixed-priority preemptive scheduler for uni-core and multi-core systems. Real-Time Operating Systems for uni-core systems are wide spread and although Pharos does bring some improvements (for example, a very fast clock tick processing routine that only awakes the highest priority thread, as opposed to awakening all the threads that are supposed to - note that Pharos still behaves as expected), Pharos major improvements come in multi-core systems were an "RMP" (Real-time MultiProcessing) design was introduced, as opposed to AMP or SMP. AMP (Assymetric MultiProcessing) is quite suitable for real-time systems since a core does not communicate with another. However, it can be improved by allowing some limited communication. SMP (Symmetric MultiProcessing) is used in systems like Linux/Windows. It is not suited for real-time systems given the overhead that it requires to manage threads from one core to another. For example, the scheduler requires a spin lock (bad idea in real-time systems) to determine which thread to execute on which core. Additionally, if a thread migrates from one core to another, its stack has to be dumped from one L1 cache to another. This overhead, in the worst case (required to calculate the WCET) is extremely bad. In some cases (for example, CPUs without cache snooping), the WCET is so bad that it is probably just better to use one core than multi-core with SMP. So basically Pharos uses RMP design as a midway solution between AMP and SMP. RMP does not use spin locks nor is thread migration possible. RMP uses only wait-free algorithms (note that it does not even use lock-free algorithms) for inter-core communication. A core can communicate with another via a "heavy weigh queue" (2-copy messages) or via a "channel" (0-copy messages). Note that with a channel, a partition can send a message of up to 1 GiB almost instantly, even from one core to another. 
+Qualifying/certifying a piece of software for safety critical systems is a somewhat overwhelming endeavour. A lot of tasks have to be performed, including tests, documentation, verifications, etc. Pharos is not qualified today to any standard. However it is our medium/long term goal to produce qualification artifacts that provide enough confidence that Pharos can be used in critical systems. Today, Pharos source code (you can check it yourself) was developed from the very beginning  according to **MISRA2004/2012**, has a good number of **comments**, the **cyclomatic number **and **nesting level **are not high. Additionally, we also produced a (non open-source) test suite composed by mostly validation tests (although a few unit tests as well). The **test suite** is roughly 3x the size (>**170 KLOCs**) of the source code (which has ~**59KLOCs**). In addition we also keep an up-to-date **user manual** (open-source and you can download it freely from "Files" - https://sourceforge.net/projects/rtospharos/files/). We created also a high-level and low-level requirements documents (non open-source), however these are now outdated and need a revision to be kept on track for the new releases of Pharos. According to the standard that we could certify Pharos to, additional documentation/tests are needed. We are developing Pharos in our free-time, so we currently just don't have the resources to this. If you require certification and are willing to provide us with some resources, we are able to this job ;).

-In Pharos, applications run in user mode (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware MMU/MPU if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310
+Another objective relates to real-time systems. That is, systems where you want to know that even in the worst overload scenarios your system will behave as expected. With this goal, Pharos provides a fixed-priority preemptive scheduler for single-core and multi-core systems. Real-Time Operating Systems for single-core systems are wide spread and although Pharos does bring some improvements (for example, a very fast clock tick processing routine that only awakes the highest priority thread, as opposed to awakening all the threads that are supposed to - note that Pharos still behaves as expected), Pharos major improvements come in multi-core systems were an "RMP" (Real-time MultiProcessing) design was introduced, as opposed to AMP or SMP. AMP (Assymetric MultiProcessing) is quite suitable for real-time systems since a core does not communicate with another. However, it can be improved by allowing some limited communication. SMP (Symmetric MultiProcessing) is used in systems like Linux/Windows. It is not suited for real-time systems given the overhead that it requires to manage threads from one core to another. For example, the scheduler requires a spin lock (bad idea in real-time systems) to determine which thread to execute on which core. Additionally, if a thread migrates from one core to another, its stack has to be dumped from one L1 cache to another. This overhead, in the worst case (required to calculate the WCET) is extremely bad. In some cases (for example, CPUs without cache snooping), the WCET is so bad that it is probably just better to use one core than multi-core with SMP. So basically Pharos uses RMP design as a midway solution between AMP and SMP. **RMP does not use spin locks nor is thread migration possible**. RMP uses only **wait-free algorithms** (note that it does not even use lock-free algorithms) for inter-core communication. A core can communicate with another via a "heavy weigh queue" (2-copy messages) or via a "channel" (0-copy messages). Note that with a channel, a partition can send a message of up to 1 GiB (depends on the CPU) almost instantly, even from one core to another. 

-Pharos is available in open-source and under an Apache 2.0 license. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.
+In Pharos, applications run in **user mode** (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware **MMU/MPU** if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310
+
+Pharos is available in open-source and under an **Apache 2.0 license**. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.

 We designed Pharos to provide to support mixed-criticality applications. In essence:

@@ -24,7 +46,7 @@
  - partitions cannot access the memory area of each other (unless configured to be able to do so)
  - each thread can be configured to have a maximum execution time 

-In other words, you could have an airbag and infotainement systems running under the same CPU and Pharos will guarantee that the low critical systems interference with the highly critical is under your applications defined limits. For example, the infotainment code will not be able to corrupt the memory area of the airbag. Furthermore, the infotainment could have high priority threads (to provide quick user response) and still Pharos can ensure that the lower priority but highly critical airbag threads will run, no matter what the high priority threads code. We refer this feature as thread execution temporal monitoring.
+In other words, you could have an airbag and infotainement systems running under the same CPU and Pharos will guarantee that the low critical systems interference with the highly critical is under your applications defined limits. For example, the infotainment code will not be able to corrupt the memory area of the airbag. Furthermore, the infotainment could have high priority threads (to provide quick user response) and still Pharos can ensure that the lower priority but highly critical airbag threads will run, no matter what the high priority threads do. We refer this feature as *"thread maximum execution temporal monitoring"*.

 Pharos divides the application into partitions, where each partition is composed by threads, semaphores, message queues, etc. Each partition threads can synchronize/communicate with each other using the standard OS features. Each thread can be:

@@ -37,7 +59,7 @@
 While a periodic thread is easy to understand, a native support for a sporadic thread might be unknow to most users. Basically, a sporadic thread has the same propreties as a periodic thread except instead of a period it has a MIT (minimum inter-arrival time). A sporadic thread can be activated at any time by a Pharos event, semaphore, message queue, etc. But the thread will be executed respecting its MIT: there must be a minimum time interval between two consecutive activations of the thread. This is similar to a periodic thread instead of a fixed period, there is a minimum "period".
 The application defines which type of sporadic thread it wants, based on events, message queues, semaphores, etc. The entry point of the thread corresponds to a function that executes a job (hence there is no need for an infinite loop inside periodic or sporadic threads). The sporadic thread function will receive an argument  corresponding to its type. For example, if it is activated by a message queue, it will get a message sent; if it is activated by an event, it will get the event sent and so on.

-Aperiodic threads, by definition, do not have a maximum time (WCET) nor a deadline. However, since Pharos 2.0.0, aperiodic threads can also have a WCET and an associated "period" by which the application can limit its execution time. That is, each aperiodic thread has a budget that is replenished at each period. If the thread tries to execute more budget than configured (more time than it is supposed to), Pharos will stop the thread until the next period. 
+Aperiodic threads, by definition, do not have a maximum time (WCET) nor a deadline. However, since Pharos 2.0.0, aperiodic threads can also have a WCET and an associated "period" (AKA replenishment period) by which the application can limit its execution time. That is, each aperiodic thread has a budget that is replenished at each period. If the thread tries to execute more budget than configured (more time than it is supposed to), Pharos will stop the thread until the next period starts. 

 Using this method the lower priority threads can have a garantee that the higher priority threads will relinquish the CPU and so they will have time to execute (as long as the application configured the maximum execution times of the higher priority threads appropriately).

@@ -58,7 +80,7 @@
     - VersatilePb board in qemu

  - Cortex-R5 (armv7-R)
-    - Hercules TMS570LC43x LaunchPad Development Kit (http://www.ti.com/tool/LAUNCHXL2-570LC43) in lock-step (one core in redundancy).
+    - Hercules TMS570LC43x LaunchPad Development Kit (http://www.ti.com/tool/LAUNCHXL2-570LC43) in lock-step (one core in redundancy). Sadly, our board has wear-down its flash (we believe) so we can no longer test in it. Currently we can only make sure that Pharos is compiled against it. If you desire support for this board let us know.

  - Cortex-M4 (armv7-M)
     - STM32F469I-DISCO (https://www.st.com/en/evaluation-tools/32f469idiscovery.html). This board from ST has a STM32F469NIH6 CPU, running at 180 MHz, 64 KiB CCM SRAM (extremely fast SRAM), 320 KiB SRAM, 4 KiB Backup SRAM, 128 Mbit SDRAM, 2 MiB Flash and more. This is the first port that Pharos is ported to that has more than one type of memory. Pharos has been extended in such a way that an application can easily select the memory type where it wants part (or all) of its memory. For example, you can place the stack of a thread on the fast CCM memory and a "large" global variable on the SDRAM, its up to you.
@@ -70,9 +92,9 @@
 - RISC-V
     - Quad-core RISC-V 64 bit Virt board in qemu (Sv39 MMU)

-Pharos is throughly tested (> 300 tests) and follows a strict quality procedure.
+Pharos is throughly tested (> 400 tests) and follows a strict quality procedure.

-The next release (3.3.0) is focusing on adding some more features, including thread restart and a partition restart. In particular the partition restart could be very useful as a safety measure. Imagine that your application has partitions developed for high criticality (and therefore are very well tested) but you could also have a "best effort" partition doing some stuff. If your application detects that this last partition has some problem (e.g. deadlock) you don't have to restart the whole system, you can just restart that partition.
+The next release (3.4.0) is focusing on adding some more features and correcting several bugs. See the ticket system for more information (select the tickets that have a milestone "3.4.0"). We hope to release "3.4.0" soon (< 1 month).

 Support is available. Please make use of the Ticket system if you found a bug, use the Discussions to place questions or contact us at **rtos.pharos@outlook.com**.

Home modified by Pharos Team

Pharos Team — Fri, 02 Aug 2019 17:50:03 -0000

--- v35
+++ v36
@@ -12,7 +12,7 @@

 Pharos third objective relates to real-time systems. That is, systems where you want to know that even in the worst overload scenarios your system will behave as expected. With this goal, Pharos provides a fixed-priority preemptive scheduler for uni-core and multi-core systems. Real-Time Operating Systems for uni-core systems are wide spread and although Pharos does bring some improvements (for example, a very fast clock tick processing routine that only awakes the highest priority thread, as opposed to awakening all the threads that are supposed to - note that Pharos still behaves as expected), Pharos major improvements come in multi-core systems were an "RMP" (Real-time MultiProcessing) design was introduced, as opposed to AMP or SMP. AMP (Assymetric MultiProcessing) is quite suitable for real-time systems since a core does not communicate with another. However, it can be improved by allowing some limited communication. SMP (Symmetric MultiProcessing) is used in systems like Linux/Windows. It is not suited for real-time systems given the overhead that it requires to manage threads from one core to another. For example, the scheduler requires a spin lock (bad idea in real-time systems) to determine which thread to execute on which core. Additionally, if a thread migrates from one core to another, its stack has to be dumped from one L1 cache to another. This overhead, in the worst case (required to calculate the WCET) is extremely bad. In some cases (for example, CPUs without cache snooping), the WCET is so bad that it is probably just better to use one core than multi-core with SMP. So basically Pharos uses RMP design as a midway solution between AMP and SMP. RMP does not use spin locks nor is thread migration possible. RMP uses only wait-free algorithms (note that it does not even use lock-free algorithms) for inter-core communication. A core can communicate with another via a "heavy weigh queue" (2-copy messages) or via a "channel" (0-copy messages). Note that with a channel, a partition can send a message of up to 1 GiB almost instantly, even from one core to another. 

-In Pharos, applications run in user mode (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware MMU/MPU if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-105989016
+In Pharos, applications run in user mode (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware MMU/MPU if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-310

 Pharos is available in open-source and under an Apache 2.0 license. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.

Home modified by Pharos Team

Pharos Team — Thu, 11 Jul 2019 07:16:45 -0000

--- v34
+++ v35
@@ -1,6 +1,19 @@
 Welcome to Pharos!

-Pharos is a Real-Time Operating System designed for secure systems. This means that applications run in user mode and cannot access the memory space outside its limits (otherwise an exception will be triggered by the hardware MMU/MPU) and must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-105989016
+Pharos is a Real-Time Operating System designed for secure systems. It is intended to by used by (in order of importance):
+
+ - secure systems
+ - safe systems
+ - real-time systems
+
+Secure systems are first and foremost the most important aspect of Pharos. This means that applications using Pharos should feel confident that security breaches are difficult to occur given the design of Pharos. Note that a badly designed application can always overcome the most perfect operating system but in Pharos a partition that has a inherent security issue will not be allowed to propagate that breach to other partitions (in terms of memory or time). The security driver was a major driver in placing Pharos as an open-source project (so that it could be scrutinized by everyone). 
+
+The second most important driver for Pharos regards its intent to be used in safety critical systems. Qualifying/certifying a piece of software for safety critical systems is a somewhat overwhelming endeavour. A lot of tasks have to be performed, including tests, documentation, verifications, etc. Pharos is not qualified today to any standard. However it is our medium/long term goal to produce qualification artifacts that provide enough confidence that Pharos can be used in critical systems. Today, Pharos source code (you can check it yourself) is designed according to MISRA2004/2012, has a good number of comments, the cyclomatic number and nesting level are not high. Additionally, we also produced a (non open-source) test suite composed by mostly validation tests (although a few unit tests as well). The test suite is roughly 3x the size of the source code. In addition we also keep an up-to-date user manual (open-source and you can download it freely from "Files" - https://sourceforge.net/projects/rtospharos/files/). We created also a high-level and low-level requirements documents (non open-source), however these are now outdated and need a revision to be kept on track for the new releases of Pharos. According to the standard that we could certify Pharos to, additional documentation/tests are needed. We are developing Pharos in our free-time, so we currently just don't have the resources to this. If you require certification and are willing to provide us with some resources, we are able to this job ;).
+
+Pharos third objective relates to real-time systems. That is, systems where you want to know that even in the worst overload scenarios your system will behave as expected. With this goal, Pharos provides a fixed-priority preemptive scheduler for uni-core and multi-core systems. Real-Time Operating Systems for uni-core systems are wide spread and although Pharos does bring some improvements (for example, a very fast clock tick processing routine that only awakes the highest priority thread, as opposed to awakening all the threads that are supposed to - note that Pharos still behaves as expected), Pharos major improvements come in multi-core systems were an "RMP" (Real-time MultiProcessing) design was introduced, as opposed to AMP or SMP. AMP (Assymetric MultiProcessing) is quite suitable for real-time systems since a core does not communicate with another. However, it can be improved by allowing some limited communication. SMP (Symmetric MultiProcessing) is used in systems like Linux/Windows. It is not suited for real-time systems given the overhead that it requires to manage threads from one core to another. For example, the scheduler requires a spin lock (bad idea in real-time systems) to determine which thread to execute on which core. Additionally, if a thread migrates from one core to another, its stack has to be dumped from one L1 cache to another. This overhead, in the worst case (required to calculate the WCET) is extremely bad. In some cases (for example, CPUs without cache snooping), the WCET is so bad that it is probably just better to use one core than multi-core with SMP. So basically Pharos uses RMP design as a midway solution between AMP and SMP. RMP does not use spin locks nor is thread migration possible. RMP uses only wait-free algorithms (note that it does not even use lock-free algorithms) for inter-core communication. A core can communicate with another via a "heavy weigh queue" (2-copy messages) or via a "channel" (0-copy messages). Note that with a channel, a partition can send a message of up to 1 GiB almost instantly, even from one core to another. 
+
+In Pharos, applications run in user mode (unless explicitly configured to run in supervisor mode) and cannot access the memory space outside its limits.  An exception will be triggered by the hardware MMU/MPU if a partition tries to access a memory area to which it does not have permissions. Also, and very important in real-time critical systems, a thread must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-105989016
+
 Pharos is available in open-source and under an Apache 2.0 license. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.

 We designed Pharos to provide to support mixed-criticality applications. In essence:

Home modified by Pharos Team

Pharos Team — Wed, 03 Jul 2019 19:04:24 -0000

--- v33
+++ v34
@@ -36,9 +36,8 @@

 One inovation that Pharos brings (to the best of our knowledge) is the introduction of filters for inter-partition objects. Inter-partition objects are not new themselves, but the way Pharos implements them and the way the application can use them is new (to the best of our knowledge). This mechanism is needed in multiple applications that have a resource (in the abstract sense of the word) that is used by multiple partitions but must be controlled. For example, a CAN driver can be used to transmit/receive messages from any partition. However, it should not be overloaded with messages from a faulty partition. Pharos introduces a  filter function that is invoked before the message is transmitted (to the message queue or channel) or the resource accessed. It is run in the context of the calling thread but with memory permissions and stack of the partition being invoked. For example, suppose partitions A, B and C can send messages to a message queue of partition Z, but partition D cannot send messages to this queue. The code executed in filter for the message queue will have the same memory permissions as partition Z and will run with a stack in partition Z. However Pharos will still account for the time taken in executing the filter to the calling thread. This means that a faulty thread can only damage its own execution time and this will have no impact on partition Z (or any other partition). In this case, the filter code that will check if the message being sent is from partition D and if so, rejects it. The application is free to create more complex filters, such as limit the number of messages per second being sent, reject messages if the CAN queue is approaching its limits, etc.

-Multicore is supported in AMP fashion on the ARM Cortex-A53. This means that each core can be viewed as running its own separate Pharos. Partitions are allocated to one core, including its threads, semaphores, queues, etc. There can be no inter-core communication through Pharos and the only way for one core to communicate with another is through the shared memory (there are some thoughts to increase the multicore functionality, stay tuned).
+Multicore is supported in RMP (Real-time MultiProcessing) fashion on all the supported multicore CPUs (currently ARM Cortex-A53 and RISC-V). RMP fashion  means that each core can be viewed as running its own separate Pharos but they can communicate between each other via channels or heavy weight queues. Partitions are allocated to one core, including its threads, semaphores, queues, etc. 

-
 The full list of currently supported CPUs is:

 - Arm
@@ -49,18 +48,18 @@
     - Hercules TMS570LC43x LaunchPad Development Kit (http://www.ti.com/tool/LAUNCHXL2-570LC43) in lock-step (one core in redundancy).

  - Cortex-M4 (armv7-M)
-    - STM32F469I-DISCO (https://www.st.com/en/evaluation-tools/32f469idiscovery.html). This board from ST has a STM32F469NIH6 CPU, running at 180 MHz, 64 KiB CCM SRAM (extremely fast SRAM), 320 KiB SRAM, 4 KiB Backup SRAM, 128 Mbit SDRAM, 2 MiB Flash and more. This is the first port that Pharos is ported to that has more than one type of memory. Pharos has been extended in such a way that an application can easily select the memory type where it wants part (or all) of its memory. 
+    - STM32F469I-DISCO (https://www.st.com/en/evaluation-tools/32f469idiscovery.html). This board from ST has a STM32F469NIH6 CPU, running at 180 MHz, 64 KiB CCM SRAM (extremely fast SRAM), 320 KiB SRAM, 4 KiB Backup SRAM, 128 Mbit SDRAM, 2 MiB Flash and more. This is the first port that Pharos is ported to that has more than one type of memory. Pharos has been extended in such a way that an application can easily select the memory type where it wants part (or all) of its memory. For example, you can place the stack of a thread on the fast CCM memory and a "large" global variable on the SDRAM, its up to you.
     - EK-TM4C129EXL (http://www.ti.com/tool/EK-TM4C129EXL)

  -  - Cortex-A53 (armv8-A)
     - Quad-core raspberry pi 3 in qemu

 - RISC-V
-    - Quad-core RISC-V 64 bit Virt board in qemu (Sv39)
+    - Quad-core RISC-V 64 bit Virt board in qemu (Sv39 MMU)

 Pharos is throughly tested (> 300 tests) and follows a strict quality procedure.

-The next release (3.2.0) is focusing on preparing the Pharos API to in the future, support the ARINC 653 APEX API. Besides this API having relevance in the aerospace world, it will extend the basic API offered by Pharos, increasing even more the provided features.
+The next release (3.3.0) is focusing on adding some more features, including thread restart and a partition restart. In particular the partition restart could be very useful as a safety measure. Imagine that your application has partitions developed for high criticality (and therefore are very well tested) but you could also have a "best effort" partition doing some stuff. If your application detects that this last partition has some problem (e.g. deadlock) you don't have to restart the whole system, you can just restart that partition.

 Support is available. Please make use of the Ticket system if you found a bug, use the Discussions to place questions or contact us at **rtos.pharos@outlook.com**.

Home modified by Pharos Team

Pharos Team — Mon, 29 Apr 2019 08:02:11 -0000

--- v32
+++ v33
@@ -1,7 +1,7 @@
 Welcome to Pharos!

 Pharos is a Real-Time Operating System designed for secure systems. This means that applications run in user mode and cannot access the memory space outside its limits (otherwise an exception will be triggered by the hardware MMU/MPU) and must execute within configurable time limits.  See a quick presentation on https://www.slideshare.net/RTOSPharos/pharos-105989016
-Pharos is available in open-source and under an Apache 2.0 license. This means that you can freely use on your public/private domain projects as you wish, free of cost. 
+Pharos is available in open-source and under an Apache 2.0 license. This means that you can freely use on your public/private domain projects as you wish, free of cost. A quick questionnaire is in https://docs.google.com/forms/d/12-MQ6OuYhEM_1gX_nI-93eMPPB9tmTAg4hZ8BL_DQMI/viewform?edit_requested=true#responses please take 5/10 min to answer this. Your feedback will give us the direction for the way to go.

 We designed Pharos to provide to support mixed-criticality applications. In essence: