as) United States
`a2) Patent Application Publication co) Pub. No.: US 2009/0307478 Al
`
` Gehrmann (43) Pub. Date: Dec. 10, 2009
`
`
`US 20090307478A1
`
`(54) PLATFORM BOOT WITH BRIDGE SUPPORT
`
`(30)
`
`Foreign Application Priority Data
`
`(76)
`
`Inventor:
`
`Christian Gehrmann,Lund (SE)
`
`(EP) sisessessmenesnnecnncecnes 06388069.4
`Dec. 21; 2006
`Publication Classification
`
`Correspondence Address:
`ERICSSONINC.
`6300 LEGACY DRIVE, M/S EVR 1-C-11
`PLANO, TX 75024 (US)
`
`(21) Appl. No.:
`
`12/281,960
`
`(22)
`
`PCTFiled:
`
`Feb. 19, 2007
`
`(86) PCT No.:
`
`PCT/EP07/01394
`
`§ 371 (¢)(),
`(2), (4) Date:
`
`Jan. 13, 2009
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/743,444, filed on Mar.
`9, 2006.
`
`(51)
`
`Int. Cl.
`(2006.01)
`GO6F 9/445
`(2006.01)
`GO6F 15/177
`(52) US. Cl. POOR ee eee eee ee eee Reet eee EEE EE EEE SEES EEE EEE SEES EE EES 713/2
`(57)
`ABSTRACT
`A method for booting a processing device, the processing
`device comprising a first and a second processing unit, the
`method comprising: detecting by the first processing unit,
`whether at least one boot configuration parameter is acces-
`sible from a non-volatile storage medium of the processing
`device, the at least one configuration parameter being indica-
`tive of a boot interface; if said at least one configuration
`parameter is available, forwarding at least a part of the
`detected at least one configuration parameter by the first
`processing unit to the second processing unit; otherwise
`detecting by at least one of the first and second processing
`units whether a boot interface is available to the processing
`device; booting at least the second processing unit from the
`indicated or detected bootinterface.
`
`174
`
`184 2
`: O 402
`Application
`
`ITCM
`
`DTCM
`
`183
`110
`
`170
`173
`
`163
`
`112
`165
`
`113
`
`/
`
`.
`
`CPU
`
`1014 |
`
`
`
`
`Mem
`con
`a
`
`Con
`
`\_
`199
`1405
`
`150
`
`G Acc
`
`SMem
`Con
`
`V
`/
`
`121
`106
`
`180
`
`INTEL 1219
`
`INTEL 1219
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 1 of 8
`
`US 2009/0307478 Al
`
`
`
`150
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 2 of 8
`
`US 2009/0307478 Al
`
`163
`
`449
`165
`113
`
`Application
`system
`
`GSM/
`
`/
`
`184
`120 102
`
`174
`ITCMfeDTCM|WCDMA||Gace|AceFY
`
`
`
`
`jLOPRSC3|teen|SMem
`
`teen|Can /|
`1wea
`10
`‘aa
`106
`SIM/ Ao
`a
`108
`ter
`182
`\ ass
`
`VICC
`
`161
`
`121
`
`180
`
`250
`
`251
`
`150
`
`299
`[audio
`
`FLASH
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 3 of 8
`
`US 2009/0307478 Al
`
` Application
`
`system
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 4 of 8
`
`US 2009/0307478 Al
`
`340
`
`J
`
`110
`
`1
`|
`Access CPU
`L.
`Za
`402
`
`Hardware
`initialisations
`
`5
`
`403
`
`6a
`
`7a
`
`Detect Service (pin)
`
`i 3
`
`I i
`
`!
`
`i
`!
`
`I1
`
`\
`
`yes Service mode?
`
`9
`
`no
`
`
`
`\
`
`Bridge config
`detected?
`Detect connected
`
`
`external interface
`and switch to
`no
`
`
`
`detected interface
`
`12
`
`Detect connected
`external interface
`and switch to
`detected interface
`
`yes
`
`11
`
`Swilcn io
`bridde
`onite‘oce
`
`44
`
`|
`
`— 18
`
`
`
`17
`xternal CP
`|<connectedto service
`|
`interface?
`
`
`
`
`
`
`
`
`! 20a
`Service mode?
`
`Service mode
`\
`rt
`req.
`start
`req
`
`16
`
`20b
`2 1b
`
`yes (normal mode)! yes (normal mode)
`
`
`
`1
`
`Service mode
`start res.
`
`
`Fig. 4a
`@)
`
`.
`
`erReq from
`ost Timeout?
`
`>
`
`:
`
`22b
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 5 of 8
`
`US 2009/0307478 Al
`
`
`
`(A) 23 7we - ~~ er He er He
`he eeeeae ee ne ee ae eee ere ee te ee ee >
`en.24
`25
`26
`
`27
`
`29
`
`33
`
`36
`
`Flashless
`bridge?
`
`yes
`
`Invoke security
`routines
`
`Read hardware
`security config.
`
`34
`
`
`
`34
`
`:
`Check security
`
`config.
`
`37 \
`
`
`
`Ignore security
`
`config.
`Switch to bridge
`interface
`
`39
`
`“40
`
`Invoke security
`routines
`
`Read hardware
`security config.
`
`35
`
`38
`
`41
`
`42
`
`Check security
`config.
`
`44
`
`45
`
`
`
` Fig. 4b
`
`Continue with boot
`from the detected
`interface
`
`47
`
`46
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 6 of 8
`
`US 2009/0307478 Al
`
`
`
`a1 120~[Application CPU 231 External CPU
`
`
`
`|| !
`
`
`402
`2b
`
`Reset
`
`13
`
`!| ! !
`
`!!| |!
`
`!
`
`!j
`'
`
`Hardware
`Initialisations
`
`4
`
`03
`
`Detect possible
`hardware bridge
`configuration
`
`4
`
`Detect Flash Root table and
`read config parameters
`
`6b
`
`7b
`
`yes
`
`Detect Service (pin)
`
`.
`
`yes
`
`
`Bridge config
`detected?
`
`Configuration
`5
`
`14
`Service mode
`
`|(t
`
`|_|senicemelacei/—|
`
`16
`Zonfiguration ack
`17
`Service mode
`
`20b.
`Service modestart req.
`22d
`Service mode start res.
`
`Fig. 4c
`
`(B)
`
`

`

`Patent Application Publication
`
`Dec. 10,2009 Sheet 7 of 8
`
`US 2009/0307478 Al
`
`Configuration
`__ Gomtousation ae
`24 Configuration ack.
`
`tosase
`
`
`43
`
`
`Read security config.
`
`parameters from non-
`volatile memory
`
`
`
`
`decree 26=Start req.
`
` J-----~-~-—---~----~-~-~-~-~~+--}~~~4--+eeeeaeeeeee
`Result
`
`30
`
`32
`
`Configuration ack./
`Service mode ack.
`
`27
`
`‘Start res.
`
`Invoke security routines
`
`Read Security config. from
`Flash
`
`34 Security config.
`
`37
`
`39 Start req.
`
`40
`
`Start res.
`
`YL 44 Security config.
`
`r— 46
`
`Result
`
`48
`
`Fig. 4d
`
`Continue with boot from the
`
`detected interface or memory
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 8 of 8
`
`US 2009/0307478 Al
`
`
`
`
`110
`
`231
`120
`
`
`4
`
`
`
`PF
`
`T''!''|
`
`22
`
`So 23
`esa
`
`a e
`
`e
`PS
`fA
`
`LN
`
`
`
` benaes
`
`nna
`
`|
`
`30
`
`32
`
`40
`
`27
`
`a 3
`
`31
`
`3
`
`36
`35
`
`
`45
`
`47
`
`8
`
`reneed
`
`
`
`
`
`

`

`US 2009/0307478 Al
`
`Dec. 10, 2009
`
`PLATFORM BOOT WITH BRIDGE SUPPORT
`
`TECHNICAL FIELD
`
`[0001] The invention relates to the booting of processing
`devices comprising a first and a second processing unit.
`
`BACKGROUND
`
`[0002] One example of a processing device comprising a
`first and a second processing unit includes a mobile platform,
`i.e. a chipset/integrated circuit for use in a plurality of differ-
`ent mobile communications devices. A mobile platform can
`be used in several different hardware configurations includ-
`ing e.g. a mobile phone architecture using two central pro-
`cessing units (CPUs). In sucha two-CPU mobile phonearchi-
`tecture typically one of the CPUsis used as an access CPU
`that handles the communication/real-time constrained tasks,
`and the other CPU is used as an application CPU that handles
`the phoneapplication tasks. It is a cost advantage to include
`both the application and the access CPU on the same base-
`band digital application specific integrated circuit (ASIC).
`However, in order to allow the platform to be used together
`with more powerful application systems, it is generally desir-
`able to be able to use the platform together with an external
`CPU andapplication system instead of the application CPU
`of the platform. For example, an electronic device including
`the platform may be connected to another data processing
`system such as a computervia a suitable interface, e.g. via a
`universal serial bus (USB). Such a configuration in which an
`external CPUis used instead ofthe internal application CPU
`of the platform is also called a bridge configuration. In this
`case, there is no direct use of the internal application CPU.
`[0003] According to a first aspect, It is thus desirable to
`provide an initialization or boot process for the processing
`device that facilitates both situations in anefficient and cost-
`effective way.
`[0004] European patent application EP 1 486 869 discloses
`a boot process for initializing a co-processor of a system
`including a main processor and a co-processor. Even though
`this process avoids the need for a NOR flash memory to be
`associated with the coprocessorit still requires two or more
`flash memories connectedto the respective processors.
`[0005] According to another aspect, the booting of a pro-
`cessing device such as amobile platform for normal operation
`typically requiresthat certain basic or platform software, e.g.
`an operating system and/or firmware, and possibly certain
`configuration parameters have beeninstalled on the process-
`ing device, e.g. during manufacturing of the device or a sub-
`sequent configuration. This installation is typically per-
`formed by loading the software onto the processing device,
`e.g. into a non-volatile memory such as a flash memory ofthe
`device. To this end the processing device can typically be
`operated in a special modeof operation, referred to as soft-
`ware flashing modeor service mode, in which the processing
`device is adapted to load software over an external interface
`so that the device can be configured for normal use. The
`process of loading the basic software and configuration
`parameters will also be referred to as external load.
`[0006]
`In some mobile platforms external load is indicated
`by a service pin that is connected to the access CPU. The
`service pin can for example be trigged whentheuser enters a
`specific keyboard combination. Once the service mode is
`detected, the platform loads the software to be executed from
`an external interface, instead from the internal non-volatile
`
`
`
`memory, e.g. flash memory. However, according to the sec-
`ondaspect, itremains a problem to provide a boot process that
`facilitates operation in a service mode irrespective of the
`hardware configuration.
`
`SUMMARY
`
`[0007] Accordingto the first aspect, disclosed is a method
`for booting a processing device, the processing device com-
`prising a first and a second processing unit, the method com-
`prising:
`detecting bythefirst processing unit, whetherat
`[0008]
`least one boot configuration parameter is accessible
`from a non-volatile storage medium of the processing
`device, the at least one configuration parameter being
`indicative of a bootinterface;
`[0009]
`if said at least one configuration parameter is
`available, forwarding at least a part of the detected at
`least one configuration parameterbythefirst processing
`unit to the second processing unit; otherwise detecting
`byat least one ofthe first and second processing units
`whether a boot interface is available to the processing
`device;
`[0010]
`booting at least the second processing unit from
`the indicated or detected boot interface.
`
`[0011] Consequently, the above boot process may be per-
`formed independently ofwhether the processing device boots
`in anormal configuration,i.e. using both its processing units
`or ina bridge configuration in which only oneofthe process-
`ing units is used, thereby providing a general-purposestart-up
`or boot procedure for the multi-processor device.
`[0012]
`In particular, embodiments of the boot process
`described herein do not require the presence of a flash
`memory, and maythus be used in processing devices operated
`in different hardware configurations.
`[0013]
`Furthermore, embodiments of the boot process
`described herein do not require a pure hardware-implicit
`bridge configuration, i.e. an entirely hardware-based detec-
`tion of a bridge configuration based on which interfaces are
`connected, since bridge interfaces such as USB mayalso be
`used also for other non-bridge purposes.
`[0014]
`For a manufacturer of a mobile platform it is an
`interesting advantageto be able to produce a general purpose
`platform including a single boot program that can bootirre-
`spective of the specific hardware and software configuration
`it may be chosen to be operated in. For example, it is an
`advantage of the boot process described herein thatit allows
`provision of a low cost mobile platform for use in smart
`phonesor in modem products such as USBplugsetc., where
`the platform is bootable even without any large non-volatile
`memory like a flash memory.
`[0015] The detected or indicated boot interface may be an
`internal interface, i.e. an interface to another module/unit
`includedin the processing device,or an external interface,i.e.
`an interface for connecting to an external device. Examples of
`an internal interface include an interface to a non-volatile
`
`memory includedin the processing device. Accordingly, the
`external CPU is external to the chip/chipset/integrated circuit
`board of the mobile platform. The external CPU may be a
`CPUin the same processing device, e.g. a CPU on a separate
`integrated circuit board, or it may be a CPU ofa separate
`device different from the processing device that includes the
`mobile platform.
`[0016]
`In one embodiment detecting whether one or more
`boot configuration parameters are accessible from a non-
`
`

`

`US 2009/0307478 Al
`
`Dec. 10, 2009
`
`may be provided that is applicable irrespective of the hard-
`volatile storage medium of the processing device includes
`ware configuration. Hence, the boot processes, even though
`detecting whether the processing device includes a non-vola-
`generic, does not require large amounts of memory in the
`tile memory for storing configuration parameters, andif the
`device, andis cost-effective to maintain andinstall.
`processing device includes a non-volatile memory for storing
`configuration parameters, detecting whether the detected
`[0021] According to the second aspect, disclosed is a
`non-volatile memoryhas stored thereon a data file including
`method for booting a processing device,
`the processing
`the one or more configuration parameters. Examples of con-
`device comprising a first and a second processing unit, the
`figuration parameters may include security parameters such
`processing device being selectably bootable in one of a stand-
`as software version information, a customer ID, platform
`alone configuration and a bridge configuration; wherein, in
`hardware configuration parameters, such as a bridge/non-
`the stand-alone configuration, the first and the second pro-
`bridge flag, a bridge interface identification, and/orthe like.
`cessing units are initialised to be operational, and wherein, in
`the bridge configuration, only the second processing unit is
`[0017]
`Since the boot polling order of the boot procedure
`initialised to be operational andinitialised to be in operational
`initially attempts to find bridge configuration information in
`connection with an external processing unit via a communi-
`the non-volatile platform storage when such memory is avail-
`cations interface; the method comprising:
`able and the platform is suitably customized, the boot proce-
`[0022]
`detecting whether the processing device is to be
`dure described herein works particularly efficiently in con-
`booted in the stand-aloneorin the bridge configuration;
`figurations with non-volatile storage on the mobile platform
`[0023]
`if the processing device is to be booted in the
`system. This is advantageous, since such configurations are
`bridge configuration, receiving a boot mode indication
`typically used for mass market products with stringentstart-
`from the external processing, unit via the communica-
`up performance requirements. Nevertheless, since in the
`tions interface, the boot modeindication being indica-
`absence of stored bridge configuration information, the pro-
`tive of whetherthe processing device is to be booted ina
`cess polls possible external interfaces to detect whether any
`service mode, in which the processing device is config-
`bridge configuration information is available from any of
`ured to load software from the external processing unit
`these interfaces, the boot process can also be performed in
`into a non-volatile memory of the processing device;
`other“flash-less” configurations.
`[0024]
`responsive to the received boot mode indication
`[0018]
`In one embodimentbooting at least the second pro-
`booting the processing device in said service mode.
`cessing unit from the indicated or detected boot interface
`[0025] Hence, it is an advantage of embodiments of the
`includes receiving boot software from the identified or
`boot process described herein that it allows booting a plat-
`detected boot interface, i.e. software for performingat least a
`form device both for normal operation and in a service mode,
`part of the boot process. When receiving the boot software
`irrespective ofwhetherthe device is operated in a stand-alone
`further comprises performing a security check of the boot
`configuration or in a bridge configuration.
`software by at least one of the first and second processing
`units before execution of the received boot software, an
`[0026]
`For example, ina mobile platform USB bridge solu-
`tion, i.e. a mobile platform that uses USB as communications
`increased security is provided against attempts to boot the
`system with unauthorised software or by an unauthorised
`interface between the mobile platform access CPU and an
`
`
`user. For example, the security check may includeaverifica- external CPU system, the boot process described herein
`tion of the authenticity and/or the integrity of the bootsoft-
`allows the external system to indicate whether to boot the
`ware and/or the authenticity and/or authorisation of the pro-
`platform in a service boot mode or a normal boot mode,
`vider ofthe boot software, or the like. The security check may
`without requiring a service pin or other hardware configura-
`include a cryptographic verification process, e.g. a private
`tion, since an USB connection typically would not provide a
`and/or public key based cryptographic verification process.
`connection ofthe service pin to the external system. Embodi-
`ments of the boot process described herein thus provide a
`[0019]
`In one embodiment, performing the security check
`generic boot procedurealso for “flashless” bridge configura-
`is performed by oneof thefirst and second processing units
`tions and configurations without service pin service indica-
`functioning as a security root for software verification during
`tion. Nevertheless embodiments of the process mayfacilitate
`booting. In one embodiment, the method comprises reading,
`that the service mode maybe indicated by a hardware con-
`by the processing unit functioning as a security root security
`figuration such as a by setting a pin connected to one of the
`information, wherein the security information is stored pro-
`CPUsor by a protocol interaction with an external system.
`tected, e.g. cryptographically protected, in anon-volatile stor-
`[0027]
`It
`is a further advantage of the boot process
`age medium of the system. Consequently, the most security
`described herein that it provides a generic boot process that
`sensitive functions are confinedto oneofthe processing units,
`can workefficiently, e.g. without unnecessary start-up delays,
`thereby further reducing the risk of malicious attacks.
`even for non-bridge and/orflash configurations.
`[0020]
`In one embodiment the method comprises perform-
`[0028]
`In one embodiment, the method further comprises
`ing,by thefirst processing unit, a sequence of protocol inter-
`receiving, if the processing device is to be booted in the
`actions of a predetermined boot sequence, where only a sub-
`stand-alone mode, a boot modeindicationvia a user-interface
`set of the protocol
`interactions is conditioned on said
`of the processing device, the boot mode indication being
`detection whether the one or more configuration parameters
`indicative of whether the processing device is to be booted in
`are available. Examples of protocol interactions include the
`the service mode. Consequently, the boot process also allows
`exchange of messages, requests, responses, etc., with the
`for an indication of a service mode by a user via a user
`second processing unit and/or a storage medium and/or exter-
`nal interfaces. In one embodiment the subset includes less
`interface of the device. For example, this indication may be
`providedby a service pin of one of the processing units.
`[0029]
`In some embodiments, the processing device is a
`communications device for providing at least one communi-
`cations service, wherein thefirst processing unit is an appli-
`
`than 5 interactions. Accordingly, when the boot process is
`constructed such that
`in the different configurations the
`respective sequences of interactions only differ from each
`other in one or a few interactions, a compact boot software
`
`

`

`US 2009/0307478 Al
`
`Dec. 10, 2009
`
`cation central processing unit adapted to execute at least one
`application software component for providing functionality
`different from the communications service, and wherein the
`second processing unit is a communications central process-
`ing unit adapted to control the communications service. For
`example, the processing device may be a platform circuit for
`one or more mobile communications products, wherein theat
`least one communications service includes a cellular tele-
`communications service. Nevertheless, it will be appreciated
`that the method mayalso be appliedto other types of process-
`ing devices.
`[0030]
`In one embodiment, each of the first and second
`processing units includes a corresponding read-only-memory
`having stored thereon boot code for controlling at least a part
`of the booting of the corresponding processing unit. Hence,
`the boot procedure is controlled at least in part by ROM-based
`code on both processing units. In addition to the boot code
`stored in the ROM,the boot process is controlled at least in
`part by boot software stored in writable memory ofthe device
`or loaded from an external system via a bridge interface.
`Hence, at least a part of the boot software maybealtered,
`thereby facilitating maintenance of the device.
`[0031] When the method comprises communicating boot
`information betweenthe first and second processing units by
`means of a predetermined boot protocol, an efficient boot
`procedure for a multi-CPU architecture, e.g. a 2-CPU archi-
`tecture is provided.
`[0032]
`Itis noted that the features ofthe methods described
`above andin the following may be implemented in software
`and carried out on a data processing device or other process-
`ing means caused by the execution of program code means
`such as computer-executable instructions. Here and in the
`following, the term processing means comprises any circuit
`and/or device suitably adapted to perform the above func-
`tions. In particular, the above term comprises general- or
`special-purpose programmable microprocessors, Digital Sig-
`nal Processors (DSP), Application Specific Integrated Cir-
`cuits (ASIC), Programmable Logic Arrays (PLA), Field Pro-
`grammable Gate Arrays (FPGA), special purpose electronic
`circuits, etc., or a combination thereof.
`[0033]
`For example,
`the program code means may be
`loaded in a memory, such as a RAM (Random Access
`Memory), from a storage medium, such as a read-only
`memory (ROM)or other non-volatile memory, such as flash
`memory, or from another device via a suitable data interface,
`the described features may be implemented by hardwired
`circuitry instead of software or in combination with software.
`[0034] The present invention relates to different aspects
`including the method described above and in the following,
`corresponding devices, and computer programs, each yield-
`ing one or more of the benefits and advantages described in
`connection with the above-mentioned methods, and each
`having one or more embodiments corresponding to the
`embodiments described in connection with the above-men-
`tioned methods.
`
`In particular, according to one aspect, a processing
`[0035]
`device comprising a first and a second processing unit is
`suitably configured to perform the steps of the method
`described above andin the following.
`[0036]
`For the purpose ofthe present description, the terms
`processing device and electronic device comprise any por-
`table radio communications equipmentand other handheld or
`portable devices and/or components such as integrated circuit
`boards thereof. The term portable radio communications
`
`equipmentincludesall equipment such as mobile telephones,
`pagers, communicators,
`i.e. electronic organisers, smart
`phones, personaldigital assistants (PDAs), handheld comput-
`ers, media players, such as mp3 players, digital cameras or
`other recording devices, embeddeddevices in the automotive
`industry, medical devices, or the like.
`[0037] According to another aspect, a computer program
`product comprises computer-executable instructions adapted
`to cause, when executed on a processing device comprising a
`first and a second processing unit, the processing device to
`perform the method described above andin the following.In
`some embodiments, the computer program product is embod-
`ied as a computer-readable medium, such as a read-only-
`memory or a re-writable non-volatile memory, having stored
`thereon the computer-executable instructions.
`[0038]
`For the purposeof the present description, the terms
`storage means/device and computer-readable medium are
`intended to comprise any suitable storage medium,device or
`circuit, e.g. a read-only-memory (ROM), a random access
`memory (RAM),a flash memory, an Erasable Programmable
`Read-Only Memory (EPROM), volatile or non-volatile
`memory,an optical storage device, a magnetic storage device,
`a diskette, a CD, a hard disk, or the like.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0039] The above and other aspects will be apparent and
`elucidated from the embodiments described in the following
`with reference to the drawing in which:
`[0040]
`FIG. 1 showsa schematic block diagram ofa mobile
`platform including two CPUs.
`[0041]
`FIG. 2 showsa schematic block diagram ofa mobile
`platform including two CPUsin a bridge configuration.
`[0042] FIG.3 showsa schematic block diagram ofa mobile
`platform including two CPUsin a non-bridge configuration.
`[0043]
`FIGS. 4a-e show a flow diagram of an example ofa
`boot process for a mobile platform.
`
`DETAILED DESCRIPTION
`
`FIG. 1 showsa schematic block diagram ofa mobile
`[0044]
`platform system including two CPUs.
`[0045] The mobile platform system, generally designated
`100, includes two subsystems: an access subsystem 101 and
`an application subsystem 102. The access subsystem includes
`an access CPU 110 while the application subsystem 102
`includes an application CPU 120. For example, the mobile
`platform system 100 maybe an integrated circuit/chipset for
`use in a mobile terminal or other communications equipment.
`The 2-CPUarchitecture of the mobile platform system 100
`thus facilitates a functional split between the access sub-
`system and the application subsystem. For example,
`the
`access subsystem 101 may be configured to handle one or
`more standardised communications protocols and/or other
`functionality that require real-time control in which meeting
`deadlines in a timely fashion is important. The application
`subsystem 102 on the other hand may be configured to handle
`end-user functionality and/or other functionality not requir-
`ing real-time control.
`[0046] Various interfaces may be part of the application
`subsystem and the access subsystem,
`respectively. For
`example, the application interface may provide one or more
`interfaces suchas, a display interface 121, a camerainterface
`122, an audio (e.g. microphone and/or loudspeaker) interface
`199, and/or further interfaces (not explicitly shown) suchas a
`
`

`

`US 2009/0307478 Al
`
`Dec. 10, 2009
`
`keyboard interface, a smart card interface, a memory stick
`interface, and/or the like. The application subsystem is further
`shown to include a graphics accelerator 181.
`[0047]
`Similarly, the access subsystem 101 may include
`communicationscircuitry 112, e.g. GSM a GSM/GPRS mod-
`ule 161, a GSM cipher block 162, a GPRS cipher block 163,
`a WCDMA module 164, anda WCDMA cipherblock 165, a
`digital signal processor (DSP) 166, and/orthelike, and pro-
`vide one or more further communications interfaces 182,
`such as an infrared data association (IrDA) interface, an uni-
`versal serial bus (USB) interface, a Bluetooth interface, a
`universal asynchronous receiver/transmitter (UART) inter-
`face, a serial peripheral interface (SPI), an inter-integrated
`circuit interface ([2C), and/or the like. The access subsystem
`further include a One-Time-Programmable memory (OTP)
`167, e.g. for storing a chip-unique identifier and/or other
`parameters. The access subsystem may further provide an
`interface 168 to a Universal Integrated Circuit Card (UICC),
`such as a SIM card, a USIM card,orthe like.
`[0048] The access subsystem may further include security
`modules, such as a platform integrity module 169 for provid-
`ing platform code and data integrity checks, a crypto accel-
`erator block 170 for providing efficient computation of cryp-
`tographic values,
`such as key generation, message
`authentication, etc., a random numbergenerator 171 for use
`in e.g. key generation, and/orthe like.
`[0049] Each of the access subsystem 101 and the applica-
`tion subsystem 102 includes a ROM 103 and 104, respec-
`tively, each including corresponding boot code 105 and 106,
`respectively. The boot codein the respective ROMsis adapted
`to perform atleast an initial part of the boot process, e.g. the
`boot process until the boot software from the internal memory
`or the external system is loaded. Furthermore, the boot code
`stored in ROM 103 of the access subsystem 101 provides the
`platform security root functionality. Ina mobile terminal with
`an access subsystem and an application subsystem where the
`application subsystem maybe disabled when configured in a
`bridge configuration,it is an advantage that the access sub-
`system functions as a security root, since the access sub-
`system is always available regardless of the chosen configu-
`ration.
`
`[0050] Each of the access subsystem 101 and the applica-
`tion subsystem 102 further includes Instruction and Data
`Tightly Coupled Memories (ITCM/DTCM) 173 and 174,
`respectively. The ITCM is on-chip memory into which an
`initial part ofthe boot codeis loaded. Furthermore, each ofthe
`access subsystem 101 and the application subsystem 102 is
`shown with a service pin 183 and 184, respectively. In each
`subsystem, the respective componentsare interconnected via
`at least one suitable bus 185 and 186, respectively,e.g. a high
`speed bus or a high speed bus and a peripheral bus, and/or the
`like. The access subsystem and the application subsystem
`communicate with each other via a suitable interface 113,
`such as a communications interface between the access and
`application CPU,e.g. a serial link, one or more shared memo-
`ries, and/orthe like.
`[0051] The mobile platform system 100 mayinclude one or
`more memory controllers for controlling access to one or
`more internal memories. In the example of FIG. 1, the mobile
`platform includes a memory controller 105 for controlling a
`common random access memory (RAM) 150 shared by the
`access and application subsystems. Hence, the memory con-
`troller 105 functions as memory arbiter which is configured
`by the access subsystem. For example, the memory controller
`
`may be configured such that respective memory regions are
`access-protected from the application system,1.e. the control-
`ler can prevent access from the application system to certain
`memory regions that belong to the access system. Alterna-
`tively or additionally, the platform system may include sepa-
`rate RAMs for the respective subsystems. Similarly,
`the
`mobile platform includesa static memory controller 106 for
`controlling one or more non-volatile memories, e.g. a flash
`memory such as NAND flash memory and/or a NOR flash
`memory, and a corresponding static memory controller 106,
`in FIG. 1 shown connected to the application subsystem. For
`example, during operation ofthe mobile platform system ina
`stand-alone configuration, software for the access subsystem
`101 and the application subsystem 102 may be loaded froma
`flash memory connected to static memory controller 106 to
`the RAM 150. For the purpose of the present description,it
`will be assumed that the memory/memories is/are accessed
`from the application CPU. However, as will be discussed
`below,the boot procedure described herein is also applicable
`for a mobile platform system that does not include non-
`volatile memory. The application subsystem of FIG. 1 is
`further shown to include a further memory controller 180.
`[0052] The access subsystem and the application sub-
`system may be implemented on the samechip or as separate
`chip sets interconnected via a suitable interface. While the
`access and application CPUs are always present, in some
`configurations a further, external CPU may be connected to
`the system as described herein. It will further be understood
`that alternative implementations of a mobile platform system
`may include additional and/or alternative components.
`Examples of such mobile platform systems are disclosed in
`international patent application WO 2005/041601.
`[0053] As will be describedin greater detail below, the boot
`code is either loaded from an external interface, i.e. in the
`bridge or service modecase, or from flash memory included
`in the platform system, e.g. flash memory attached to e.g.
`interface 106 or 180 in FIG.1. Irrespectively of whether the
`boot code is loaded from an external or an internal interface,
`the initial boot codeto be loadedis stored on the ITCMsofthe
`respective CPUs.
`[0054]
`FIG. 2 shows a schematic block diagram of the
`mobile platform 100 described in connection with FIG. 1 ina
`bridge configuration. The mobile platform system 100 is
`shown connected to an external system 230, including an
`external CPU 231, via one of the interfaces 182 of theplat-
`form system, e.g. via a USB interface. The external system
`230 in FIG.2 is further shown