RTA Knowledge Base

Skip to end of banner
Go to start of banner

How to Startup Multicore Systems

Introduction

Modern microcontrollers and SoCs (Systems-on-Chip) typically have multiple cores. To make use of this additional processing power, it is necessary to distribute application and Basic Software (BSW) across cores (see also Multicore and AUTOSAR for an introduction to multicore in general and an explanation of the terminology).

The start-up of a multicore system with distributed BSW (see also BSW Distribution Strategies) requires some extensions compared to a single core system (described in detail in EcuM Startup Sequence).

The AUTOSAR Layered Software Architecture contains the following top-level architecture diagram:

  • There is one EcuM (ECU State Manager) per core (each in a trusted partition).
  • The EcuM on the core that is started after reset is the master EcuM.
    • Assumption: only the master core (usually core 0) starts running after a reset, while the satellite cores (core 1..n) initially start halted.
  • The master EcuM starts all satellite EcuMs.
  • There is a BswM (BSW Mode Manager) in every partition that runs BSW modules (all these partitions are trusted).
  • The OS (Operating System) is aware of all configured cores and implements partitions as OS Applications.
  • Other BSW modules can be distributed across several partitions and cores (see also recommended BSW Distribution Strategies).

The AUTOSAR SWS ECUStateManager contains the following overview of the start-up phase:

Toolchain

It is assumed you are using the RTA-CAR 12.7.0 toolchain:

ToolVersion
ISOLAR-AB12.7.0
RTA-RTE12.7.2
RTA-BSW12.7.0
RTA-OS12.6.0

Multicore Startup Sequence

The following sequence diagram provides an overview of the start-up sequence on a microcontroller with 2 cores: 

Boot and C Init Code

AUTOSAR does not specify these target-specific low-level parts. Typical activities in this phase could be:

  • Set up clock tree, wait for PLL lock.
  • Execute built in self-test (BIST).
  • Set up memory, stack pointer.
  • Wait for external flash being available.
  • Further set-up of each core.
  • And finally a call to EcuM_Init().


RTA-OS delivers a placeholder implementation for this, but it is the responsibility of the user to write this code. Further advice specific to each HW can be found in the Target/Compiler Port Guide.

EcuM StartPreOS Sequence

The EcuM StartPreOS Sequence is triggered by a call to EcuM_Init() on every core. Its goal is to prepare this core for a start of the OS.

EcuM_Init() contains a couple of call-outs defined in AUTOSAR_CP_SWS_ECUStateManager. They are mostly applicable for both single core and multicore systems and are therefore also described in EcuM Startup Sequence. The main extension in a multicore system is that there is one dedicated master core that starts up first and subsequently starts the other cores.

  • GetCoreID() identifies the core we’re currently running on.
    • This is needed to distinguish code parts that shall run e.g. only on the master core.
  • EcuM_AL_SetProgrammableInterrupts() sets programmable interrupt priorities before the OS is started (only on the master core).
  • EcuM_AL_DriverInitZero() initializes drivers required to find the correct post-build configuration.
    • It calls the initialization functions configured in EcuMDriverInitListZero. (Caveat: these initialization functions must not use post-build configuration on their own. Therefore, there is no possibility to configure EcuMModuleParameter.)
    • Which EcuMDriverInitItem runs on which core is configured via the item's EcuMEcucCoreDefinitionRef (the default is only on the master core).
    • The example below shows EcuMDriverInitListZero executed only on the master core:

  • EcuM_DeterminePbConfiguration() returns a pointer to a fully initialized EcuM_ConfigType structure containing the post-build configuration data for the ECU Manager module and all the other BSW modules (only on the master core).
  • EcuM_AL_DriverInitOne() initializes the drivers required to start the OS.
    • It calls the functions configured in EcuMDriverInitListOne.
    • Here post-build configuration can be used. This means POSTBUILD_PTR can be configured as EcuMModuleParameter.
    • Which EcuMDriverInitItem runs on which core is configured via the item's EcuMEcucCoreDefinitionRef (the default is only on the master core).
    • The example below shows EcuMDriverInitListOne with some initialization functions called on core 1.

  • StartCore() starts all the configured cores (Core 0 and Core 1 in the example shown in the sequence diagram above).
    • Each core starts running its main function, which calls EcuM_Init().
  • StartOS() starts the OS.
    • The StartOS() call does not return.
    • At that point, the OS executes the StartupHook() and it activates auto-start tasks (this is configured on the task, through OsTaskAutostart that references the OSDEFAULTAPPMODE).
    • Either mechanism can be used to call EcuM_StartupTwo() as long as it is started immediately after StartOS() is called.

EcuM StartPostOS Sequence

The EcuM StartPostOS Sequence is triggered by a call to EcuM_StartupTwo() on every core. Its goal is to bring up the core's basic BSW infrastructure with SchM and BswM.

The call sequence of EcuM_StartupTwo() is as follows:

  • GetCoreID() identifies the core we’re currently running on.
    • This is needed to distinguish code parts that shall run e.g. only on the master core.
  • BswM_Init() initializes the BswM (only on the master core).
  • SchM_Init() initializes the SchM and starts BSW scheduling.

Further Initialization via BswM

Now that the basic BSW infrastructure is up and running, further initializations can be done within the desired task and partition contexts on Core 0 or Core 1 by triggering BswM mode requests with immediate processing that leads to the execution of appropriate BswM action lists.

E.g.:

  • Use the BswM action BswMEcuMDriverInitListBswM to trigger the execution of functions configured in the EcuM driver initialization list EcuMDriverInitListBswM.
  • Use the BswM action BswMUserCallout to trigger the execution of individually configured initialization functions.
  • Use the BswM action BswMRteStart to trigger the call of Rte_Start().

RTA-CAR Extensions

Configuration of the Sequence of EcuMDriverInitItems

AUTOSAR defines EcuMDriverInitItem with the attribute requiresIndex = true. This means that the value elements shall be provided with an index that is usually derived from the order in which the value elements are configured. This also means, however, that it is not allowed to split instances across several files.

To support splitting, there is an ETAS-specific parameter EcuMRbSequenceID that works across several files.

Earlier Start of Satellite Cores

The typical sequence is to run EcuM_Init() on the master core (usually Core 0) and start the satellite cores after EcuM_AL_DriverInitOne() has finished.

There is an ETAS-specific parameter called EcuMRbSlaveCoreEarlierStart, which will start the satellite cores after EcuM_AL_DriverInitZero() and before EcuM_AL_DriverInitOne() is called on the master core. Please note that this means the DriverInitOne functions on all cores will run concurrently, so they cannot rely on any initialization of the start-up core being complete. If there is such a dependency, additional synchronization must be added.

References

  • No labels