System -Startup Overview

Configuring and Controlling a device's boot process

Whenever -a Symbian device is powered up a number of things have to happen before it -is ready to be used. A number of processes and applications have to be started -and certain tasks performed.

The System Starter and its related components -control the startup process. This guide describes what the System Starter -does and how it may be configured. Configuration is the responsibility of -device manufacturers. A manufacturer may choose to enable operators, third -parties and users to extend the startup configuration.

There are numerous -considerations when configuring device startup. These include:

which processes, tasks -and applications are required,
the sequence of, and -inter-dependencies between, activities,
the user experience,
the impact on manufacturing -and testing,
operators' customisation -requirements,
users' customisation -requirements,
what to do when something -goes wrong

and
aftermarket applications

Processes and Applications

In the interest of readability -this document frequently uses the terms application and process interchangeably. -Unless specifically stated otherwise you may assume that the term used refers -to both.

Static Startup Configuration

The System Starter -is automatically invoked as part of the boot process once the file system -has been mounted. It works by processing a list of instructions in sequence. -The list is referred to as a Static Startup Configuration, or SSC. In practical -terms the SSC is defined in a resource file and is built into the ROM.

A -fundamental feature of the SSC is that it allows the start up procedure to -be optimised. Though the commands are processed in sequence their effect is -to perform tasks not only in sequence (wait for the application or -process to initialise before continuing) but also in parallel (do not -wait for initialisation) and at the optimum time (wait until conditions -are right).

For further information on the contents of an SSC see:

Static -Startup Configuration

Though an SSC cannot be changed, a number of SSCs may be included -in a ROM. This allows a device to be started with one of a number of different -configurations, i.e. to be booted into different modes.

The mode determines -which SSC the System Starter uses to start the system. Symbian has defined -(and reserved) a number of Startup Modes (for test and reference purposes): -Full, Emulator, Emergency, Battery charge & Test. Device manufacturers -may use their own startup modes and reserve their own unique range of values -by sending an email to the Device Services package mailing list (td-os_base_services-dev@lists.symbian.org) -specifying:
1. the device manufacturer -name
2. the number of start-up -mode ranges required (each range has 32 values)

SSC files are named SCCForStartupModeN.rss where -N is the number of the mode. The method of selecting the mode, and therefore -the SSC file, for each startup is defined by the licensee.

The degree -to which an SSC can control and optimise the boot process is further enhanced -by the concepts of Startup States and Staged Startup.

Startup States

An SSC is divided into a series of states which -follow each other sequentially. Those described here are defined by Symbian. -Licencees may add or insert further states by defining them and including -them in an SSC. The Symbian defined states have a certain significance:

The Critical Static -State: This is when the essential ROM based components are started. Nothing -started in this state relies on anything outside the ROM.
The Critical Dynamic -State: This is when essential non-ROM based components and components -which use non-ROM based files are started.
The Non-critical -State: Components started here are not essential for the basic functionality -of the device. i.e. the phone will be 'up and running' before these components -are started.

Staged -Startup

A further level of startup control and configuration can -be achieved using Staged Startup. This technique enables components to perform -their initialisation procedure as separate stages - essential earlier, non-essential -later. This enables further reduction of the effective boot time.

Applications -must be Staged Startup Aware (SSA) to take advantage of the staged -startup facilities. They must register with the Starter so that they can receive -state-change notifications. An SSA application may perform a stage of -its startup during each SSC state.

Staged startup subdivides -each state into five ordered domains: Kernel, Base, OS Services, Application -Services and UI Framework (these correspond to the Symbian -OS System Model). Each SSA component associates itself with a domain -according to its location in the System Model. Within each state the domains -are processed sequentially. This allows application dependency to be accommodated -without individual applications having to manage these dependencies.

Dynamic Startup Configuration (DSC)

All of the -components included in the Static Startup Configuration are present for the -life of the device. Components installed after the ROM has been built, or -after the device has been shipped, may also be started during boot by being -added to a Dynamic Startup Configuration (DSC).

One or more DSCs may -be included at various points in an SSC.

A run-time API allows entries -to be added to and deleted from a DSC. This means that aftermarket applications, -updates and patches can be inserted automatically on installation, over the -air by a Network Operator, or by the user.

How -to use the DSC API

Specifying action on failure

Though system startup -is an automatic process, things can go wrong. In some cases the device can -continue to function if a component fails to start, in others it cannot. Applications -can fail to start or fail after they have started for a variety of reasons. -Symbian OS provides mechanisms for detecting and handling failure.

When -an application is started using an SSC or a DSC several parameters must be -specified in its resource. These include:

a startup method (EFireAndForget, EWaitForStart, EDeferredWaitForStart)
the number of retries -(attempts to start the application)
a timeout period (after -which an EWaitForStart startup will be considered to have failed)
a restart action (EIgnoreProcessFailure, ERestartOS, ERestartOSWithMode - the action to be taken in the event of failure -to rendezvous or failure while running normally.)
a restart mode (the -phone might restart in a 'Safe Mode', for instance)
whether to initiate -monitoring after the component has made its rendezvous.

If, after the timeout period the application has not made -its rendezvous, the OS can make further attempts to start it. If, after the number -of retries specified, it has not succeeded it will take the specified restart -action. If the restart action is ERestartOS or ERestartOSWithMode it -will shut down the device and restart it (in the second case in the restart -mode specified). If monitoring is enabled the System Monitor will -continue to monitor the process after a successful rendezvous and, if it stops -unexpectedly at any time, will re-use the same configuration information and -act accordingly.

How -to use the System Monitor

Note that processes or threads declared 'System Critical' use an -aternative monitoring mechanism, which pre-dates the System Monitor, to restart -the OS when they fail (see RThread::SetCritical()). The -System Monitor offers two significant advantages: the ability to restart the -process without restarting the OS and the option of restarting in a specified -mode.

+ + + + + +System +Startup Overview +

Configuring +and Controlling a device's boot process

Whenever a Symbian device +is powered up a number of things have to happen before it is ready to be used. +A number of processes and applications have to be started and certain tasks +performed.

The System Starter and its related components control the +startup process. This guide describes what the System Starter does and how +it may be configured. Configuration is the responsibility of device manufacturers. +A manufacturer may choose to enable operators, third parties and users to +extend the startup configuration.

There are numerous considerations +when configuring device startup. These include:

which processes, tasks +and applications are required,
the sequence of, and +inter-dependencies between, activities,
the user experience,
the impact on manufacturing +and testing,
operators' customisation +requirements,
users' customisation +requirements,
what to do when something +goes wrong

and
aftermarket applications

Processes and Applications

In the interest of readability +this document frequently uses the terms application and process interchangeably. +Unless specifically stated otherwise you may assume that the term used refers +to both.

Static Startup +Configuration

The System Starter is automatically invoked as part +of the boot process once the file system has been mounted. It works by processing +a list of instructions in sequence. The list is referred to as a Static Startup +Configuration, or SSC. In practical terms the SSC is defined in a resource +file and is built into the ROM.

A fundamental feature of the SSC is +that it allows the start up procedure to be optimised. Though the commands +are processed in sequence their effect is to perform tasks not only in sequence (wait +for the application or process to initialise before continuing) but also in parallel (do +not wait for initialisation) and at the optimum time (wait until conditions +are right).

For further information on the contents of an SSC see:

Static +Startup Configuration

Though an SSC cannot be changed, a number of SSCs may be included +in a ROM. This allows a device to be started with one of a number of different +configurations, i.e. to be booted into different modes.

The mode determines +which SSC the System Starter uses to start the system. Symbian has defined +(and reserved) a number of Startup Modes (for test and reference purposes): +Full, Emulator, Emergency, Battery charge & Test. Device manufacturers +may use their own startup modes and reserve their own unique range of values +by sending an email to the Device Services package mailing list (td-os_base_services-dev@lists.symbian.org) specifying:
1. the device manufacturer +name
2. the number of start-up +mode ranges required (each range has 32 values)

SSC files are named SCCForStartupModeN.rss where +N is the number of the mode. The method of selecting the mode, and therefore +the SSC file, for each startup is defined by the licensee.

The degree +to which an SSC can control and optimise the boot process is further enhanced +by the concepts of Startup States and Staged Startup.

Startup +States

An SSC is divided into a series of states which follow +each other sequentially. Those described here are defined by Symbian. Licencees +may add or insert further states by defining them and including them in an +SSC. The Symbian defined states have a certain significance:

The Critical Static +State: This is when the essential ROM based components are started. Nothing +started in this state relies on anything outside the ROM.
The Critical Dynamic +State: This is when essential non-ROM based components and components +which use non-ROM based files are started.
The Non-critical +State: Components started here are not essential for the basic functionality +of the device. i.e. the phone will be 'up and running' before these components +are started.

Staged Startup

A further level of startup control and +configuration can be achieved using Staged Startup. This technique enables +components to perform their initialisation procedure as separate stages - +essential earlier, non-essential later. This enables further reduction of +the effective boot time.

Applications must be Staged Startup Aware +(SSA) to take advantage of the staged startup facilities. They must register +with the Starter so that they can receive state-change notifications. An SSA +application may perform a stage of its startup during each SSC state.

Staged +startup subdivides each state into five ordered domains: Kernel, Base, OS +Services, Application Services and UI Framework (these correspond to the Symbian +System Model). Each SSA component associates itself with a domain according +to its location in the System Model. Within each state the domains are processed +sequentially. This allows application dependency to be accommodated without +individual applications having to manage these dependencies.

Dynamic Startup +Configuration (DSC)

All of the components included in the Static +Startup Configuration are present for the life of the device. Components installed +after the ROM has been built, or after the device has been shipped, may also +be started during boot by being added to a Dynamic Startup Configuration (DSC).

One +or more DSCs may be included at various points in an SSC.

A run-time +API allows entries to be added to and deleted from a DSC. This means that +aftermarket applications, updates and patches can be inserted automatically +on installation, over the air by a Network Operator, or by the user.

How +to use the DSC API

Specifying +action on failure

Though system startup is an automatic process, +things can go wrong. In some cases the device can continue to function if +a component fails to start, in others it cannot. Applications can fail to +start or fail after they have started for a variety of reasons. Symbian provides +mechanisms for detecting and handling failure.

When an application +is started using an SSC or a DSC several parameters must be specified in its +resource. These include:

a startup method (EFireAndForget, EWaitForStart, EDeferredWaitForStart)
the number of retries +(attempts to start the application)
a timeout period (after +which an EWaitForStart startup will be considered to have failed)
a restart action (EIgnoreProcessFailure, ERestartOS, ERestartOSWithMode - the action to be taken in the event of failure +to rendezvous or failure while running normally.)
a restart mode (the +phone might restart in a 'Safe Mode', for instance)
whether to initiate +monitoring after the component has made its rendezvous.

If, after the timeout period the application has not made +its rendezvous, the platform can make further attempts to start it. If, after +the number of retries specified, it has not succeeded it will take +the specified restart action. If the restart action is ERestartOS or ERestartOSWithMode it +will shut down the device and restart it (in the second case in the restart +mode specified). If monitoring is enabled the System Monitor will +continue to monitor the process after a successful rendezvous and, if it stops +unexpectedly at any time, will re-use the same configuration information and +act accordingly.

How +to use the System Monitor

Note that processes or threads declared 'System Critical' use an +aternative monitoring mechanism, which pre-dates the System Monitor, to restart +the platform, when they fail (see RThread::SetCritical()). +The System Monitor offers two significant advantages: the ability to restart +the process without restarting the platform, and the option of restarting +in a specified mode.

\ No newline at end of file