System +Start Example

Resource files

In +this example a resource file SSCForStartupMode0.rss is used +at Start-up.

On a target device booting normally, the SSC SSCForStartupMode0.rss is +always used for start-up. This SSC is associated with startup mode zero, which +is defined as EStartupModeUndefined in e32modes.h. The +System Starter architecture provides an ability to select between a number +of static Start-up configurations (rss files) depending on the desired Start-up +Mode, for example: Full, Emergency, Charging, or Test. Each of these modes +may require different sets of components and order of execution.

The +start-up process in the resource file is staged via an ordering of Start-up +States or phases. These states cannot be removed or their values altered. +They appear in the following order:

EStartupStateUndefined – +Value before the system enters its first state/ undefined state.

EStartupStateCriticalStatic – +Within this Start-up State all ROM based (static) components or resources +that are critical to the operation of the phone function are started.

EStartupStateCriticalDynamic – +Within this Start-up State all non-ROM based (dynamic) components or resources +that are critical to the operation of the phone function are started.

EStartupStateNonCritical – +Within this Start-up State all ROM based (static) or non-ROM based (dynamic) +components or resources that are non-critical to the operation of the phone +function are started. All components that have not already been started and +are required at device boot are started in this Start-up State.

This +allows start-up to be split into separate, distinct states with a defined +order. Within each state, a STATE_INFO structure containing +information regarding that state is located. This contains the following information:

+ + + +

The id of the state as defined in the custom header file

+ + +

Name

A text string describing the state

+ + +

Command_list

The name of the Command array in the SSC which contains the list +of Commands to invoke in that state

+ + +

The name of the Command array corresponding to the next state

+ + + +

Following the STATE_INFO structure in the SSC +is a COMMAND_ARRAY structure. This contains details of all +commands to be executed within that list. Its name matches the command_list +identifier in the STATE_INFO struct and contains one array +entry: Commands. The Command entry contains a list of all commands to be executed. +Each instance in the rss file is headed with the START_PROCESS_INFO identifier +and contains any value needed to override the defaults specified in startup.rh.

+ + + +Type +

Set by default. Should not be specified in the SSC.

+ + +Path +

The location of the binary e.g. path = "Z:\sys\bin\fbserv.exe"

+ + +Args +

Arguments passed to the process.

+ + +start_method +

The enum TStartupCommandType is defined in startup.hrh. +Currently it takes one of three values:

EFireAndForget (the +default)
EWaitForStart
EDeferredWaitForStart

Use EFireAndForget if there is no need for the +process to be started serially in other words as soon as the process has been +invoked, the System Starter can continue with starting the next process without +waiting for the process to rendezvous.

Use EWaitForStart if +the process needs to get to a certain stage before starting the next process. +The starter cannot continue with the next Command until a rendezvous has been +made with the first process.

Note that the apparc component must be +started with mode EWaitForStart to allow connection with +the server to take place.

Use EDeferredWaitForStart if +there is no need to start the process serially, but at a later stage there +is a command which cannot be invoked until this process has initialized. Using +this value allows a number of commands to be started and the System Starter +to wait for them all at a later point in the SSC. This ensures later on that +the initializations of all EDeferredWaitForStart commands +have completed.

EWaitForStart and EDeferredWaitForStart depend +upon receiving a rendezvous from the started process. By default this is performed +automatically by EikonEnv. If however, you wish your component to perform +its own rendezvous, then the following function should be overridden in your +AppUi class and return EFalse.

TBool CCoeAppUi::FrameworkCallsRendezvous();

+ + +timeout +

This field is for use with start_method EWaitForStart only.

Indicate +if a timer should be started when attempting to start the process by filling +in this timeout value in milliseconds. The value is 0 by default indicating +that no timer will be started.

Note that if the timer expires before +a rendezvous with the component is made, the component will be killed. If +the component is a critical process this will result in a Kern:4 Panic (which +on licensee phones usually initiates in a system restart).

+ + +retry_failure_recovery_method +

This specifies the action to take if an error is returned from an +attempt to start the process.

It is set to ERestartOS by +default. This means if the process fails to start the system will restart +in the default start-up mode.

If it is set to EIgnoreOnFailure then +the starter will continue with the next Command. This option is intended for +non-critical components on which nothing critical is dependent.

If +it is set to ERestartOSWithMode the system will be restarted +in a specific start-up mode.

Note: this field has a slightly different +use depending on the start mode: in modes EFireAndForget and EDeferredWaitForStart a +failure will be indicated only if there is an immediate error for example +the initial process creation/invocation fails. In EWaitForStart a +failure will also be indicated if there is no successful rendezvous.

+ + +no_of_retries_on_failure +

For use with start_method EWaitForStart only. +Set to 0 by default.

This specifies the maximum number of times the +starter should try to start a failed process. After the process has been retried +the specified number of times, the starter will act according to the value +in the retry_failure_recovery_method field. This is used +in conjunction with the timeout value.

+ + +monitor +

Indicates whether the started process should be monitored for failure +by the System Monitor component. The value is 0 by default indicating that +no monitoring will be done.

A value of 1 indicates monitoring should +be performed. The recovery policy set by retry_failure_recovery_method (and +if applicable retry_failure_recovery_startup_mode) will be used by the System +Monitor if a failure occurs to this process during the lifetime of the system.

Note: +if the component being started is a System Critical process, monitoring must +not be enabled.

+ + +retry_failure_recovery_startup_mode +

For use with retry_failure_recovery_method ERestartOSWithMode only.

Used +to specify the start-up mode the system should restart with. This is set to EStartupModeUndefined by +default.

+ + + +