sebastian.huber at embedded-brains.de
Fri Mar 7 07:38:53 UTC 2014
On 2014-03-07 03:25, Chris Johns wrote:
> On 6/03/2014 9:04 pm, Sebastian Huber wrote:
>> there is a potential problem in the SMP initialization procedure.
>> One processor in the system has a special role, the so called boot
>> processor. Currently this is the processor with index zero. The way to
>> select the boot processor may change in the future, but what will not
>> change is that we have a boot processor.
>> The boot processors initializes the data and BSS sections. It performs
>> also the sequential part of the RTEMS initialization.
>> During the sequential initialization the function
>> * @brief Performs CPU specific SMP initialization in the context of
>> the boot
>> * processor.
>> * This function is invoked on the boot processor by RTEMS during
>> * initialization. All interrupt stacks are allocated at this point in
>> * the CPU port allocates the interrupt stacks.
>> * The CPU port should start secondary processors now.
>> * @param[in] configured_cpu_count The count of processors requested by
>> * application configuration.
>> * @return The count of processors available for the application in the
>> * This value is less than or equal to the configured count of processors.
>> uint32_t _CPU_SMP_Initialize( uint32_t configured_cpu_count );
>> called. This function is currently implemented by the BSPs. An example
>> which starts the processor on its own:
>> An example which uses U-Boot to start the second processor:
>> The return value of _CPU_SMP_Initialize() will tell the RTEMS system how
>> many processors are present.
>> void _SMP_Handler_initialize( void )
>> uint32_t max_cpus = rtems_configuration_get_maximum_processors();
>> uint32_t cpu;
>> * Discover and initialize the secondary cores in an SMP system.
>> max_cpus = _CPU_SMP_Initialize( max_cpus );
>> _SMP_Processor_count = max_cpus;
>> If the BSP says "you have three processors", and one of them is actually
>> not available, then we have a problem later.
>> Before the system starts multitasking there is a synchronization
>> barrier. This synchronization barrier is necessary to have a defined
>> starting point for the scheduler.
> Just to be clear here I assume this means when the scheduler starts the defined
> resources are present and there is no degraded mode to be supported by RTEMS.
> Getting the processors to the same point means the application can assume a
> specific runtime scheduling profile from the start. What happens after this is
> the application's problem and RTEMS makes no further checks. It also means
> RTEMS cannot be started with cores in a powered down state and enable them on
> demand at the application level.
>> I am in favor of 1. in combination with 2.1 and 220.127.116.11. For BSPs with
>> unreliably start of secondary processors we should add a support
>> function, e.g.
>> * @brief Waits for all other processors to enter the ready to start
>> * multitasking state with a timeout in microseconds.
>> * In case one processor enters the shutdown state, this function does not
>> * return.
>> * This function should be called only in _CPU_SMP_Initialize() if
>> required by
>> * the CPU port or BSP.
>> * @param[in] processor_count The processor count which will later
>> returned by
>> * _CPU_SMP_Initialize().
>> * @param[in] timeout_in_us The timeout in microseconds.
>> * @retval true All other processors entered the ready to start
>> * state.
>> * @retval false Not all the other processors entered the ready to start
>> * multitasking state and the timeout expired.
>> bool _Per_CPU_State_wait_for_ready_to_start_multitasking(
>> uint32_t processor_count,
>> uint32_t timeout_in_us
>> This avoids the burden for the application developer to know about the
>> timeout configuration option and to select a proper value.
>> It moves the
>> responsibility to deal with issue to the BSP which knows best what to
>> do. In case false is returned it can either issue a fatal error or
>> reduce the processor count.
> Can I assume the BSP can use a call to see which cores are present and which
> are not, eg state of a cpu ? Peeking the per CPU struct is not a good idea.
> The approach seems reasonable.
Please have a look at the attached patch.
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2689 bytes
Desc: not available
More information about the devel