KR20160049956A - Mobile divece and operating method thereof - Google Patents

Abstract

An operating method for shadowing one or more boot images of a mobile device comprises the following steps: setting a first register representing whether the boot images are configured or not by a host unit of the mobile device; and periodically accessing a shadow routine by a shadow control logic unit, thereby having improved operating speed and performance.

Description

≪ Desc / Clms Page number 1 > MOBILE DIVECE AND OPERATING METHOD THEREOF &

The present invention relates to mobile devices, and more particularly, to a method of shadowing boot images of a mobile device.

Nonvolatile memory (flash) storage is an important component of smartphones, smartphones, tanlets, ultra-books, wearable devices and other embedded and mobile devices. to be. The issue of "device not booting" includes a very high percentage of reasons why end users return the mobile device for repair or replacement. Symptoms that these devices do not boot are due to variations in the boot data of the flash storage device. Boot data modifications can be controlled from many sources, such as sudden power loss, poor power subsystem design, software faults, host system problems, unintentional overwriting of the boot area, or unprotected data .

Generally, debugging of boot images can be performed through a USB function enabled after the boot loader image is executed. However, in a typical approach, if the boot images present in the boot partition are modified due to, for example, sudden power loss, poor system design, software defects, and / or weak device firmware structure, Can not be booted and there is no easy way to reprogram the boot image, especially in the production version of mobile devices with generally limited debugging capabilities.

In most cases, it costs a lot of time and the repair costs of these devices. These problems can affect not only the end-users of these devices, but also the manufacturers' sub-lines, component suppliers and / or distribution partners.

It is an object of the present invention to provide a mobile device with improved performance and a method of operation thereof.

An operating method for shadowing one or more boot images of a mobile device according to an embodiment of the present invention includes determining, by the host portion of the mobile device, whether one or more boot images are configured And setting the first register to a first state, and periodically entering the shadow routine by a shadow control logic unit.

A mobile device according to an embodiment of the present invention includes a first non-volatile memory for storing one or more boot images in a reserved area for boot partitions, a second non-volatile memory for storing reserved areas for user partitions, Volatile memory for storing one or more user images; and a second nonvolatile memory for storing the one or more boot images from the first nonvolatile memory into one or more shadowed boot regions of the region reserved for the user partitions of the second non- And a shadow control logic portion that shadows images.

According to embodiments of the present invention, the mobile device shadows boot images. Subsequently, a mobile device with improved operating speed and performance and an operating method thereof are provided.

1 is a block diagram illustrating a mobile device including a shadow control logic portion in accordance with an embodiment of the present invention.
2 is a block diagram illustrating shadow copies of boot partitions, user partitions, and boot partitions in accordance with an embodiment of the present invention.
3 is a block diagram illustrating a dynamic shadowing technique in accordance with an embodiment of the present invention.
4 is a flowchart illustrating a technique for verifying a boot image according to an embodiment of the present invention.
5 is a flow chart illustrating a technique for shadowing one or more boot images in accordance with an embodiment of the invention.
6 is a flowchart illustrating a technique for detecting a boot failure according to an embodiment of the present invention.
7 is a block diagram illustrating a computing system including the shadow control logic portion of FIG.

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the concepts of the present invention. It is to be understood that persons of ordinary skill in the art may implement the concepts of the present invention without these specific details. In other instances, well-known methods, procedures, elements, circuits, and networks have not been described in detail in order to make unnecessary aspects of the embodiments clear.

 The terms first and second can be used to describe various components, but the components are not limited by the terms. These terms are used to distinguish one element from another. Without departing from the scope of the inventive concept, the first server may be referred to as a second server, and similarly, the second server may be referred to as a first server.

The terminology used in describing the concepts of the present invention is intended to illustrate specific embodiments of the invention and is not intended to limit the inventive concept. As used in the description of the concepts of the present invention and the appended claims, singular forms, such as "a," "an," and "the" are intended to include the plural, unless the context clearly dictates otherwise. The terms "and / or" include all possible combinations of one or more of the listed items. As used in the detailed description of the present invention, terms such as "comprising" or "comprising" specify the presence of stated features, steps, operations, components, and / or components, , Components, components and / or groups thereof.

Embodiments of the present invention include techniques for replicating boot images to shadow partitions of a user area of a non-volatile memory device such as a flash memory. The technique may include detecting a boot image variation, controlling a mobile device to boot from shadow partitions. The technique may include dynamic shadowing and release of blocks used from shadow partitions. The technique may include boot failure recovery and retention of bad images through flash translation layer (FTL) firmware. Failures of boot image modification may be debugged and / or recovered using shadow partitions.

1 is a block diagram illustrating a mobile device 105 that includes a shadow control logic portion 120 in accordance with an embodiment of the present invention. The mobile device 105 may include a code storage area 110, a host part 125 and a shadow control logic part 120. [ Shadow control logic 120 may be part of code storage 110, although shadow control logic 120 is illustrated as being separate from code storage 110. For example, shadow control logic 120 may be located on or in firmware, hardware, or a combination thereof, or non-volatile device 155 and / or central processing unit (CPU) 135. The code execution block 115 initiates the example boot sequence 190 of the mobile device 105. CPU 135 may include registers 130 and CPU read only memory (ROM) The ROM 140 may be a non-volatile memory. The CPU ROM 140 may include a first CPU boot loader image 145 and a second CPU boot loader image 150. In other words, the CPU ROM can store one or more boot images in the area reserved by the boot partitions.

The code storage unit 110 may include a nonvolatile memory 155. [ The non-volatile memory 155 may include flash memory, magneto resistive random access memory (MRAM) modules, phase-change memory (PRAM) modules, have. Non-volatile memory 155 may include boot logical unit 0 (boot logical unit 0, LU0) and / or boot LU1. The non-volatile memory 155 may include a replay protected memory block (RPMB) Non-volatile memory 155 may include an area for user LUs 165. The area for user LUs may include shadowed boot images such as boot LU0 and / or boot LU1. Non-volatile memory 155 may include an operating system (OS) kernel image 170, system and user data images 175.

The host unit 125 may execute host processes and applications. The host unit 125 may be connected for communication with the code storage unit 110 and / or the shadow control logic unit 120. For example, host portion 125 may update and / or access one or more registers 130 and / or 132. The shadow control logic portion 120 may store one or more boot images (the first CPU boot loader image 145 and / or the second CPU boot loader image 150) into one or more shadowed boot Images (boot LU0 and / or boot LU1).

There is a particular code execution that can occur in a particular order, as described in code execution 115 of the boot sequence 190 of the mobile device 105. For example, booting may be initiated from the CPU within the ROM code execution when the mobile device 105 is powered on. As such, booting can handle boot partitions / LUs of non-volatile element 155. More specifically, the first CPU bootloader image 145 may be loaded into one internal random access memory (IRAM), and the second CPU boot loader image 150 may be loaded into two IRAMs and / Or a dynamic random access memory (DRAM). Can be loaded into the DRAM of the boot loader image 160 (3), and the OS core images 175 can be loaded into the DRAM of 5.

2 is a block diagram of a computer system 200 that includes boot partitions 205 (sometimes referred to as " boot images "), user partitions 215 (sometimes referred to as" user images " And the shadow copies 225 of the boot partitions. The boot LU shadowing routine 220 may be performed periodically from the shadow control logic portion (120 in FIG. 1). The shadow control logic portion 120 may shadow one or more boot images 205 to one or more shadowed boot images 225. [

The mobile device 105 may generally boot from one or more boot images 205 as disclosed by arrow 237. In the event of a modification of one or more boot images 205, the mobile device 105 may instead boot from one or more shadow boot images 225 as shown from arrow 239. The shadow control logic 120 may detect a variation in one or more boot images 205. In response to detecting the deformation, the shadow control logic 120 may control the mobile device 105 to boot from one or more shadowed boot images 225.

More specifically, a flash translation layer (FTL) 230 may map one or more pointers between physical addresses 235 to one or more shadow images 205 in one or more boot images 205, You can update (225) the boot images. The FTL operations of the logical addresses 240 and the host part 125 (FIG. 1) interfaces and physical addresses 235 may be hidden from the host part 125. In other words, if shadow images 225 are not visible on the host, they can be protected from external access. The FTL 230 may update the pointers with shadow images 225 on boot failure detection and the original boot images 305 may not be accessible to the host part 125 operating in the logical address space 240 do. One or more altered images 205 may be protected from cause and / or debug of subsequent roots.

3 is a block diagram illustrating a dynamic shadowing technique in accordance with an embodiment of the present invention. The shadow control logic portion 120 of FIG. 1 may sense the amount of available space 305 in the reserved area for user partitions 215 and may determine the available space 305, as shown at 325, It is possible to judge whether the amount is equal to or less than a predetermined threshold value 310. [ When it is determined that the amount of available space 305 is less than or equal to the predetermined threshold 310, the shadow control logic unit 120 is designated for garbage collection and the shadow boot image copies 225 Can be generated. And, as shown at 330, the space occupied from the shadow boot image copies 225 may be released into the reserved area for user partitions 215. [ As shown in 330, when the amount of second available space 315 is less than available space 305, the total available space for user partitions 215 increases. As such, an impact on the usable density of the storage device for user partitions is achieved.

The shadow control logic portion 120 may determine that the amount of available space 320 is greater than a predetermined threshold 310 as shown in 335, And recreate the allocated space within the reserved area for the partitions 215. [ For example, if the device is less full (providing a density of more than five times the full boot partition / LU size), the shadow control logic 120 automatically enters the shadowing routine to replicate boot partitions to the user area . In other words, blocks in the area of non-volatile memory 155 reserved for user partitions 215 may be freed and retrieved to accommodate the shadowing of boot partitions.

4 is a flowchart 400 illustrating a technique for verifying a boot image in accordance with an embodiment of the present invention. In step 405, the mobile device (105 in FIG. 1) is powered. The host unit (125 in FIG. 1) may generate boot partitions to fill the boot loader images from the ROM (145, 150). Then, in step 410, the host unit (125 in FIG. 1) may execute the main boot loader images after the system power is supplied. In step 415, the host unit 125 may execute the boot loader from the boot LUs (one or more boot images 205 in FIG. 2). In operation 420, the host unit 125 may fetch an OS kernel.

In step 425, when the boot loader step and the OS kernel fetching step are successfully passed, the host unit 125 determines whether the boot images 205 are well-formed and validated, such as 1, A BOOT_SUCCESS register (130, 132 in FIG. 1) can be set. The BOOT_SUCCESS register may be set to any other suitable value for differentiating between two different states. BOOT_SUCCESS can be variably stored in any suitable memory area. The BOOT_SUCCESS register may allow preserving good data of the boot images 205 in the shadow images 225. The BOOT_SUCCESS register may direct the shadow control logic 120 to verify the image of the boot partitions to start the shadowing process if the shadowing is not complete. In step 430, the host unit 125 may execute the OS kernel.

5 is a flowchart 500 illustrating a technique for shadowing one or more boot images in accordance with an embodiment of the present invention. In step 505, a shadow routine is started. The shadow control logic portion (120 in FIG. 1) may generate a shadow routine that enters periodically. Upon reaching certain states, the shadow control logic 120 may cause one or more boot partitions (205 in FIG. 2) to be partitioned into one or more shadow partitions 225). ≪ / RTI >

In step 510, for the start time of the shadow routine, the determination may be made according to whether or not the BOOT_FROM_SHADOW register (130, 132 in FIG. 1) is equal to a predetermined value such as one. Value indicates whether the mobile device 105 will boot from one or more shadowed boot images 225 or from one or more shadowed images 225. [ The shadow routine is no longer terminated at no-operation (NOP) 515 and ends. A value of zero indicates that the mobile device 105 is not booted from one or more shadowed boot images 225. In this case, the shadow routine is processed in step 520. The BOOT_FROM_SHADOW register may be set to any other suitable value for differentiating between two different states. BOOT_FROM_SHADOW can be variably stored in any suitable memory area.

In step 520, another determination may be made as to whether the hash check is the same. More specifically, the shadow control logic portion (120 in FIG. 1) may compare the hash of one or more shadowed boot images 225 with the hash of one or more boot images 205. In response to the match of the comparison of the first and second hashes, it indicates whether one or more shadowed boot images 225 match one or more boot images 205. Then, the routine ends with the NOP 530. In other words, if the routine ends with NOP 530, this means that the shadow images have already been configured. Conversely, in response to the inconsistency of the comparison of the first and second hashes, the routine continues to step 535, where the SHADOW_COMPLETE register indicates that the one or more shadowed images 225 are complete It can be set to a predefined value, such as 0, which means the copy is not yet. The SHADOW_COMPLETE register may be set to any other suitable value for differentiating between two different states. SHADOW_COMPLETE may be variably stored in any suitable memory area.

At step 540, one or more boot images 205 may be replicated to one or more shadowed boot images 225 of the user area reserved for user LUs. Replication may be performed in an incremental fashion so as not to affect the performance of the mobile device 105.

In step 545, another determination may be made as to whether the hash check is the same. This determination is the same as or similar to the determination method mentioned in step 525. If it is determined that the hash check is not the same, shadowing is not successful. Then, the shadowed images are invalidated and require reconstruction. The process then returns to step 540 for additional replication of the boot LUs to the user area.

On the other hand, if it is determined that the hash check is the same, step 550 is performed. The SHADOW_COMPLETE register is set to one. This indicates that the shadowing process is complete. The host unit 125 can know the state (whether or not to shadow) by reading the SHADOW_COMPLETE status register. The hash codes of one or more boot images may be stored and stored for data comparison and error checking.

The shadow control logic portion (120 in FIG. 1) may allocate physical regions of the user partition as shadowing partitions. The total size of these areas may be equal to the total size of boot partitions (boot LUs). The shadow control logic 120 may additionally configure one or more shadowed boot images in a single-level cell (SLC) mode for improved performance and stability. The shadow control logic portion 120 can read data from the boot partitions and write data to the shadowed boot images stored in the user partition during the device idle time.

If the shadowing process is aborted from a host command that brings the mobile device 105 to an idle state, the shadow control logic unit 120 may track the process. If the mobile device 105 enters the idle state again, the shadow control logic portion 120 may resume the shadowing process until the shadowing process is complete. Thereafter, the shadow control logic unit 120 may perform hash checking, and may set the SHADOW_COMPLETE status register to 1, indicating that the shadowing process is complete. The physical location of the blocks for the shadow partitions need not be fixed. The shadow control logic 120 may track the physical locations of the blocks of the shadow partitions. The steps shown in Fig. 5 need not occur in order, but may occur in different orders and / or intermediate steps.

FIG. 6 is a flowchart 600 illustrating a technique for detecting a boot failure according to an embodiment of the present invention. During the boot process of the mobile device 105, the primary boot loaders (145, 150 in FIG. 1) of the CPU ROM (140 in FIG. 1) are executed first. The primary boot loaders may generate initialization command sequences into the non-volatile memory (155 in FIG. 1) via the host portion (125 in FIG. 1). For example, if the BOOT_SUCCESS register is set to 1, the shadow control logic portion (120 in FIG. 1) can estimate that boot images (205 in FIG. 2) of the boot partition are good, Images can be replicated to shadowed boot images in a dynamic shadowing process.

For example, if the BOOT_SUCCESS register has a value of zero, the shadow control logic unit 120 may maintain an INIT_CYCLE internal counter to track the total number of host initiation issuance requests. If the BOOT_SUCCESS register changes from a value of 0 to a value of 1, the INIT_CYCLE counter can be cleared to a value of zero.

In response to the determination of the BOOT_SUCCESS register indicating that one or more boot images are not configured (step 520 of FIG. 5), the shadow routine may be processed as in step 605 of FIG. The shadow control logic unit 120 may count the number of initialization requests from the host unit 125 of the mobile device 105. [ The shadow control logic unit 120 may determine whether the number of initialization requests exceeds a predetermined threshold 20. [

If the number of initialization requests does not exceed the predetermined threshold, the routine ends at NOP 610, which means that the initialization cycle condition is not satisfied, and the host unit 125 performs more boot retries Needs to be. On the other hand, in step 615, the shadow control logic unit 120 determines whether the SHADOW_COMPLETE register has completely shadowed one or more boot images (205 in FIG. 2) into one or more shadowed boot images .

If the SHADOW_COMPLETE register is not equal to one (0), the routine may be terminated at NOP 620, which means that the shadowing process is not properly completed before the mobile device 105 fails to boot. On the other hand, in response to the determination by the second register that one or more boot images are completely shadowed (SHADOW_COMPLETE = 1) with one or more shadowed boot images, the shadow control logic portion 120 may determine that one or more boot images (205 in FIG. 2) and the second hash of one or more shadowed boot images (FIG. 2, 225).

In other words, when the shadow control logic unit 120 determines that the number of initialization requests from the host unit 125 is larger than the predetermined threshold value 20, the shadow control logic unit 120 determines that the current boot partition images A hash checking process may be performed to compare the hashed and copied images within the shadow partitions. The duration of this hash checking process may depend on the setting of the 'X' number that can be programmed by the host unit 125 through the hash checking period register of the mobile device 105. For example, the mobile device 105 may have a default value for 20 hash checking periods.

In step 625, if the shadow control logic 120 finds a hash code mismatch that may mean a boot partition (LU) image modification, the high number of host initialization attempts is the root cause of the boot image modification . This failure can be detected automatically. In operation 635, the shadow control logic unit 120 may generate the FTL for updating the logical address pointers of one or more boot partitions to the shadowed partitions in the physical boot area. In step 640, the shadow control logic unit 120 may set the BOOT_FROM_SHADOW register to 1 to notify the host unit 125. [ The next boot will boot from one or more shadow partitions in the user area.

After booting from the shadow partitions, the host unit 125 can check the BOOT_FROM_SHADOW register of the OS and additionally display a message to the user informing the user to take action. On the other hand, if, in step 625, the shadow control logic 120 finds that the hash check is the same (hashes are the same), the routine ends at NOP 630, which means that boot failed, It is not necessarily found in boot partitions.

In other words, in step 625, in response to a discrepancy due to a comparison of the hash of one or more boot images and the hash of one or more shadowed boot images, the shadow control logic 120 may assume that one or more boot images have been modified have. In step 635, the FTL may update one or more pointers from one or more boot images, for each of the one or more shadowed boot images. In operation 640, the shadow control logic unit 120 may set the BOOT_FROM_SHADOW register to a predetermined value, such as 1, indicating that the mobile device 105 is booted with one or more shadowed boot images.

The steps shown in Fig. 6 need not occur in the order shown, but may occur in different orders and / or intermediate steps.

Table 1 below is provided to help understand the various registers described in the present invention.

Register name Kinds Type Definitions usage BOOT_SUCCESS R / W / CP The resolver can write after the value is erased by power failure and / or hardware reset. The host can reset the registers after all boot cycles have been completed. The register can be reset automatically (by the firmware) when all devices are powered on. SHADOW_COMPLETE R / W / E Registers can be written multiple times while maintaining values after power failure, hardware reset, and / or software reset. The registers can also be read. The register may be a status register for indicating the completion of the shadowing process of the host unit and / or the device firmware. BOOT_FROM_SHADOW R / W / E Registers can be written multiple times while maintaining values after power failure, hardware reset, and / or software reset. The registers can also be read. The register may be a status register for informing the host and / or device firmware to be current and next booted from one or more shadowed partitions.

The steps shown in Fig. 6 need not occur in the order shown, but may occur in different orders and / or intermediate steps.

Table 1 below is provided to help understand the various registers described in the present invention.

7 is a block diagram illustrating a computing system including the shadow control logic portion of FIG. 7, a computing system 700 includes a processor 710, such as a clock 710, a random access memory (RAM) 715, a user interface 720, a baseband chipset, A solid state drive / disk (SSD) 740, a memory controller 745, and / or a processor 735, an electrical (not shown) And a system bus 705 connected to the system bus 705. The shadow control logic portion 730 of FIG. 7 is the same as the shadow control logic portion 120 described above, and is electrically connected to the system bus 705. Shadow control logic 730 may include or interface with clock 710, RAM 715, memory controller 745, and / or processor 735.

The "device does not boot" problem arises from the boot code image modification of boot logical units (boot partitions), and embodiments of the present invention can help the mobile device recover from this failure. According to embodiments of the present invention, the firmware of the non-volatile memory (flash storage device) is used to transfer the contents of the boot logical units (boot partitions) to user logical units (user partitions) via firmware internal data, Can be copied automatically. The copied copies of the boot images contain the same hash data as the original images in the boot logical units. The hash data can be maintained for error checking. Copied copies of the user partition are named shadow partitions.

If code changes occur in the boot partitions due to a "device not booting" problem, the firmware can automatically detect failures based on subsequent initialization retry requests from the host. These retry thresholds are configurable from the host and may have default values. If the failure detection reference value and the threshold match, the firmware FTL layer automatically updates the physical address table of the boot partitions that point to the shadow partitions of the user area containing valid copies of the original boot code images.

Thus, when the mobile device attempts to reboot, the boot code data may be patched from the shadow partitions of the host. When the host operates in the logical address space and the firmware FTL layer handles pointer updates inside the non-volatile memory storage device, the essential aspects of the invention may not be visible to the host hardware and software. Failure conditions can be preserved for root generation and debugging.

Various embodiments of the invention may be implemented with minimal host software intervention. Different sizes of boot partitions / LUs can be supported with capacities as large as several hundred megabytes or more. In some embodiments, the shadow control logic portion 120 may shadow the OS kernel when located in the boot LU. Incremental replication is performed during the background and / or device idle time and does not affect performance. Furthermore, shadowing is dynamic and there is no loss of density because the device can be released when it is full.

The foregoing description provides a brief, general description of a machine or a suitable machine upon which certain aspects of the inventive concepts may be implemented. In general, a machine may be a processor, a processor, a memory (RAM, read-only memory, ROM or other storage medium), storage devices, a video interface, and / The system bus.

The machine can be controlled from the input of common input devices such as keyboards, mice, and the like. As well as. The machine may be controlled from a virtual reality (VR) environment received from another machine, biometric feedback, or an interaction indication with another input signal. As used herein, the term "machine" is used in conjunction with a signal machine, a virtual machine, or a system connected to communicate with a machine, virtual machines or devices operating together. Examples of such machines include personal computers, workstations, servers, portable computers, handheld devices, cellular phones, computing devices such as tablets, as well as personal or public transport And transport devices such as devices (automobiles, trains, taxis).

The devices may be programmable or non-programmable logic devices or arrays, application specific integrated circuits (ASICs), embedded computers, embedded controllers such as smart cards embedded controllers. A machine may utilize one or more connections with one or more remote machines via a connection to a network interface, modem, or other communication. The machines may be interconnected via physical and / or logical network methods such as intranets, local area networks, wide area networks. Those skilled in the art will appreciate that network communications including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optical, infrared, / ≪ / RTI > or wireless short-range or long-distance transport and protocol.

Embodiments of the present invention may be described in conjunction with or with reference to related data, including functions, procedures, data structures, application programs. Related data may include volatile and / or nonvolatile memory such as RAM, ROM or other storage devices and hard drives, floppy-disks, optical storage, tables, flash memory sticks, Information storage, and the like. Relevant data may be transmitted over transport environments that include physical and / or logical networks in the form of packets, serial data, parallel data, radio signals, etc., that may be used in a compressed or encrypted format. The relevant data is used in a distributed environment and can be stored locally and / or remotely for machine access.

As described above, an optimal embodiment has been disclosed in the drawings and specification. Although specific terms have been employed herein, they are used for purposes of illustration only and are not intended to limit the scope of the invention as defined in the claims or the claims. Therefore, those skilled in the art will appreciate that various modifications and equivalent embodiments are possible without departing from the scope of the present invention. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims.

105: mobile device 170: OS kernel image
110: storage area 175: user data images
115: code execution block 700: computing system
120: Shadow control logic area 705: Bus
125: Host section 710: Clock
132: Register 715: RAM
135: CPU 720: user interface
140: CPU ROM 725: modem
145: First CPU boot loader image 730: Shadow control logic unit
150: Second CPU boot loader image 735: Processor
155: nonvolatile memory 740: SSD
160: Boot loader image 745: Memory controller
165: User LUs

Claims (10)

CLAIMS What is claimed is: 1. An operating method for shadowing one or more boot images of a mobile device, comprising:
Setting a first register by the host unit of the mobile device, the first register indicating whether one or more boot images are configured; And
Wherein the shadow control logic unit periodically enters the shadow routine. The method according to claim 1,
In the shadow routine,
In response to determining that the first register indicates that the one or more boot images are configured:
Shadowing the one or more boot images with one or more shadowed boot images by the shadow control logic; And
Further comprising setting a second register by the shadowing control logic to indicate whether the one or more boot images are fully shadowed with the one or more shadowed boot images. 3. The method of claim 2,
In the shadow routine
In response to determining that the first register indicates that the one or more boot images are not configured:
Counting the number of initialization requests from the host portion of the mobile device by the shadow control logic portion;
Determining, by the shadow control logic, whether the number of initialization requests exceeds a threshold;
Determining if the second register indicates whether the one or more boot images are fully shadowed with the one or more shadowed boot images if the number of initialization requests is determined to exceed the threshold; And
If the second register indicates that the one or more boot images have been fully shadowed with the one or more shadowed boot images, then the first hash of the one or more boot images is stored in the one or more shadowed boot images And comparing the second hash to the second hash. The method of claim 3,
In the shadow routine
If the first hash and the second hash do not match, then:
Updating, by the flash translation layer, one or more pointers from the one or more boot images to the one or more shadowed boot images, respectively; And
Further comprising: setting, by the shadow control logic, a third register indicating that the mobile device will boot from the one or more shadowed boot images. A first non-volatile memory for storing one or more boot images in a reserved area for boot partitions;
A second non-volatile memory for storing one or more user images in a reserved area for user partitions; And
And a shadow control logic portion for shadowing the one or more boot images from the first non-volatile memory into one or more shadowed boot images of the region reserved for the user partitions of the second non-volatile memory. Device. 6. The method of claim 5,
Wherein the shadow control logic portion senses a variation in the one or more boot images,
And in response to the detection, the shadow control logic unit controls the mobile device to boot from the one or more shadowed boot images. The method according to claim 6,
Updating one or more pointers from the one or more boot images to the one or more shadowed boot images respectively and updating the one or more bootings including the variant for subsequent root cause or debugging, Further comprising a flash translation layer to protect the images. 6. The method of claim 5,
Wherein the shadow control logic portion senses the amount of available space in the area reserved for the user partitions and determines whether the amount of available space is below a threshold. 9. The method of claim 8,
If the amount of available space is below the threshold,
Wherein the shadow control logic unit comprises:
Garbage collection of the one or more shadowed boot images,
And releases the space of the area reserved by the user partitions of the second nonvolatile memory occupied from the one or more shadowed boot images. 9. The method of claim 8,
If the amount of available space is greater than the threshold,
Wherein the shadow control logic unit comprises:
Allocating space in the area reserved for the user partitions for the one or more shadowed boot images,
Wherein the one or more boot images from the first non-volatile memory are shadowed with the one or more shadowed boot images of the region reserved for the user partitions of the second non-volatile memory.

Images