[PATCH 2/4] score: SMP initialization and shutdown changes

[Chris Johns]

On 21/02/2014 3:31 am, Sebastian Huber wrote:
> Hello Chris,
>
> On 2014-02-20 03:50, Chris Johns wrote:
>> On 20/02/2014 12:42 am, Sebastian Huber wrote:
>>> +/**
>>> + * @brief State of a processor.
>>> + *
>>> + * @dot
>>> + * digraph states {
>>> + *   bi [label="PER_CPU_STATE_BEFORE_INITIALIZATION"];
>>> + *   rsm [label="PER_CPU_STATE_READY_TO_START_MULTITASKING"];
>>> + *   sm [label="PER_CPU_STATE_START_MULTITASKING"];
>>> + *   ds [label="PER_CPU_STATE_DO_SHUTDOWN"];
>>> + *   u [label="PER_CPU_STATE_UP"];
>>> + *   s [label="PER_CPU_STATE_SHUTDOWN"];
>>> + *   bi -> rsm [label="secondary processor\ncompleted initialization"];
>>> + *   bi -> u [label="main processor\nstarts multitasking"];
>>> + *   rsm -> sm [label="main processor\ncompleted initialization"];
>>> + *   rsm -> ds [label="a fatal error occurred"];
>>> + *   ds -> s [label="do shutdown\nstate observed"];
>>> + *   sm -> u [label="secondary processor\nstarts multitasking"];
>>> + *   u -> s [label="shutdown initiated"];
>>> + * }
>>> + * @enddot
>>
>> I do not see sm to ds if the main core goes to s after going from bi
>> to u ?
>>
>> I also see u to s and not to ds; why as the state is called "do
>> shutdown" ?
>> Should this state be PER_CPU_STATE_SHUTTING_DOWN ?
>
> I had to change the procedure considerably since I noticed unsolvable
> problems with the previous approach based only on atomic read/write
> operations. Attached is the new state diagram.
>

I do not follow this picture. I am assume there is one state machine per 
CPU and so I do not see where the state "starting multitasking" is. I 
see a state called "request start multitasking" then "up" and I am 
wondering what the state is after the request has happened and before up.

>>
>> I do not see why we have main and secondary processors ?
>
> I changed "main processor" into "boot processor" to highlight that this
> is only the case during system boot.
>

Is there any code checking the processor number ? I see it in the

>> This is symmetric
>> multiprocessing which means each core is the same therefore capable of
>> completing any required task. I understand there are paths which need to
>> complete so if we have states for these phases as gates then any
>> processor that
>> arrives should be able to enter the gate (spinning lock for those that
>> need to
>> wait) and complete the work. This means a degraded state can exist and
>> things
>> at least start. The application would need to detect and manage the
>> degraded
>> state and so RTEMS should not be concerned with this condition other
>> than doing
>> its best to run where possible.
>
> In case the boot procedure of the system is unstable then it makes no
> sense to run an application.
>

This depends on the application and its system requirements and how the 
hardware is constructed. A boot monitor can see cores are not present 
and decide not to start RTEMS or it can decide to start a single core. 
This relates to the system's requirement and can vary and has little to 
do with RTEMS. If a boot monitor passes control to RTEMS then it should 
run and only fail if it's integrity it not correct. RTEMS does should 
not move into the area of system requirements or constraints. Adding 
constraints like this in the operating system does not seem a good idea 
to me.

>>
>> I assume if we have n cores where n is 1..cpus available we enter the
>> static
>> constructors once and 'main' [1] once and this independent of the
>> number of
>> defined and/or operating cores. If an application's static constructor
>> starts
>> further threads it needs to manage the concurrency issues and main is
>> only
>> entered once.
>
> This change is about the low-level boot procedure.  High level concepts
> like threads are not an issue here.
>

They are if you remove the all cores needing to sync plus using cpu 
numbers to control which cores go through to the static constructors and 
main and which cores go direct to the score thread code. It is this sort 
of code that concerns me ...

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/include/arm-a9mpcore-start.h#n88

http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/shared/start/start.S#n226

I see no need for this code if the per cpu and the system level state 
are handled symmetrically. That is all cores enter the same entry point 
and the state manages where and what they need to do.

By the way is there a LEON4 or LEON5 in the works so is this dependence 
on LEON3 because it is the first to support SMP or because it is 
specific to this variant of the cpu ?

>>
>> [1] I am not concerned with the Classic API init task tables with more
>> than one
>> init task and what happens with static constructors as this is not
>> defined by
>> any standard. I will never directly use init task tables because it is
>> not
>> portable. All we can do is make sure static constructors and
>> destructors are
>> only called once.
>
> Yes, the constructor calls are an open issue.
>

Well lets get the issue on the table and discuss it. I see it is very 
much a part of this discussion and the overall design.

Chris