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.