<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-A3449F37-89BB-5208-8FD5-F4DF73F7E71A" xml:lang="en"><title>System
Startup Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-C41A0540-2C28-4CCC-B8AA-8236C68CEB18"><title> Configuring and Controlling a device's boot process </title> <p>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. </p> <p>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. </p> <p>There are numerous
considerations when configuring device startup. These include: </p> <ul>
<li id="GUID-5BA1769D-D1FC-59A4-87F6-30D031443CD9"><p>which processes, tasks
and applications are required, </p> </li>
<li id="GUID-48D7345B-0D3B-5ADA-A646-A3DAC85FE4F5"><p>the sequence of, and
inter-dependencies between, activities, </p> </li>
<li id="GUID-9C7A919A-8C67-5DC0-BDD8-D1DC12AE0636"><p>the user experience, </p> </li>
<li id="GUID-9F2C5CCC-EAD6-5AD6-8B85-7EB459F385BA"><p>the impact on manufacturing
and testing, </p> </li>
<li id="GUID-7212D20D-2A6C-51BC-A3B4-23FAF4CA5EC0"><p>operators' customisation
requirements, </p> </li>
<li id="GUID-1D75BFB9-9E0C-5E60-8473-278D3ABCF7B7"><p>users' customisation
requirements, </p> </li>
<li id="GUID-41225C9C-047B-59BF-A670-0981A73BF6FC"><p>what to do when something
goes wrong </p> <p>and </p> </li>
<li id="GUID-5E519AE8-3268-5C2B-A623-2E99229947F8"><p>aftermarket applications </p> </li>
</ul> <p><b>Processes and Applications </b> </p> <p>In the interest of readability
this document frequently<b> uses the terms application and process interchangeably</b>.
Unless specifically stated otherwise you may assume that the term used refers
to both. </p> </section>
<section id="GUID-528B2FD1-7233-413A-81C8-5064095135AB"><title>Static Startup Configuration</title> <p>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. </p> <p>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 <b>sequence</b> (wait for the application or
process to initialise before continuing) but also in <b>parallel</b> (do not
wait for initialisation) and <b>at the optimum time</b> (wait until conditions
are right). </p> <p>For further information on the contents of an SSC see: </p> <ul>
<li id="GUID-1F8911D9-F92B-5A4F-8548-942842A7ED2A"><p><xref href="GUID-57F38146-1DA3-5657-ADF4-76DF740363C5.dita">Static
Startup Configuration</xref>  </p> </li>
</ul> <p>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 <b>modes</b>. </p> <ul>
<li id="GUID-92E0E027-8A4F-55A5-AC48-4252164E2E77"><p>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 &amp; 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 (<xref href="mailto:td-os_base_services-dev@lists.symbian.org" scope="external">td-os_base_services-dev@lists.symbian.org</xref>)
specifying: </p> <ol id="GUID-E4D9A3AB-4BD5-5E5E-8B70-8E6435842F06">
<li id="GUID-9F4658CA-4DCE-5E88-91FC-AE0F3CA65997"><p>the device manufacturer
name </p> </li>
<li id="GUID-AA1CC293-099A-5534-BA71-3EEE6691BE53"><p>the number of start-up
mode ranges required (each range has 32 values)</p> </li>
</ol> </li>
</ul> <p>SSC files are named <filepath>SCCForStartupModeN.rss</filepath> 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. </p> <p>The degree
to which an SSC can control and optimise the boot process is further enhanced
by the concepts of <b>Startup States</b> and <b>Staged Startup</b>. </p> <p><b> Startup States</b> </p> <p>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: </p> <ul>
<li id="GUID-4C3113C7-CFAF-59AE-A271-51424F6B2478"><p> <b>The Critical Static
State:</b> This is when the essential ROM based components are started. Nothing
started in this state relies on anything outside the ROM. </p> </li>
<li id="GUID-56754FF8-08A4-56BE-A4C2-A8F2A25AE738"><p> <b> The Critical Dynamic
State:</b> This is when essential non-ROM based components and components
which use non-ROM based files are started. </p> </li>
<li id="GUID-804244EC-006E-5216-B286-D9FC6B9495EA"><p> <b> The Non-critical
State:</b> 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. </p> </li>
</ul> <p><b>Staged
Startup</b> </p> <p>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. </p> <p>Applications
must be <b>Staged Startup Aware (SSA)</b> 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 <b>stage</b> of
its startup during each SSC <b>state</b>. </p> <p>Staged startup subdivides
each state into five ordered domains: Kernel, Base, OS Services, Application
Services and UI Framework (these correspond to the <xref href="GUID-98E4DFEE-D7FA-581B-A56C-89797890D418.dita">Symbian
OS System Model</xref>). 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. </p> </section>
<section id="GUID-F58AE201-31BF-4E36-96B6-50D61A53B9CA"><title>Dynamic Startup Configuration (DSC) </title> <p>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). </p> <p>One or more DSCs may
be included at various points in an SSC. </p> <p>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. </p> <ul>
<li id="GUID-84D36270-880B-56F4-BBD9-5C80F9DA1BEF"><p><xref href="GUID-E3941FAF-988E-5FB3-8E62-84E192E41EA1.dita">How
to use the DSC API</xref>  </p> </li>
</ul> </section>
<section id="GUID-D6D28700-0BAD-4F88-8CE9-2E0330233468"><title>Specifying action on failure </title> <p>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. </p> <p>When
an application is started using an SSC or a DSC several parameters must be
specified in its resource. These include: </p> <ul>
<li id="GUID-4DC8B8DA-FA50-57E9-B1FD-B60991C927C1"><p>a startup method (<codeph>EFireAndForget</codeph>, <codeph>EWaitForStart</codeph>, <codeph>EDeferredWaitForStart</codeph>) </p> </li>
<li id="GUID-8236B8FB-CDD9-544A-91FA-F53231EDEDAF"><p>the number of retries
(attempts to start the application) </p> </li>
<li id="GUID-A9EA3792-BA99-59C8-8AE1-40A34CFAC095"><p>a timeout period (after
which an EWaitForStart startup will be considered to have failed) </p> </li>
<li id="GUID-F9CEA642-4140-5430-9092-C5B70BE9B691"><p>a restart action (<codeph>EIgnoreProcessFailure</codeph>, <codeph>ERestartOS</codeph>, <codeph>ERestartOSWithMode</codeph> - the action to be taken in the event of failure
to rendezvous or failure while running normally.) </p> </li>
<li id="GUID-F737C84D-3BAB-5256-858E-4D9EF9C0AB19"><p>a restart mode (the
phone might restart in a 'Safe Mode', for instance) </p> </li>
<li id="GUID-2030D3D4-D1C6-5E80-B75E-F8F656CA5168"><p>whether to initiate
monitoring after the component has made its rendezvous. </p> </li>
</ul> <p>If, after the <b>timeout period</b> the application has not made
its rendezvous, the OS can make further attempts to start it. If, after the <b>number
of retries</b> specified, it has not succeeded it will take the specified <b>restart
action</b>. If the restart action is <codeph>ERestartOS</codeph> or <codeph>ERestartOSWithMode</codeph> it
will shut down the device and restart it (in the second case in the <b>restart
mode</b> specified). If <b>monitoring</b> 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. </p> <ul>
<li id="GUID-64BFBF8C-3279-5DE5-9350-19DB7FD5D481"><p><xref href="GUID-4E195F2A-78AE-5664-A115-AD65BF457AB1.dita">How
to use the System Monitor</xref>  </p> </li>
</ul> <p>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 <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-AF3E8BE4-FE65-3CCE-8B5A-6C4585BEA2EC"><apiname>RThread::SetCritical()</apiname></xref>). 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. </p> </section>
</conbody></concept>