Progressive boot for a wireless device

Techniques for performing progressive boot to reduce perceived boot time for a wireless device are described. Program codes to be stored in a bulk non-volatile memory may be partitioned into multiple code images. A first code image may include program codes used to support basic functionality of the wireless device. A second code image may include the remaining program codes. For progressive boot, the first code image may be loaded first from the bulk non-volatile memory. Once the first code image has been loaded, the wireless device may be rendered operational and may appear as functional to a user. While the wireless device is operational, the second code image may be loaded from the bulk non-volatile memory as background task and/or on-demand as needed.

BACKGROUND

The present disclosure relates generally to electronics, and more specifically to techniques for booting a wireless device at power up.

A wireless device (e.g., a cellular phone) typically operates based on program codes that control the hardware within the wireless device and support various designed functions. The program codes may be stored in a bulk non-volatile memory and may be loaded into a faster volatile memory at power up. The bulk non-volatile memory may be a NAND Flash that can economically store a large amount of data but can only be accessed one page at a time. A page may be the smallest unit of data that can be retrieved from the NAND Flash and may be four kilobytes (KB) or some other size. The faster volatile memory may be a synchronous dynamic random access memory (SDRAM) that can support random access. The memories may be selected to provide the desired storage capacity and access capability and to be as economical as possible.

When the wireless device is powered up, all of the program codes may be loaded from the bulk non-volatile memory into the faster volatile memory. Once all of the program codes have been loaded, the wireless device may be enabled to accept user inputs and perform user selected functions. The amount of program codes to load at power up may be large, and the boot time may be relatively long. Hence, the user may need to wait an extended period of time before the wireless device is operational.

SUMMARY

In one aspect, an apparatus includes a processor configured to program first and second code images into a memory device used for a wireless device, the first code image being loaded from the memory device to boot the wireless device and render the wireless device operational, the second code image being loaded from the memory device while the wireless device is operational to further boot the wireless device.

In another aspect, a method includes programming a first code image into a memory device used for a wireless device, the first code image being loaded from the memory device to boot the wireless device and render the wireless device operational. The method further includes programming a second code image into the memory device, the second code image being loaded from the memory device while the wireless device is operational to further boot the wireless device.

In another aspect, an apparatus includes means for programming a first code image into a memory device used for a wireless device, the first code image being loaded from the memory device to boot the wireless device and render the wireless device operational and means for programming a second code image into the memory device, the second code image being loaded from the memory device while the wireless device is operational to further boot the wireless device.

In another aspect, an apparatus includes a memory controller configured to load a first code image from an external memory to boot a wireless device and a main controller configured to render the wireless device operational after loading the first code image, and wherein the memory controller is further configured to load a second code image from the external memory while the wireless device is operational to further boot the wireless device.

In another aspect, a method includes loading a first code image from an external memory to boot a wireless device, rendering the wireless device operational after loading the first code image, and loading a second code image from the external memory while the wireless device is operational to further boot the wireless device.

In another aspect, an apparatus includes means for loading a first code image from an external memory to boot a wireless device, means for rendering the wireless device operational after loading the first code image, and means for loading a second code image from the external memory while the wireless device is operational to further boot the wireless device.

In another aspect, a computer program product includes a computer-readable medium comprising code for causing a computer to load a first code image from an external memory to boot a wireless device, code for causing a computer to render the wireless device operational after loading the first code image, and code for causing a computer to load a second code image from the external memory while the wireless device is operational to further boot the wireless device.

In another aspect, an apparatus includes a memory controller configured to retrieve a plurality of pages of a code image from an external memory, the plurality of pages being associated with separate security information, and to authenticate each page retrieved from the external memory based on security information for the page.

In another aspect, a method includes retrieving a plurality of pages of a code image from an external memory, the plurality of pages being associated with separate security information, and authenticating each page retrieved from the external memory based on security information for the page.

In another aspect, an apparatus includes means for retrieving a plurality of pages of a code image from an external memory, the plurality of pages being associated with separate security information and means for authenticating each page retrieved from the external memory based on security information for the page.

DETAILED DESCRIPTION

The boot techniques described herein may be used for various electronics devices such as wireless communication devices, handheld devices, game devices, computing devices, consumer electronics devices, computers, etc. For clarity, the techniques are described below for a wireless communication device having a memory such as a NAND Flash memory and an SDRAM.

FIG. 1shows a block diagram of a wireless communication device100in accordance with an aspect of the invention, which may be a cellular phone, a personal digital assistant (PDA), a handset, a handheld device, a wireless module, a terminal, a modem, etc. Wireless device100may be capable of providing bi-directional communication with one or more wireless communication systems via a transmit path and a receive path. On the transmit path, a digital section120may provide data to be transmitted by wireless device100. A transmitter (TMTR)114may process the data to generate a radio frequency (RF) output signal, which may be transmitted via an antenna112to base stations. On the receive path, signals transmitted by the base stations may be received by antenna112and provided to a receiver (RCVR)116. Receiver116may condition and digitize the received signal and provide samples to digital section120for further processing.

Digital section120may include various processing, interface, and memory units that support digital processing for wireless device100. In the design shown inFIG. 1, digital section120includes a modem processor122, a central processing unit (CPU)/reduced instruction set computer (RISC)124, a main controller130, a static RAM (SRAM)132, a read-only memory (ROM)134, a NAND Flash controller140, and an SDRAM controller142, all of which may communicate with one another via one or more buses160. Modem processor122may perform processing for data transmission and reception, e.g., encoding, modulation, demodulation, decoding, etc. CPU/RISC124may perform general-purpose processing for wireless device100, e.g., processing for audio, video, graphics, and/or other applications. Main controller130may direct the operation of various units within digital section120. SRAM132may store program codes and data used by the controllers and processors within digital section120. ROM134may store a boot code136and a root public key138. Boot code136may perform an initial part of power-up boot and may start loading program codes from a NAND Flash150when wireless device100is powered up. Root public key138may be used for security functions, e.g., to authenticate the program codes loaded from NAND Flash150.

NAND Flash controller140may facilitate transfer of data between NAND Flash150and digital section120. SDRAM controller142may facilitate transfer of data between an SDRAM152and digital section120. Main controller130may direct the operation of NAND Flash controller140and/or SDRAM controller142. For example, main controller130may direct loading of program codes from NAND Flash150to SDRAM152during boot up, e.g., when wireless device100is powered on.

NAND Flash150and SDRAM152may provide mass storage for the processing units within digital section120. NAND Flash150may provide non-volatile storage for program codes and data used by digital section120. NAND Flash150may also be replaced with other types of non-volatile memory, e.g., a NOR Flash. SDRAM152may provide storage with random access capability for program codes and data used by digital section120. SDRAM152may also be replaced with other types of volatile memory, e.g., an SRAM, a DRAM, etc.

In general, digital section120may include any number of processing, interface, and memory units. Digital section120may also be implemented with one or more digital signal processors (DSPs), micro-processors, RISC processors, etc. Digital section120may be fabricated on one or more application specific integrated circuits (ASICs) and/or some other type of integrated circuits (ICs).

As shown inFIG. 1, wireless device100may utilize a memory architecture with different types of memory. SDRAM152is a volatile memory that lose its data once power is removed. SDRAM152may be accessed in a random manner and is commonly used as the main run-time memory. NAND Flash150is a non-volatile memory that can retain its data even after power is removed. NAND Flash150has large storage capacity, good speed for continued memory access, and low cost. However, NAND Flash150has poor performance for random memory access and is typically accessed in units of pages, one page at a time, with each page being of a particular size (e.g., 4 KB).

The memory architecture inFIG. 1incorporates both NAND Flash150and SDRAM152and is capable of providing large storage capacity with random access at reduced cost. For this memory architecture, program codes may be permanently stored in NAND Flash150. The program codes may control the hardware within wireless device100as well as support various designed functions and features. Upon power up, wireless device100may perform a boot that may entail transferring the program codes from NAND Flash150to SDRAM152. NAND Flash150may store a large amount of program codes. Hence, the amount of time to load all of the program codes from NAND Flash150to SDRAM152at power up may be relatively long.

In an aspect, the program codes to be stored in NAND Flash150may be partitioned into multiple code images that may be stored in different segments of NAND Flash150. A segment may also be referred to as a partition, a section, etc. In one design, the program codes may be partitioned into first and second code images. The first code image may include program codes used to support basic functionality of wireless device100and may be stored in a non-paged segment of NAND Flash150. The second code image may include the remaining program codes and may be stored in a paged segment of NAND Flash150. For progressive boot at power up, the first code image may be loaded first from the non-paged segment of NAND Flash150into SDRAM152. Once the first code image has been loaded, wireless device100may be enabled and may appear as functional to a user. While wireless device100is operational, the second code image may be loaded from the paged segment of NAND Flash150into SDRAM152, e.g., as background task and/or on-demand as needed. The progressive boot may shorten the amount of time to enable wireless device100at power up, which may improve user experience and provide other benefits.

The program codes stored in NAND Flash150may include codes that control the operation of wireless device100, higher layer applications that support various designed features and functions, factory test codes, and/or other types of codes. It may be desirable or necessary to ascertain whether or not the program codes stored in NAND Flash150are authorized for use, to allow execution of program codes that are authorized, and to prevent execution of program codes that are unauthorized. Furthermore, it may be desirable to provide security in an efficient manner for the multiple code images used for progressive boot.

In another aspect, security may be efficiently provided for progressive boot by performing authentication for the entire first code image and also for each page of the second code image. The first code image may be loaded first from NAND Flash150in its entirely at power up and may be authenticated when loaded. The second code image may be partitioned into pages and loaded one page at a time from NAND Flash150. The pages of the second code image may be loaded in different orders depending on memory accesses. Each page of the second code image may be authenticated individually to allow the page to be loaded and used without regards to the other pages of the second code image.

FIG. 2shows a design of NAND Flash150, which includes a non-paged segment210and a paged segment220, in accordance with an aspect of the invention. In this design, non-paged segment210stores a first code image212, a hash digest table214, a certificate216, and a digital signature218. Certificate216may include cryptographic information used to authenticate non-paged segment210and paged segment220. Digital signature218may be generated over both first code image212and hash table214and may be used to authenticate these two parts. First code image212may include program codes and/or data to be loaded from NAND Flash150prior to enabling wireless device100, e.g., codes for drivers, user interface (UI), modem, etc. Table214may include cryptographic hash digests for individual pages of a second code image222. Second code image222may include program codes and/or data to be loaded from NAND Flash150after enabling wireless device100, e.g., codes for higher layer applications. In general, a code image may include program codes, data, etc.

FIG. 2also shows a design of a process200to program non-paged segment210and paged segment220of NAND Flash150. Process200may be performed during manufacturing of NAND Flash150, provisioning of wireless device100, etc. The design inFIG. 2uses two sets of cryptographic keys: (1) a set of private and public keys to sign and authenticate non-paged segment210, which are referred to as private key x and public key x, and (2) a set of private and public keys to authenticate a source entity, which are referred to as root private key r and root public key r. Root private key r and private key x are secret and only known to the source entity, which may be a source code vendor, a manufacturer, etc. Root public key r is made available to wireless device100and is used to verify digital signatures generated with root private key r. Public key x is used to verify digital signatures generated with private key x and may be sent in certificate216.

A sign function232may generate a digital signature over public key x and possibly other information using root private key r. This digital signature may be referred to as signature cx and may be used to authenticate the source entity. Sign function232may implement an RSA (Rivest, Shamir and Adleman) algorithm, a Digital Signature Algorithm (DSA), or some other cryptographic (digital signature or encryption) algorithm. A certificate generator234may form a certificate containing signature cx, public key x, and possibly other information such as an identifier of the source entity, the cryptographic algorithm selected for use, the expiration date of the certificate, etc. This certificate may be stored in NAND Flash150as an X.509 certificate or in some other format known in the art. Root public key r may be made available to wireless device100in any manner and may be securely stored in ROM134within wireless device100inFIG. 1.

In the design shown inFIG. 2, second code image222may be processed and stored first, and first code image212may be processed and stored next. A page partition unit252may receive and partition second code image222into pages of a particular size (e.g., 4 KB) and may provide one page at a time to a secure hash function254and also to NAND Flash150. Function254may hash each page from unit252with a secure hash algorithm and provide a hash digest for that page. Function254may implement SHA-1 (Secure Hash Algorithm), SHA-2 (which includes SHA-224, SHA-256, SHA-384 and SHA-512), MD-4 (Message Digest), MD-5, or some other secure hash algorithm known in the art. A secure hash algorithm has cryptographic properties so that the function between an input message and its digest (which is a pseudo-random bit string) is irreversible and the likelihood of two input messages mapping to the same digest is very small. A secure hash algorithm may receive an input message of any length and may provide a hash digest of a fixed length. A table generator256may generate a table of hash digests for all pages of second code image222and may store this table as hash digest table214in NAND Flash150.

First code image212may be provided to a multiplexer (Mux)242and also stored in NAND Flash150. Multiplexer242may also receive hash digest table214from generator256and may sequentially provide first code image212and hash digest table214to a secure hash function244. Function244may hash both first code image212and hash digest table214with a secure hash algorithm and may provide a hash digest, which may be called digest x. Function244may implement SHA-1, SHA-2, MD-5, or some other secure hash algorithm. A sign function246may generate a digital signature over digest x using private key x. This digital signature may be stored as digital signature218in NAND Flash150. Sign function246may implement the RSA, DSA, or some other cryptographic algorithm. Sign functions232and246may implement the same or different cryptographic algorithms.

FIG. 3shows a design of second code image222and hash digest table214in NAND Flash150. In this design, second code image222may be partitioned into N pages 0 through N−1, where N may be any integer value. Each code page may be hashed with a secure hash algorithm (Hash) to generate a corresponding hash digest. Hash digest table214may store N hash digests for the N code pages.

FIG. 4shows a design of a process400to load and authenticate non-paged segment210and paged segment220of NAND Flash150, in accordance with an aspect of the invention. Process400may be performed when wireless device100is power up, etc. A verify function432may receive certificate216from NAND Flash150and root public key r from ROM134within wireless device100inFIG. 1. Verify function432may extract signature cx and public key x from certificate216, verify signature cx with root public key r, and provide public key x if signature cx is verified. Any tampering with certificate x by a third party can be easily detected by signature cx not verifying.

A multiplexer442may receive first code image212and hash digest table214and may sequential provide both parts to a secure hash function444. Function444may hash both first code image212and hash digest table214and may provide a hash digest, which may be called digest x′. Function444may implement the same secure hash algorithm used by secure hash function244inFIG. 2. A verify function446may receive digest x′ from secure hash function444, digital signature x from NAND Flash150, and public key x from verify function432. Verify function446may verify digital signature218with public key x and digest x′ and may indicate whether or not digital signature218is verified. Public key x is authenticated with root public key r. Hence, any tampering with digital signature218, first code image212, and/or hash digest table214by a third party can be easily detected by digital signature218not verifying.

If digital signature218is verified, then first code image212may be provided for use, and hash digest table214may be stored in a table456. Wireless device100may be enabled once first code image212has been loaded from NAND Flash150to SDRAM152. If digital signature218is not verified, then the loading process may be aborted, and an error message may be provided.

After enabling wireless device100, second code image222may be loaded from NAND Flash150to SDRAM152, one page at a time, as background task and/or on-demand as needed. A secure hash function454may hash a page retrieved from NAND Flash150and may provide a hash digest y′ for the retrieved page. Function454may implement the same secure hash algorithm used by secure hash function254inFIG. 2. A verify function458may receive the hash digest y′ from secure hash function454and the authenticated hash digest y for the retrieved page from table456. Verify function458may compare the two hash digests y′ and y and declare the retrieved page as authenticated if the two digests match. Hash digest table214may be authenticated with root public key r. The cryptographic properties of the secure hash algorithm ensure that the likelihood of another page mapping to the same hash digest y is very small. Hence, any tampering with the page by a third party can easily be detected by a mismatch between the two hash digests. The retrieved page may be provided for use if the hash digests match. The loading process may be aborted and an error message may be provided if the hash digests do not match.

FIGS. 2 to 4show one design of NAND Flash150, which supports progressive boot of non-paged segment210and paged segment220and further supports authentication of the code images stored in segments210and220. In general, NAND Flash150may store P code images in P paged segments and Q code images in Q non-paged segments, where P and Q may each be any integer value one or greater. The code images from the Q non-paged segments may be loaded from NAND Flash150prior to enabling wireless device100. The code images from the P paged segments may be loaded from NAND Flash150after enabling wireless device100.

Security for the code images stored in the non-paged and paged segments may be implemented in various manners. In general, security information used for authentication may comprise one or more certificates, digital signatures, hash digests, etc. Security information used to authenticate a code image from a non-paged segment (or simply, a non-paged code image) may be stored in that non-paged segment, in a designated non-paged segment, etc. Security information used to authenticate a code image from a paged segment (or simply, a paged code image) may be stored in that page segment, in another paged segment, in a non-paged segment, etc. Security information may be provided for each page of a paged code image to allow each page to be loaded and authenticated separately. Security information may also be provided for an entire paged code image. In one design, one non-paged segment may store security information for all non-paged and paged segments, as described above. In another design, authentication may be performed in a daisy chain manner, with each segment storing security information for the next segment to be loaded. Authentication of the non-paged and paged code images may also be performed in other manners.

For clarity, the following description assumes the use of the structure shown inFIGS. 2 to 4, and that NAND Flash150includes non-paged segment210and paged segment220. Non-paged segment210may include program codes that support basic functionality of wireless device100, codes to support progressive boot, etc. Paged segment220may include the remaining program codes for wireless device100.

FIG. 5shows a design of first code image212stored in non-paged segment210of NAND Flash150. In this design, first code image212includes modules510that support progressive boot, drivers530, user interface (UI) codes540, and modem codes550.

Within modules510, a header512may include pertinent information for NAND Flash150such as the number of paged and non-paged segments, the starting address and size of each segment, the location of each segment header, etc. A boot loader514may handle the loading of non-paged segment210from NAND Flash150to SDRAM152. A NAND driver516may retrieve pages from NAND Flash150and copy these pages to SDRAM152. A memory manager518may handle the loading of paged segment220from NAND Flash150to SDRAM152and may keep tracks of which pages of second code image222have been loaded. An abort handler520may handle page faults due to memory accesses of pages of second code image222that have not been loaded from NAND Flash150. When a page fault occurs, abort handler520may save the context of the current task and then request a pager handler522to load one or more pages including the requested page. Pager handler522may handle background and on-demand paging of requested pages of second code image222from NAND Flash150. Boot loader514and pager handler522may request NAND driver516to retrieve specific pages from NAND Flash150and copy these pages to SDRAM152.

Drivers530may support input/output (I/O) devices such as a liquid crystal display (LCD), a keypad, a microphone, a speaker, etc. UI codes540may support various UI functions such as display of animation at power up, acceptance of keypad inputs, display of pressed characters on the LCD, etc. UI codes540may provide an indication of life on wireless device100and may accept user inputs so that the wireless device can be perceived as operational to the user. Modem codes550may perform various functions to support radio communication, e.g., to initialize transmitter114and receiver116, to search for wireless systems, to originate and receive calls, to perform processing (e.g., encoding and decoding) for the calls, etc.

FIG. 5shows one design of non-paged segment210. Non-paged segment210may also include different and/or other modules not shown inFIG. 5. For example, non-paged segment210may include factory test codes, Binary Runtime Environment for Wireless (BREW) Application Execution Environment (AEE) codes, etc.

FIG. 6shows a design of SDRAM152at wireless device100inFIG. 1. First code image212may be retrieved from NAND Flash150and stored in SDRAM152during the first part of the progressive boot. Pages 0 through N−1 of second code image222may be retrieved in any order from NAND Flash150and stored in the proper location of SDRAM152during the second part of the progressive boot.

Background loading of second code image222may commence after first code image212has been loaded into SDRAM152. For background loading, the N pages of second code image222may be retrieved one page at a time and in a sequential order from NAND Flash150, authenticated, and stored in a corresponding location of SDRAM152. The entire second code image222may be completely loaded into SDRAM152in a particular amount of time, which may be referred to as the secondary load time. The background loading may be given lower priority than other tasks performed by wireless device100. Hence, the secondary load time may be variable and may be dependent on various factors such as the size of second code image222, the transfer rate between NAND Flash150and SDRAM152, the amount of activity at wireless device100, etc.

While performing background loading, a page of second code image222that has not yet been loaded may be accessed, and a page fault may occur. The requested page may be loaded on-demand from NAND Flash150and provided for use. In one design, only the requested page is loaded from NAND Flash150. In another design, the requested page and one or more nearby pages may be loaded from NAND Flash150. This design may avoid repeated page faults and hence improve performance. After completing the on-demand paging of the requested page, background loading of the remaining pages of second code image222may be resumed.

Memory manager518may keep track of which pages of second code image222have been loaded from NAND Flash150. This information may be used to determine whether a requested page is stored in SDRAM152or should be retrieved from NAND Flash150. The load status of the pages of second code image222may be stored in various manners.

FIG. 7shows a design of a 2-level structure700that may be used to determine whether a given page of second code image222is stored in SDRAM152. In this design, a 32-bit memory address702may include bits0through31and may have an address range of 0 to 4 gigabytes (GB). The address range may be partitioned into 4096 sections, with each address section covering one megabyte (MB). Each address section may cover 256 pages, and each page may be 4 KB.

Structure700may include one main table710with 4096 entries for 4096 address sections, one entry for each address section. Structure700may further include one page table720for each address section. Each page table may include 256 entries for 256 pages, one entry for each page.

In one design, the main table and the page tables for the entire second code image222may be created and initialized prior to loading any page of second code image222. For example, one main table and 64 page tables may be created within SDRAM152to support 64 MB of virtual memory for paging. Each entry in the main table may include a pointer to the start of the page table corresponding to that main table entry. The 256 entries of each page table may be initialized to a predetermined value to indicate that the 256 pages covered by these entries have not been loaded into SDRAM152(or no access permission for these 256 pages). When a page is loaded from NAND Flash150to SDRAM152, the page table covering that page may be ascertained, and the entry for that page may be updated to indicate that the page has been loaded into SDRAM152.

While second code image222is being loaded from NAND Flash150, each memory access of SDRAM152may be checked to determine whether the requested page is stored in SDRAM152. The 12 most significant bits (MSBs) of the memory address for a memory access may be used to access an entry in the main table. The pointer from this main table entry may be used to determine the start of the page table for the address section covering the memory address. The 8 next MSBs of the memory address may be used to determine a page table entry for the page being accessed. This page table entry may be checked to determine whether the page being accessed has been loaded into SDRAM152. If the page has been loaded, then SDRAM152may be accessed to obtain the requested program code or data. If the page has not been loaded, then abort handler520may be notified, and the requested page may be loaded into SDRAM152.

The main table and page tables may be used to determine whether individual pages of second code image222have been loaded into SDRAM152. An indicator may be used to indicate whether all of the N pages of second code image222has been loaded into SDRAM152. This indicator may be initialized to one value (e.g., 0) and may be set to another value (e.g., 1) once all of the pages of second code image222has been loaded into SDRAM152. The main table and page tables may be deleted after the entire second code image222has been loaded.

FIG. 7shows one design of structure700to determine whether pages of second code image222have been loaded into SDRAM152. Structure700may be similar to a structure used for memory protection to keep track of which pages are accessible. Structure700may thus be implemented and updated in similar manner as the structure used for memory protection.

Various other structures may also be used to keep track of which pages of second code image222have been loaded into SDRAM152. For example, a bit map containing one bit for each page may be used. The bit for each page may be set to one value (e.g., 0) if the page has not been loaded into SDRAM152or to another value (e.g., 1) if the page has been loaded.

FIG. 8shows a design of a process800for programming a memory device, e.g., during manufacturing or provisioning phase, in accordance with an aspect of the invention. First security information may be generated based on a first code image and possibly other information (block812). Second security information may be generated based on a second code image (block814). The first code image may be programmed into a memory device used for a wireless device (block816). The first code image may be loaded from the memory device to boot the wireless device and render the wireless device operational. The second code image may be programmed into the memory device (block818). The second code image may be loaded from the memory device while the wireless device is operational to further or fully boot the wireless device. The first and second security information may be programmed into the memory device and may be used to authenticate the first and second code images, respectively (block820).

For block814, the second code image may be partitioned into a plurality of pages, and each page may be hashed with a secure hash algorithm to obtain a hash digest for that page. A table of hash digests for the plurality of pages may be generated and programmed into the memory device in block820. For block812, a digital signature may be generated based on the first code image, a private key, and the table of hash digests for the second code image. A certificate containing a public key corresponding to the private key may be generated. The certificate and the digital signature may be programmed into the memory device in block820.

FIG. 9shows a design of a process900for performing progressive boot of a wireless device at power up, in accordance with an aspect of the invention. A first code image may be loaded from an external memory to boot the wireless device, e.g., loaded from a NAND Flash to an SDRAM (block912). First security information for the first code image may be obtained from the external memory (block914). The first code image may be authenticated based on the first security information (block916). The wireless device may be rendered operational after loading and authenticating the first code image (block918). While operational, the wireless device may be capable of processing keypad inputs, establishing calls with a wireless system, etc.

A second code image may be loaded from the external memory while the wireless device is operational to further boot the wireless device (block920). Second security information for the second code image may be obtained from the external memory (block922). The second code image may be authenticated based on the second security information (block924). Execution of the second code image may be enabled if authenticated (block926).

For block920, the second code image may be loaded as background task and/or on-demand while the wireless device is operational. For on-demand loading, a memory access for a page of the second code image may be received. A predetermined number of pages of the second code image, including the page being accessed, may be loaded from the external memory in response to the memory access.

The second code image may comprise a plurality of pages, which may be loaded one page at a time from the external memory. At least one table may be maintained to keep track of pages of the second code image that have been loaded and pages of the second code image that have not been loaded. For example, a main table with multiple entries for multiple address ranges may be maintained. Multiple page tables for the multiple address ranges may also be maintained, one page table for each address range, with each page table including multiple entries for multiple pages within the address range for that page table. Each entry of the main table may include a pointer to a corresponding page table. Each entry of the corresponding page table may indicate whether an associated page is loaded and accessible. The table(s) may be created prior to loading the second code image and may be deleted after loading the second code image.

For block916, the first security information may comprise a certificate and a digital signature. The certificate may be authenticated based on a root public key, which may be securely stored at the wireless device. The first code image may be authenticated based on the digital signature and a public key from the certificate. For block924, the second security information may comprise at least one hash digest, which may be authenticated based on the first security information. The second code image may then be authenticated based on the at least one hash digest.

FIG. 10shows a design of a process1000for authenticating a code image, in accordance with an aspect of the invention. Process1000may be used for blocks920to924inFIG. 9. A plurality of pages of a code image may be retrieved from an external memory, with the plurality of pages being associated with separate security information (block1012). The plurality of pages may be retrieved one page at a time and either in a predetermined order (e.g., for background loading) or in a random order determined based on memory accesses for pages of the code image (e.g., for on-demand loading). Each page retrieved from the external memory may be authenticated based on security information for that page (block1014). In one design, a table of hash digests for the plurality of pages may be retrieved from the external memory and authenticated. Each retrieved page may be hashed based on a secure hash algorithm to obtain a generated hash digest for that page. The retrieved page may be declared as authenticated if the generated hash digest matches an authenticated hash digest for the page, which may be from the table of hash digests.

FIG. 11shows a block diagram of a design of programming station1100for NAND Flash150, in accordance with an aspect of the invention. Programming station1100includes a controller/processor1110, a memory1112, programming tools1114, and a database1116. Controller/processor1110may perform the secure processing shown inFIG. 2and may further direct the operation of programming station1100. Memory1112may store data and codes used by controller/processor1110. Programming tools1114may program NAND Flash150, e.g., as shown inFIG. 2. Database1116may store the code images to be programmed into NAND Flash150, cryptographic keys, etc. Programming station1100may perform process800inFIG. 8and/or other processes to program memories.

For clarity, the boot techniques have been described for a memory configuration with a NAND Flash and an SDRAM. The boot techniques may also be used for other memory configurations and other types of memories. The boot techniques may further be used for any number of non-paged and paged code images, any number of non-paged and paged segments, any page size, etc.

The boot techniques described herein may provide certain advantages. A shorter perceived boot time may be achieved for memory load at power up. This may result in shorter factory test time since factory test codes may be stored in a non-paged segment and loaded first. The factory test codes may rely on the early loading of these codes and may have test equipment talk to a wireless device sooner after power up, even if the wireless device has not finished the loading process. The shorter perceived boot time may reduce the amount of time a user waits after power up and may thus improve user experience.