--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-A3449F37-89BB-5208-8FD5-F4DF73F7E71A.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,149 @@
+<?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>
\ No newline at end of file