<?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 & 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="http://developer.symbian.org/wiki/index.php/Symbian_System_Model" scope="external">Symbian

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 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 platform 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 platform, 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 platform, and the option of restarting

in a specified mode. </p> </section>

</conbody></concept>