--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-A3449F37-89BB-5208-8FD5-F4DF73F7E71A.dita	Wed Mar 31 11:11:55 2010 +0100
@@ -0,0 +1,150 @@
+<?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="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>
\ No newline at end of file