(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2009/0307478 A1
`
`
` 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) .................................. 063880694
`Dec. 21, 2006
`Publication Classification
`
`Correspondence Address:
`ERICSSON INC.
`6300 LEGACY DRIVE, M/S EVR 1-C-11
`PLANO, TX 75024 (Us)
`
`(21) APP1~ N05
`
`12/2813960
`
`(22) PCT Filed:
`
`Feb. 19, 2007
`
`(86) PCT N05
`
`PCT/EP07/01394
`
`§371 (00):
`(2): (4) Date:
`
`Jan. 13, 2009
`
`Related US. Application Data
`
`(60) Provisional application No. 60/743,444, filed on Mar.
`9, 2006.
`
`(51)
`
`Int. Cl-
`(2006.01)
`G06F 9/445
`(200601)
`G061” 15/177
`(52) U-S- Cl: ............................................................ 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 boot interface.
`
`1 83.
`
`1 63
`
`170
`173
`
`101
`
`165
`113
`
`.
`
`120
`
`102
`174
`
`
`
`2
`
`_ ‘
`
`‘
`
`,
`GAcc
`
`m
`
`GPR
`
`03
`
`Me
`°°
`
`Mem
`
`SMem
`
`V
`
`1
`
`Access system .I /
`1
`
`-|TCM
`c1
`.ITCM
`
`
`——-——-—
`'
`162
`
`m
`
`SW"
`UICC
`
`168
`
`16
`
`4
`
`167
`
`-
`
`161
`
`182
`
`1 21
`
`106
`
`180
`
`199
`
`105
`
`150
`
`INTEL 1219
`
`INTEL 1219
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 1 0f 8
`
`US 2009/0307478 A1
`
`163
`110
`170
`173
`
`101
`
`163
`112
`165
`113
`
`184
`120
`
`102
`174
`
`Application
`
`ITCM
`
`103
`
`
`
` ———-
`
`.
`
`-1
`"“6 m
`
`SIM/
`anc
`
`OTP
`
`168
`
`64
`
`1 167
`
`" ‘
`I
`
`DSP
`
`Mem
`con
`
`-
`
`Mem
`
`L
`
`199
`105
`
`150
`
`‘
`
`C3
`
`162
`
`1_g
`
`161
`182
`
`Fig. 1
`
`Access system .I /
`1
`CPU‘ DTCM
`-
`
`61
`
`CPU
`
`ITCM
`
`DTCM
`
`
`,
`'
`
`
`»
`
`SMem
`
`1
`
`2‘
`106
`
`.
`180
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 2 0f 8
`
`US 2009/0307478 A1
`
`174
`;:"I am
`
`
`
`I
`
`163
`112
`165
`113
`
`184
`120102
`
`Application
`
`ITC M
`
`GAcc '7
`'
`
`.
`
`Access system.1.l
`
`-
`
`DMA
`
`GSM/
`
`-lon Mem SMem
`_G-PRS—C3
`Con Con
`—-1_62
`100L199 .
`—
`182
`
`UICC
`
`SIMI -:
`6167
`
`161
`
`121
`
`180
`
`106
`
`105
`
`150
`
`299
`[Xudio
`
`\—23O
`
`250
`
`251
`
`FLASH
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 3 0f 8
`
`US 2009/0307478 A1
`
`
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 4 0f 8
`
`US 2009/0307478 A1
`
`1
`
`l 5
`
`[EE:]\+\—340
`
`110 «/l
`
`Access CPU
`
`
`] A/f‘l
`28
`402
`
`Hardware
`initialisations
`
`7
`
`5
`
`403
`
`Ga
`
`7a
`
`Detect Service (pin)
`
`yes Service mode?
`
`
`
`9
`
`no
`
`= ridge confi-
`detected?
`
`yes
`
`1 1
`
`Switch to
`_
`..
`bndge
`interface
`
`
`
`14
`
`Detect connected
`external Interface
`
`
`.
`and swrtch to
`“0
`
`detected interface
`12
`
`Detect connected
`
`external interface
`and switch to
`
`detected interface
`
`
`
`/—- 18
`
`
`xternal CP
`
`
`
`
`
`17
`
`:
`i
`
`l l
`
`i
`
`1
`
`5 i
`
`|l E
`
`l E
`
`5
`
`E
`;
`1
`.
`;
`f
`
`i
`2
`}
`i
`
`.:
`
`I i i
`
`
`
`1 6
`
`20b
`
`21 b
`
`>
`
`20a
`Service mode
`
`Service mode?
`
`
`
`. start req.
`21 a
`
`yes (normal mode) yes (normal mode)
`
`
`erReq from
`erReq from
`
`
`ost Timeout?
`ost Timeout?
`
`
`
`
`.
`I
`Fig. 452
`®
`
`|
`:22b
`
`Service mode
`start res.
`
`§
`
`'
`
`22b
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 5 0f 8
`
`US 2009/0307478 A1
`
`0 23 —\
`—————————————————————————————————————————————————————— ‘>
`_____________24K_
`25
`26
`
`27
`
`29
`
`33
`
`36
`
`Flashless
`
`yes
`
`bndge?
`
`Invoke security
`routines
`
`Read hardware
`
`security config.
`
`34
`
`Check security
`config.
`
`37\
`
`
`
`34
`
`Ignore security
`config.
`
`Switch to bridge
`interface
`
`35
`
`38
`
`V
`
`39
`
`40
`
`Invoke security
`routines
`
`41
`
`Read hardware
`
`security config.
`
`42
`
`Check security
`confi-.
`
`44
`
`45
`
`46/
`
`Continue with boot
`
`
`from the detected
`interface
` Fig. 4b
`
`47
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 6 0f 8
`
`US 2009/0307478 A1
`
`External CPU
`
`1
`
`231
`
`II II
`
`2b
`
`: 1
`
`Reset
`
`120
`
`Application CPU
`
`402
`
`4
`
`03
`
`Hardware
`Initiaiisations
`
`13
`
`Detect service
`
`II
`
`I II |
`
`I III| II
`
`5 iI I I I III
`
`III
`
`Configuration
`5
`
`Detect possible
`hardware bridge
`configuration
`
`4
`
`Detect Flash Root table and
`
`read config parameters
`
`6b
`
`7b
`
`yes
`
`Detect Service (pin)
`
`,
`
`
`
`yes
`
`
`
`'ridge con Io
`detected?
`
`
`14
`Service mode
`
`.
`1.6
`I onfiguratlon ack
`17
`Service mode
`
`20b
`Service mode start req.
`22b
`Service mode start res.
`
`lb
`
`Fig. 4c
`
`9
`
`0
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 7 0f 8
`
`US 2009/0307478 A1
`
`23 Configuration
`
`.3
`
`E
`“ ‘gg'Eaafigfiré‘tidfih‘c'iii """"""""" fl""""""""""
`Service mode ack.
`
` [— 24 Configuration ack
`
`
` _____1_______-___.______.____.____-———.__.....—__-_--—___.__-_____-______---_______.--______._.____
`Result
`
`43
`
`Read security config.
`
`parameters from non-
`volatile memory
`
`
`
`
`26
`
`Start req.
`
`27
`
`Start res.
`
`Invoke security routines
`
`30
`
`32
`
`Read Security config. from
`Flash
`
`34 Security config.
`
`37
`
`39 Start req.
`
`40
`
`Start res.
`
`/— 44 Security config.
`/—' 46
`Result
`
`
`43
`
`Fig. 4d
`
`Continue with boot from the
`
`detected interface or memory
`
`
`
`
`i
`
`

`

`Patent Application Publication
`
`Dec. 10, 2009 Sheet 8 of 8
`
`US 2009/0307478 A1
`
`.
`
`......
`
`120
`23 1
`
`
`1
`
`
`
`-I-
`
`
`
`lIIllll
`
`____..-.1,-_-_- __
`/: 23
`
`1::::::::i::::::f:
`
`
`
`ES
`
`
`
`
`X 2
`
`6
`
`.—
`
`31
`
`33
`
`
`
`
`
`27
`
`’
`
`30
`
`32
`
`36
`35
`
`
`D!
`39
`
`40
`
`44
`
`47
`
`46
`
`48
`
`

`

`US 2009/0307478 A1
`
`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 such a two-CPU mobile phone archi-
`tecture typically one of the CPUs is 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 phone application 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 and application 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 computer via a suitable interface, e.g. via a
`universal serial bus (USB). Such a configuration in which an
`external CPU is used instead of the 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 ii an eflicient and cost-
`
`
`
`effective way.
`[0004] European patent application 3P 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 coprocessor it still requires two or more
`flash memories connected to the respective processors.
`[0005] According to another aspect, the booting of a pro-
`cessing device such as a mobile platform for normal operation
`typically requires that certain basic or platform software, e.g.
`an operating system and/or firmware, and possibly certain
`configuration parameters have been installed 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 of the
`device. To this end the processing device can typically be
`operated in a special mode of operation, referred to as soft-
`ware flashing mode or 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 when the user 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-
`ond aspect, it remains a problem to provide a boot process that
`facilitates operation in a service mode irrespective of the
`hardware configuration.
`
`SUMMARY
`
`[0007] According to 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 by the first processing unit, whether at
`[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 boot interface;
`[0009]
`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;
`[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 a normal configuration, i.e. using both its processing units
`or in a bridge configuration in which only one of the process-
`ing units is used, thereby providing a general-purpose start-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 may thus 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 may also be
`used also for other non-bridge purposes.
`[0014]
`For a manufacturer of a mobile platform it is an
`interesting advantage to be able to produce a general purpose
`platform including a single boot program that can boot irre-
`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 that it allows
`provision of a low cost mobile platform for use in smart
`phones or in modem products such as USB plugs etc., 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
`included in 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 included in 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
`CPU in the same processing device, e.g. a CPU on a separate
`integrated circuit board, or it may be a CPU of a 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 A1
`
`Dec. 10, 2009
`
`volatile storage medium of the processing device includes
`detecting whether the processing device includes a non-vola-
`tile memory for storing configuration parameters, and if the
`processing device includes a non-volatile memory for storing
`configuration parameters, detecting whether the detected
`non-volatile memory has stored thereon a data file including
`the one or more configuration parameters. Examples of con-
`figuration parameters may include security parameters such
`as software version information, a customer ID, platform
`hardware configuration parameters, such as a bridge/non-
`bridge flag, a bridge interface identification, and/or the like.
`[0017]
`Since the boot polling order of the boot procedure
`initially attempts to find bridge configuration information in
`the non-volatile platform storage when such memory is avail-
`able and the platform is suitably customized, the boot proce-
`dure described herein works particularly efficiently in con-
`figurations with non-volatile storage on the mobile platform
`system. This is advantageous, since such configurations are
`typically used for mass market products with stringent start-
`up performance requirements. Nevertheless, since in the
`absence of stored bridge configuration information, the pro-
`cess polls possible external interfaces to detect whether any
`bridge configuration information is available from any of
`these interfaces, the boot process can also be performed in
`other “flash-less” configurations.
`[0018]
`In one embodiment booting at least the second pro-
`cessing unit from the indicated or detected boot interface
`includes receiving boot software from the identified or
`detected boot interface, i.e. software for performing at least a
`part of the boot process. When receiving the boot software
`further comprises performing a security check of the boot
`software by at least one of the first and second processing
`units before execution of the received boot software, an
`increased security is provided against attempts to boot the
`system with unauthorised software or by an unauthorised
`user. For example, the security check may include a verifica-
`tion of the authenticity and/or the integrity of the boot soft-
`ware and/or the authenticity and/or authorisation of the pro-
`vider ofthe boot software, or the like. The security check may
`include a cryptographic verification process, e.g. a private
`and/or public key based cryptographic verification process.
`[0019]
`In one embodiment, performing the security check
`is performed by one of the first and second processing units
`functioning as a security root for software verification during
`booting. In one embodiment, the method comprises reading,
`by the processing unit functioning as a security root security
`information, wherein the security information is stored pro-
`tected, e.g. cryptographically protected, in a non-volatile stor-
`age medium of the system. Consequently, the most security
`sensitive functions are confined to one ofthe processing units,
`thereby further reducing the risk of malicious attacks.
`[0020]
`In one embodiment the method comprises perform-
`ing, by the first processing unit, a sequence of protocol inter-
`actions of a predetermined boot sequence, where only a sub-
`set of the protocol
`interactions is conditioned on said
`detection whether the one or more configuration parameters
`are available. Examples of protocol interactions include the
`exchange of messages, requests, responses, etc., with the
`second processing unit and/or a storage medium and/or exter-
`nal interfaces. In one embodiment the subset includes less
`
`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
`
`may be provided that is applicable irrespective of the hard-
`ware configuration. Hence, the boot processes, even though
`generic, does not require large amounts of memory in the
`device, and is cost-effective to maintain and install.
`[0021] According to the second aspect, disclosed is a
`method for booting a processing device,
`the processing
`device comprising a first and a second processing unit, the
`processing device being selectably bootable in one of a stand-
`alone configuration and a bridge configuration; wherein, in
`the stand-alone configuration, the first and the second pro-
`cessing units are initialised to be operational, and wherein, in
`the bridge configuration, only the second processing unit is
`initialised to be operational and initialised to be in operational
`connection with an external processing unit via a communi-
`cations interface; the method comprising:
`[0022]
`detecting whether the processing device is to be
`booted in the stand-alone or in the bridge configuration;
`[0023]
`if the processing device is to be booted in the
`bridge configuration, receiving a boot mode indication
`from the external processing unit via the communica-
`tions interface, the boot mode indication being indica-
`tive of whether the processing device is to be booted in a
`service mode, in which the processing device is config-
`ured to load software from the external processing unit
`into a non-volatile memory of the processing device;
`[0024]
`responsive to the received boot mode indication
`booting the processing device in said service mode.
`[0025] Hence, it is an advantage of embodiments of the
`boot process described herein that it allows booting a plat-
`form device both for normal operation and in a service mode,
`irrespective ofwhether the device is operated in a stand-alone
`configuration or in a bridge configuration.
`[0026]
`For example, in a mobile platform USB bridge solu-
`tion, i.e. a mobile platform that uses USB as communications
`interface between the mobile platform access CPU and an
`external CPU system,
`the boot process described herein
`allows the external system to indicate whether to boot the
`platform in a service boot mode or a normal boot mode,
`without requiring a service pin or other hardware configura-
`tion, since an USB connection typically would not provide a
`connection of the service pin to the external system. Embodi-
`ments of the boot process described herein thus provide a
`generic boot procedure also for “flashless” bridge configura-
`tions and configurations without service pin service indica-
`tion. Nevertheless embodiments of the process may facilitate
`that the service mode may be indicated by a hardware con-
`figuration such as a by setting a pin connected to one of the
`CPUs or by a protocol interaction with an external system.
`[0027]
`It
`is a further advantage of the boot process
`described herein that it provides a generic boot process that
`can work efficiently, e. g. without unnecessary start-up delays,
`even for non-bridge and/or flash configurations.
`[0028]
`In one embodiment, the method further comprises
`receiving, if the processing device is to be booted in the
`stand-alone mode, a boot mode indication via a user-interface
`of the processing device, the boot mode indication being
`indicative of whether the processing device is to be booted in
`the service mode. Consequently, the boot process also allows
`for an indication of a service mode by a user via a user
`interface of the device. For example, this indication may be
`provided by 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 commum-
`cations service, wherein the first processing unit is an appli-
`
`

`

`US 2009/0307478 A1
`
`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 the at
`least one communications service includes a cellular tele-
`
`communications service. Nevertheless, it will be appreciated
`that the method may also be applied to other types of process-
`ing devices.
`[003 0]
`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 may be altered,
`thereby facilitating maintenance of the device.
`[0031] When the method comprises communicating boot
`information between the 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]
`It is noted that the features ofthe methods described
`above and in 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 and in the following.
`[0036]
`For the purpose ofthe present description, the terms
`processing device and electronic device comprise any por-
`table radio communications equipment and other handheld or
`portable devices and/or components such as integrated circuit
`boards thereof. The term portable radio communications
`
`equipment includes all equipment such as mobile telephones,
`pagers, communicators,
`i.e. electronic organisers, smart
`phones, personal digital assistants (PDAs), handheld comput-
`ers, media players, such as mp3 players, digital cameras or
`other recording devices, embedded devices 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 and in 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 purpose of 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 shows a schematic block diagram ofa mobile
`platform including two CPUs.
`[0041]
`FIG. 2 shows a schematic block diagram ofa mobile
`platform including two CPUs in a bridge configuration.
`[0042]
`FIG. 3 shows a schematic block diagram ofa mobile
`platform including two CPUs in a non-bridge configuration.
`[0043]
`FIGS. 4a-e show a flow diagram ofan example ofa
`boot process for a mobile platform.
`
`DETAILED DESCRIPTION
`
`FIG. 1 shows a 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 may be an integrated circuit/chipset for
`use in a mobile terminal or other communications equipment.
`The 2-CPU architecture 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 such as, a display interface 121, a camera interface
`122, an audio (e. g. microphone and/or loudspeaker) interface
`199, and/or further interfaces (not explicitly shown) such as a
`
`

`

`US 2009/0307478 A1
`
`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
`communications circuitry 112, e.g. GSM a GSM/GPRS mod-
`ule 161, a GSM cipher block 162, a GPRS cipher block 163,
`a WCDMA module 164, and a WCDMA cipher block 165, a
`digital signal processor (DSP) 166, and/or the like, 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 (IZC), 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, or the 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 eflicient computation of cryp-
`tographic values,
`such as key generation, message
`authentication, etc., a random number generator 171 for use
`in e.g. key generation, and/or the 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 code in the respective ROMs is adapted
`to perform at least 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. In a mobile terminal with
`an access subsystem and an application subsystem where the
`application subsystem may be 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 code is 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 components are 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/or the like.
`[0051] The mobile platform system 100 may include 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, i.e. the control-
`ler can prevent access from the application system to certain
`memory regions that belong to the access system. Altema-
`tively or additionally, the platform system may include sepa-
`rate RAMs for the respective subsystems. Similarly,
`the
`mobile platform includes a 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 in a
`stand-alone configuration, software for the access subsystem
`101 and the application subsystem 102 may be loaded from a
`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 same chip 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 described in greater detail below, the boot
`code is either loaded from an external interface, i.e. in the
`br