RTEMS + PS3

[Joel Sherrill]

Steven Johnson wrote:
> The IBM Research Hypervisor is not the same interface as the Sony one.  
> They both utilise the System Call instruction to access functions of the 
> Hypervisor from the Supervisor space, but beyond that the similarity 
> ends. (at a programming level). 
>
>   
OK.  I just thought the fact it was on a simulator would be
save more trouble than it would create. 
> Targeting different Hypervisors may be useful, but at the moment I only 
> have access to the PS3 Hypervisor.
>   
I can't tell but the other may be freely downloadable.

The discussion below really should be captured in a Wiki
page.  We have had similar discussions in the past about
RTEMS on SMP hardware.
> I am very much concerned by the dual hardware thread nature of the Cell 
> PowerPC core.  It has 2 x 64 bit hardware threads operating (from a 
> software perspective it can be considered dual core).  I have only seen 
> RTEMS running on Single Processor - Multi Threaded systems or (seen, but 
> not used) multi-processor systems where each processor runs a copy of 
> rtems and each processor intercommunicates using rtems facilities.  What 
> are the issues when the Hardware threads are tightly coupled like the 
> Cell processor.  I would want RTEMS to schedule 2 simultaneously running 
> threads to each processor thread.  Are there any issues with that?  
Yes.  Internally RTEMS has  a _Thread_Executing variable.
This indicates the single thread TCB currently on the CPU.
This would have to be extended to an array of tasks per CPU
and scheduling decisions would have to be extended to
pick which CPU to bump a thread off of.

In order to be clean, the scheduling decisions may need to
be broken into subroutines so they can be conditionally
switched from "one CPU core" to "multiple CPU core" versions.
> has 
> it been done before?  
Not with RTEMS.

> Are there any examples I can look at?  
FreeBSD and other OSes have SMP support and would have
code to handle critical sections.  The actual scheduling
code would have to be unique to RTEMS.  The mechanics
of being on CPU A and switching threads on CPU B should
be readable in another OS.

Remember we would be scheduling threads on each cpu core.
If you are reading other OSes, be sure they also do that and
just don't schedule processes on each core.
> How will 
> this effect things like critical regions when getting a critical region 
> will not guarantee that the other hardware thread is not going to access 
> the thing the critical region seeks to protect (The PowerPC targets I am 
> aware of implement critical regions by turning of IRQ's, which is only 
> "per thread" and not global.
>
>   
There are two types of critical sections in RTEMS -- Dispatching
and interrupt.  Both would have to be enhanced to account for
the multi-core nature.

Dispatching allows interrupts but prevents other threads from
entering RTEMS critical sections.

Interrupt disable does what it says and more tightly protects
a critical section.

Luckily these are implemented completely inside dedicated
routines which are inlined.  So providing new algorithms could
be a compile time option.
> Forget the SPU's, because I don't intend to run RTEMS on them, they will 
> just be intelligent programmable peripherals.  Although it would be 
> feasible to port RTEMS to an SPU and implement a classic RTEMS 
> multi-processor implementation using them.  The limited ram in each 
> (256K) may restrict the viability of that however.
>
>   
With older versions of RTEMS, this would definitely be true.
With newer versions, it should be doable.  The BSP for an SPU
could be incredibly simple.  The IO could be minimal.  This would
help restrict the minimum footprint. 

We would just have to define a profile and make sure the RTEMS
pieces you didn't want/need didn't get linked in.
> Advice on the multi-threaded nature of this processor and best utilising 
> that on RTEMS would be very helpful.
>
>   
Search the archives for SMP RTEMS and you will find longer
more detailed discussions.  Building a Wiki page of the
ideas and issues would be a good thing.

This is doable.  It just takes addressing some fundamental
issues carefully.

--joel
> Thanks,
> Steven
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>