[GSOC 2013] - RTEMS Run-Time Oriented projects and Raspberry Pi BSP

[Joel Sherrill]

On 2/26/2013 10:03 AM, Sagara Paranagama wrote:
> Hi all,
>
> I'm Sagara Paranagama and I'm an undergraduate from the University of 
> Peradeniya, Sri Lanka. I took a look at the projects listed at[1] and 
> thought of contributing towards the RTEMS Run-Time Oriented projects 
> for GSOC 2013.
>
> I've got a couple of questions.
>
> 1. What are the projects in the Run-Time Oriented section which are 
> relevant to GSOC 2013? (I found that some were already completed in 
> GSOC 2012) To be a bit specific, I'd like to know whether any areas 
> are open for development in the SuperCore Scheduler and TinyRTEMS.
>
We are due for some updates there. :(

I have one Scheduler project in mind that is not written up yet.  I hope 
this quick
description gives you the right idea.

RTEMS manages sets of tasks/threads. Some are sets waiting on resources.
There is a set of tasks ready to execute. There is a set of tasks executing
(1-n depending on number of cores).

This task has a series of steps which make this more obvious at the 
SuperCore
level. Names suck at this point but hopefully this makes sense.

+ Create SuperCore Handlers for Task Sets:
    - Refactor "FIFO for Priority Ordering" from Scheduler Simple into
      something like "ThreadSetSimplePriority"
    - Refactor priority discipline from Thread Queue (e.g. Block 2-n 
structure)
      and name it something like "ThreadSetBlock2nPriority"
    - Reflactor Thread Set from Deterministic Priority Scheduler and
     name it something like "ThreadSetDeterministicPriority"
+ Add Scheduler which uses Block2-n
+ Rework Scheduler Simple SMP to use Block 2-n (if feasible)
+ Run Timing Tests with each scheduler as default
     - A report on this is desirable
     - Helping provide more guidance in selecting a scheduler is important.

Deterministic Priority Scheduler is O(constant)
Simple Priority Scheduler has some operations that are O(number of tasks)
Simple Scheduler SMP has some O(number of tasks) and others which are
    O(number of cores)
Block2N based scheduler would be bounded but worst case basically 
O(constant).
   It can iterate a few times but that has a maximum that is designed in.

TinyRTEMS projects are harder to come by and require quite a bit of 
finesse at this
point. We still need something like the BSD kernel initial for our init. 
I think this is
prototyped but not fully implemented.

The other idea is that most small target architectures do not use 
newlib. One
possibility is to use avr-libc instead of newlib with the avr port. The 
AVR maintainers
have privately expressed willingness to accept RTEMS specific patches. 
This would
shrink the footprint of the AVR port, likely adding magic to select the 
correct
support code for a particular C library, and possibly disabling things 
which do not
fit or simply are beyond the capabilities of the C Library and target.

In general, the AVR port would require verifying that even hello ran 
before you
started. :)

Other C Libraries have been mentioned but the general idea of using a 
different
C Library is a good GSOC project but not something that has been widely
discussed.

> 2. Where can I find more information in developing a BSP for the 
> Raspberry Pi? (ex: a contact person, partial implementation etc.) I 
> have a RPi so I'm extremely interested in this project :)
>
This is underway. A BSP has been submitted this week and is under review.
It only has basic functionality so there is a lot of room to add 
capabilities to
it. Alan Cudmore wrote what there is. The Pi Project will change to be "add
drivers". But this is a good thing with plenty of work.
> [1] - http://www.rtems.org/wiki/index.php/Open_Projects
>
> Thanks
> Sagara Paranagama


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985