US10146627B2

Movatterモバイル変換

Info

Publication number: US10146627B2
Application number: US15/726,375
Authority: US
Inventors: Yang Yu; Chang-eun Choi; Kyung Ho Kim; Walter JUN; Wonchuri Zoo; Robert Brennan
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2014-10-28
Filing date: 2017-10-05
Publication date: 2018-12-04
Anticipated expiration: 2035-03-19
Also published as: US20180032403A1; US9823972B2; KR20160049956A; KR102198609B1; US20160117225A1

Abstract

Embodiments of the inventive concept include computer-implemented method for shadowing one or more boot images of a mobile device. The technique can include duplicating boot images to shadow partitions in a user area of a non-volatile memory device such as a flash memory. The technique can include detecting boot image corruption, and causing a mobile device to boot from the shadow partitions. The technique can include dynamically shadowing and releasing blocks used by the shadow partitions. The technique can include boot failure recovery and bad image preservation through firmware flash translation layer (FTL) logical to physical mapping updates. Boot image corruption failures can be recovered from and/or debugged using the shadow partitions.

Description

RELATED APPLICATION DATA

This application is a continuation patent application of U.S. patent application Ser. No. 14/663,220, filed Mar. 19, 2015, which claims the benefit of U.S. Patent Application Ser. No. 62/069,805, filed Oct. 28, 2014, which is hereby incorporated by reference.

BACKGROUND

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

Non-volatile memory (e.g., flash) storage is a crucial component of today's smartphones, tablets, ultra-books, wearable devices and other embedded and mobile devices. A “device-does-not-boot” issue comprises a very high percentage of the reasons why end users return their mobile device for repair or replacement, which can cause a significant negative user experience. Many of these device-does-not-boot symptoms are due to corruption of boot data in the flash storage device. Boot data corruption can be caused by many reasons such as a sudden power-loss, poor power subsystem design, software glitches, host system issues, inadvertent overwrite to the boot partition, unprotected data, or the like.

Conventionally, debugging of boot images is performed through USB capability that is enabled after the boot loader image gets executed. But in the conventional approach, if the boot images residing in boot partitions are corrupted, for example, due to sudden power loss events, poor system design, software glitches, and/or weakness of device firmware architecture, then the mobile devices will not boot and there is no easy method to reprogram the boot images, especially in the production version of the mobile devices, which conventionally have very limited debugging capability.

Most often it is time consuming and costly to repair these devices or debug the issues. Such problems impact not only the end users of these devices, but also the bottom line of the original manufacturer, component suppliers, and/or distribution partners. Embodiments of the present inventive concept address these and other limitations in the prior art.

BRIEF SUMMARY

Embodiments of the inventive concept include a computer-implemented method for shadowing one or more boot images of a mobile device. The method can include storing, in a section reserved for boot partitions in a first non-volatile memory of the mobile device, the one or more boot images. The method can include shadowing, by a shadow control logic section, the one or more boot images to one or more shadowed boot images in a section reserved for user partitions in a second non-volatile memory of the mobile device.

Embodiments of the inventive concept can include a computer-implemented method for shadowing one or more boot images of a mobile device. The method can include setting, by a host section of the mobile device, a first register indicating whether or not one or more boot images are constructed, and periodically entering, by a shadow control logic section, a shadow routine.

Embodiments of the inventive concept can include a mobile device. The mobile device can include a first non-volatile memory configured to store, in a section reserved for boot partitions, one or more boot images, a second non-volatile memory configured to store one or more user images in a section reserved for user partitions, and a shadow control logic section configured to shadow the one or more boot images from the first non-volatile memory to one or more shadowed boot images in the section reserved for the user partitions in the second non-volatile memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and additional features and advantages of the present inventive principles will become more readily apparent from the following detailed description, made with reference to the accompanying figures, in which:

FIG. 1 is an example block diagram of a mobile device including shadow control logic section in accordance with embodiments of the inventive concept.

FIG. 2 is an example block diagram of boot partitions, user partitions, and shadow copies of boot partitions, in accordance with embodiments of the inventive concept.

FIG. 3 is an example block and flow diagram illustrating a dynamic shadowing technique in accordance with embodiments of the inventive concept.

FIG. 4 is a flow diagram illustrating a technique for validating a boot image in accordance with embodiments of the inventive concept.

FIG. 5 is a flow diagram illustrating a technique for shadowing one or more boot images in accordance with embodiments of the inventive concept.

FIG. 6 is a continuation of the flow diagram ofFIG. 5, illustrating a technique for detecting a boot failure in accordance with embodiments of the inventive concept.

FIG. 7 is a block diagram of a computing system including the shadow control logic section ofFIG. 1.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the inventive concept, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to enable a thorough understanding of the inventive concept. It should be understood, however, that persons having ordinary skill in the art may practice the inventive concept without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first module could be termed a second module, and, similarly, a second module could be termed a first module, without departing from the scope of the inventive concept.

The terminology used in the description of the inventive concept herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the inventive concept. As used in the description of the inventive concept and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The components and features of the drawings are not necessarily drawn to scale.

Embodiments of the inventive concept include a technique for duplicating boot images to shadow partitions in a user area of a non-volatile memory device such as a flash memory. The technique can include detecting boot image corruption, and causing a mobile device to boot from the shadow partitions. The technique can include dynamically shadowing and releasing blocks used by the shadow partitions. The technique can include boot failure recovery and bad image preservation through firmware flash translation layer (FTL) logical to physical mapping updates. Boot image corruption failures can be recovered from and/or debugged using the shadow partitions.

FIG. 1 is an example block diagram of amobile device105 including a shadowcontrol logic section120 in accordance with embodiments of the inventive concept. Themobile device105 can include acode storage section110, ahost section125, and the shadowcontrol logic section120. Although the shadowcontrol logic section120 is shown to be separate from thecode storage section110, it will be understood that the shadowcontrol logic section120 may be a part of thecode storage section110. For example, the shadowcontrol logic section120 can be firmware, hardware, or a combination thereof, residing in or on thenon-volatile device155 and/or a central processing unit (CPU)135. Acode execution block115 shows anexample boot sequence190 of themobile device105. TheCPU135 can includeregisters130 and a CPU read-only memory (ROM)140. TheROM140 can be a non-volatile memory. TheCPU ROM140 can include aCPU boot loader 1image145 and aCPU boot loader 2image150. In other words, theCPU ROM140 can store one or more boot images in a section reserved for boot partitions.

Thecode storage section110 can include anon-volatile memory155. Thenon-volatile memory155 can be a flash memory, magnetoresistive random access memory (MRAM) modules, phase-change memory (PRAM) modules, resistive type memory modules, or the like. Thenon-volatile memory155 can store aboot loader image160 including a boot logical unit 0 (LU0) and/or a boot LU1. Thenon-volatile memory155 can include one ormore registers132. Thenon-volatile memory155 can include a replay protected memory block (RPMB)162. Thenon-volatile memory155 can include a section foruser LUs165. The section for user LUs can include shadowed boot images such as boot LU0 and/or boot LU1, as further described in detail below. Thenon-volatile memory155 can include an operating system (OS)kernel image170, system anduser data images175, or the like.

Thehost section125 can run host processes and applications. Thehost section125 can be communicatively coupled to thecode storage section110 and/or to the shadowcontrol logic section120. For example, thehost section125 can access and/or update one ormore registers130 and/or132. The shadowcontrol logic section120 can shadow one or more boot images (e.g.,CPU boot loader 1image145 and/orCPU boot loader 2 image150) to one or more shadowed boot images (e.g., boot LU0 and/or boot LU1) in the non-volatile memory (e.g.,155), as further described in detail below.

In aboot sequence190 of themobile device105, there is a certain code execution that can occur in a particular order, as shown in thecode execution115. For example, the booting can start from the CPU internal ROM code execution when power to themobile device105 is turned on. Then, the booting can proceed to the boot partitions/LUs of thenon-volatile component155. More specifically, theCPU boot loader 1image145 can be loaded into internal random access memory (IRAM) at 1, theCPU boot loader 2image150 can be loaded into IRAM and/or dynamic random access memory (DRAM) at 2, theboot loader image160 can be loaded into DRAM at 3, theOS kernel image170 can be loaded into DRAM at 4, and the system anduser data images175 can be loaded into DRAM at 5.

FIG. 2 is an example block diagram200 of boot partitions205 (sometimes referred to herein as “boot images”), user partitions215 (sometimes referred to herein as “user images”),RPMB210, andshadow copies225 of the boot images, in accordance with embodiments of the inventive concept. A boot LU shadowing routine (e.g.,220) may be periodically performed by the shadow control logic section (e.g.,120 ofFIG. 1). The shadowcontrol logic section120 can shadow the one ormore boot images205 to one or more shadowedboot images225, as further described in detail below.

Themobile device105 can normally boot from the one ormore boot images205 as shown byarrow237. In the event of corruption of the one ormore boot images205, themobile device105 can instead boot from the one or moreshadow boot images225 as shown byarrow239. The shadowcontrol logic section120 can detect corruption within the one ormore boot images205, the technique of which is further described in detail below. Responsive to such a detection of corruption, the shadowcontrol logic section120 can cause themobile device105 to boot from the one or more shadowedboot images225.

More specifically, a flash translation layer (FTL)230 can update one or more pointers among thephysical addresses235 from the one ormore boot images205, respectively, to the one or more shadowedboot images225. The host section (e.g.,125 ofFIG. 1) interfaces withlogical addresses240, and therefore, such FTL manipulation of thephysical addresses235 can be hidden from thehost section125. As such, the shadow copies225 can be invisible from thelogical space240 for data security purposes. Put differently, sinceshadow images225 are invisible to the host, they are protected from external access. Since theFTL230 can update the pointers to theshadow images225 upon the detection of boot failure, theoriginal boot images205 can become inaccessible to thehost section125, which operates in thelogical address space240. The one or more corruptedimages205 can therefore be preserved for subsequent root causing and/or debugging efforts.

FIG. 3 is an example block and flow diagram300 illustrating a dynamic shadowing technique in accordance with embodiments of the inventive concept. The shadow control logic section (e.g.,120 ofFIG. 1), can detect an amount ofavailable space305 within the section reserved for the user partitions215, and determine whether the amount ofavailable space305 is less than or equal to apredefined threshold310 as shown at325. When the determination is that the amount ofavailable space305 is less than or equal to thepredefined threshold310, the shadowcontrol logic section120 can cause the shadowboot image copies225 to be marked as invalid and designated for garbage collection, and the space occupied by the shadowboot image copies225 can be released to the section reserved for the user partitions215 as shown at330. As shown at330, while the amount ofavailable space315 is less than the amount ofavailable space305, the overall space available for the user partitions215 is increased. Thus, less impact to the usable density of the storage device for the user partitions is achieved.

When a determination is made that the amount ofavailable space320 is greater than thepredefined threshold310 as shown at335, then the shadowcontrol logic section120 can again cause space to be allocated within the section reserved for the user partitions215 for the one or more shadowedboot images225. For example, when the device becomes less full (e.g., providing five times more density than total boot partition/LU size), the shadowcontrol logic section120 can automatically reenter the shadowing routine to duplicate the boot partitions to the user area. In other words, blocks within the section of thenon-volatile memory155 reserved for user partitions215 can be dynamically released and reclaimed to accommodate the shadowing of the boot partitions.

FIG. 4 is a flow diagram400 illustrating a technique for validating a boot image in accordance with embodiments of the inventive concept. The technique begins at405 where the mobile device (e.g.,105 ofFIG. 1) is powered on. The host section (125 ofFIG. 1) can cause the boot partitions to be loaded with bootloader images from ROM (e.g.,145 and150 ofFIG. 1) and execute the primary boot loader images at410 after the system powers on. At415, thehost section125 can execute the bootloader from boot LUs (e.g., the one ormore boot images205 ofFIG. 2). The flow proceeds to420 where thehost section125 can fetch the OS kernel.

At425, when both the bootloader phase and the OS kernel fetching phase are successfully passed, thehost section125 can set the BOOT_SUCCESS register (e.g.,130 and/or132 ofFIG. 1) to a predefined value, such as 1, indicating that the boot images (e.g.,205) are constructed and proven good. The BOOT_SUCCESS register can be reset, for example, to a value of 0 at the time of powering on themobile device105. The BOOT_SUCCESS register can be accessed by the shadow control logic section (120 ofFIG. 1), as further describe below. It will be understood that the BOOT_SUCCESS register can be set to different or other suitable values to differentiate the two different states. It will also be understood that rather than a register, the BOOT_SUCCESS can be a variable stored in any suitable memory location. The BOOT_SUCCESS register allows the known good data in theboot images205 to be preserved in theshadow images225, as also further described below. The BOOT_SUCCESS register can indicate a validation of the images in the boot partitions, so that shadowcontrol logic section120 can start the shadowing process, if not completely shadowed already. At430, thehost section125 can execute the OS kernel.

FIG. 5 is a flow diagram500 illustrating a technique for shadowing one or more boot images in accordance with embodiments of the inventive concept. At505, the shadow routine can start. The shadow control logic section (120 ofFIG. 1) can cause the shadow routine to be periodically entered. If certain conditions are met, the shadow control logic section can cause the one or more boot partitions (e.g.,205 ofFIG. 2) to be shadowed to one or more shadow partitions (e.g.,225 ofFIG. 2) so that the boot partitions and the shadow partitions have the same images. The shadow routine can be entered when themobile device105 is in an idle mode or is otherwise substantially idle. In other words, the shadowing can include yielding to higher priority tasks while the shadowing occurs in the background.

At510, at about a start time of the shadow routine, a determination can be made whether or not a BOOT_FROM_SHADOW register (e.g.,130 and/or132 ofFIG. 1) is equal to a predefined value such as 1. The value can indicate that themobile device105 should boot from the one or more shadowedboot images225 or will boot from the one or more shadowedimages225, and in such case, the shadow routine is not continued and ends in a no-operation (NOP)515. The value of 0 can indicate that themobile device105 should not boot from the one or more shadowedboot images225, and in such case, the shadow routine can continue and the flow can proceed to520. It will be understood that the BOOT_FROM_SHADOW register can be set to different or other suitable values to differentiate the two different states. It will also be understood that rather than a register, the BOOT_FROM_SHADOW can be a variable stored in any suitable memory location.

At520, another determination can be made whether the BOOT_SUCCESS register (e.g., ofFIG. 4) indicates that the one or more boot images (e.g.,205 ofFIG. 2) are constructed or otherwise known to be good. If the BOOT_SUCCESS register is equal to 1, for example, then the routine can proceed to525. Otherwise, if the BOOT_SUCCESS register is equal to 0, meaning that themobile device105 did not successfully boot, then the routine can proceed to ‘A’ ofFIG. 6, as further described below.

At525, another determination can be made whether a hash check is equal. More specifically, the shadow control logic section (e.g.,120 ofFIG. 1) can compare a hash of the one ormore boot images205 with a hash of the one or more shadowedboot images225. Responsive to a match in the comparison of the first and second hashes, this indicates that the one or more shadowedboot images225 are equivalent to the one ormore boot images205, and the routine can end with aNOP530. In other words, if the routine ends with theNOP530, it means that the shadow images have already been constructed. Conversely, responsive to a mismatch in the comparison of the first and second hashes, the routine can continue to535 where a SHADOW_COMPLETE register can be set to a predefined value such as 0, meaning that the one or more shadowedimages225 are not yet complete copies of the one ormore boot images205. It will be understood that the SHADOW_COMPLETE register can be set to different or other suitable values to differentiate two different states. It will also be understood that rather than a register, the SHADOW_COMPLETE can be a variable stored in any suitable memory location.

The flow can proceed to540, where the one ormore boot images205 can be duplicated to the one or more shadowedboot images225 in the user area section reserved for user LUs. The duplication can be performed in an incremental manner so as to not impact the performance of themobile device105. At545, another determination can be made whether a hash check is equal. Such a determination can be the same or similar determination made with reference to525, and therefore, a detailed description is not repeated. If it is determined that the hash check is not equal, it is likely that the shadowing did not succeed and/or that the shadowed images are invalid and need to be reconstructed, and therefore, the flow can return to540 for additional duplication of the boot LUs to the user area. Otherwise, if it is determined that the hash check is equal, the flow proceeds to550, where the SHADOW_COMPLETE register is set to 1. This indicates that the shadowing process has completed. The host section (125 ofFIG. 1) can know the status (i.e., shadowed or not shadowed) by reading the SHADOW_COMPLETE status register. The hash codes of the one or more boot images can be stored and used for data comparison and error checking.

The shadow control logic section (120 ofFIG. 1) can allocate physical areas in the user partition as shadowing partitions. The total size of these areas can be equal to the total size of boot partitions (e.g., boot LUs). The shadowcontrol logic section120 can optionally configure the one or more shadowed boot images into single-level cell (SLC) mode for performance and reliability improvements. The shadowcontrol logic section120 can read data from the boot partitions and write the data to the shadowed boot images stored in the user partition during device idle time. The shadowcontrol logic section120 can keep track of the progress if the shadowing process is interrupted by a host command, which might bring themobile device105 out from the idle state. When themobile device105 enters the idle state again, the shadowcontrol logic section120 can resume the shadowing process until it is completed. Subsequently, the shadowcontrol logic section120 can perform the hash checking and set the SHADOW_COMPLETE register to 1 to indicate that the shadowing process is completed. The physical location of the blocks for shadow partitions need not be fixed. The shadowcontrol logic section120 can keep track of the physical locations of the blocks of the shadow partitions.

It will be understood that the steps illustrated inFIG. 5 need not occur in the illustrated order, but rather, can occur in a different order and/or with intervening steps.

FIG. 6 is a continuation flow diagram600 of the flow diagram500 ofFIG. 5, illustrating a technique for detecting a boot failure in accordance with embodiments of the inventive concept. During the booting process of themobile device105, the primary boot loaders (e.g.,145 and150 ofFIG. 1) in the CPU ROM (e.g.,140 ofFIG. 1) get executed first. The primary boot loaders can cause initialization command sequences to be sent to the non-volatile memory (e.g.,155 ofFIG. 1) through the host section (e.g.,125 ofFIG. 1). When the BOOT_SUCCESS register is set to 1, for example, the shadow control logic section (e.g.,120 ofFIG. 1) can assume that the boot images (e.g.,205 ofFIG. 2) in the boot partitions are good, and therefore, the boot images can be duplicated to the shadowed boot images in the dynamic shadowing process.

When the BOOT_SUCCESS register has a value of 0, for example, the shadowcontrol logic section120 can keep an INIT_CYCLE internal counter to keep track of the total number of host issued initialization requests. The INIT_CYCLE counter can be cleared to a value of 0 when the BOOT_SUCCESS register is changed from a value of 0 to a value of 1.

Responsive to determining that the BOOT_SUCCESS register indicates that the one or more boot images are not constructed (e.g., at520 ofFIG. 5), the shadow routine can proceed to605 ofFIG. 6, where theshadow control logic120 can count a number of initialization requests from thehost section125 of themobile device105. Theshadow control logic120 can determine whether the number of initialization requests exceeds a predefined threshold (e.g.,20).

If the number of initialization requests does not exceed the predefined threshold, the routine can end in aNOP610, meaning that the initialization cycle condition is not met, and thehost section125 needs to conduct more booting retries. On the other hand, responsive to determining that the number of initialization requests exceeds the predefine threshold, theshadow control logic120 can determine at615 whether the SHADOW_COMPLETE register indicates that the one or more boot images (e.g.,205 ofFIG. 2) are completely shadowed to the one or more shadowed boot images (e.g.,225 ofFIG. 2) at625.

If the SHADOW_COMPLETE register is not 1 (e.g., 0), then the routine can end in aNOP620, meaning that the shadowing process was not properly completed before themobile device105 failed to boot. Otherwise, responsive to determining that the second register indicates that the one or more boot images are completely shadowed to the one or more shadowed boot images (i.e., SHADOW_COMPLETE=1), the shadowcontrol logic section120 can compare a first hash of the one or more boot images (e.g.,205 ofFIG. 2) with a second hash of the one or more shadowed boot images (e.g.,225 ofFIG. 2).

In other words, when the shadowcontrol logic section120 determines that the total number of initialization requests from thehost section125 is larger than the predefined threshold (e.g., 20), the shadowcontrol logic section120 can conduct a hash checking process to compare the hash of the current boot partition images with the copied images in the shadow partitions. The period of such hash checking process can depend on an ‘X’ number setting, which can be programmable for or by thehost section125 through a hash checking period register on themobile device105. Themobile device105 can have a default value for the hash checking period of 20, for example.

If the shadowcontrol logic section120 finds at625 a hash code mismatch, which can mean boot partition (e.g., LU) image corruption, then the high number of host initialization retries can be root-caused to be boot image corruption. Such a failure can be detected automatically. The shadowcontrol logic section120 can cause the FTL (e.g.,230 ofFIG. 2) to update at635 the logical address pointers of the one or more boot partitions from the physical boot areas to the shadowed partitions, then set at640, the BOOT_FROM_SHADOW register to 1, for example, to notify thehost section125. The next boot will therefore boot from the one or more shadow partitions in the user area.

Thehost section125 can check the BOOT_FROM_SHADOW register in the OS after booting from the shadow partitions, and optionally display a message for the user informing the user of the action taken. Otherwise, if the shadowcontrol logic section120 finds at625 that the hash check is equal (i.e., that the hashes are equal), then the routine can end in theNOP630, meaning that although the booting failed, corruption was not necessarily found in the boot partitions since the hashes match.

Put differently, responsive to a mismatch at625 in the comparison of a hash of the one or more boot images with a hash of the one or more shadowed boot images, the shadowcontrol logic section120 can infer that the one or more boot images are corrupted. At635, the FTL can update one or more pointers from the one or more boot images, respectively, to the one or more shadowed boot images. At640, the shadowcontrol logic section120 can set the BOOT_FROM_SHADOW register to a predefined value such as 1, indicating that themobile device105 should boot from the one or more shadowed boot images.

It will be understood that the steps illustrated inFIG. 6 need not occur in the illustrated order, but rather, can occur in a different order and/or with intervening steps.

The following table 1 is provided to assist in the understanding of the various registers described herein.

TABLE 1

Register Name	Type	Type Description	Usage

BOOT_SUCCESS	R/W/CP	This register can be	Host section can set
		writeable after its value is	this register after
		cleared by a power failure	every successful
		and/or hardware reset. In	booting cycle. This
		some embodiments, this	register can be reset
		register is not cleared by a	automatically (e.g.,
		software reset. This register	by firmware) at
		can also be readable.	every device power
			on.
SHADOW_COMPLETE	R/W/E	This register can be multiple	This register can be a
		writable with its value kept	status register to
		after a power failure,	inform the host
		hardware reset, and/or any	section and/or the
		software reset. This register	device firmware of
		can also be readable.	the completion of the
			shadowing process.
BOOT_FROM_SHADOW	R/W/E	This register can be multiple	This register can be a
		writable with its value kept	status register to
		after a power failure,	inform the host
		hardware reset, and/or any	section and/or device
		software reset. This register	firmware that the
		can also be readable.	current and next boot
			will be from the one
			or more shadowed
			partitions.

FIG. 7 is a block diagram of acomputing system700 including the shadowcontrol logic section120 ofFIG. 1.

Referring toFIG. 7, thecomputing system700 may include aclock710, a random access memory (RAM)715, a user interface720, amodem725 such as a baseband chipset, a solid state drive/disk (SSD)740, amemory controller745, and/or aprocessor735, any or all of which may be electrically coupled to asystem bus705. The shadowcontrol logic section120 can correspond to that described in detail above, and as set forth herein, and may also be electrically coupled to thesystem bus705. The shadow control logic section730 can include or otherwise interface with theclock710, the random access memory (RAM)715, the user interface720, themodem725, the solid state drive/disk (SSD)740, thememory controller745, and/or theprocessor735.

Accordingly, when a “device-does-not-boot” issue is caused by boot code image corruption in the boot logical units (e.g., boot partitions), embodiments of the inventive concept can help the mobile device to recover from this failure. According to embodiments of the inventive concept, the firmware of a non-volatile memory (e.g., flash storage device) can automatically duplicate the contents of boot logical units (e.g., boot partitions) into the user logical units (e.g., user partition) through firmware internal data moving operations in the physical address space. The duplicated copies of the boot images can have the same hash data as the original images residing in the boot logical units. This hash data can be kept for error checking. The duplicated copies in the user partition can be called shadow partitions.

In the event of code corruption in the boot partitions, thereby causing the “device-does-not-boot” issue, the firmware can automatically detect the failure based on the number of continuous initialization retry requests issued by the host. Such retry threshold can be configurable by the host, and can have a default value. Once the failure detection criteria and threshold are met, the firmware FTL layer can automatically update the logical to physical address table of the boot partitions, pointing to the shadow partitions in the user area which contains the valid copies of the original boot code images.

Therefore, when the mobile device attempts to boot again, the boot code data can be fetched from the shadow partitions for the host. Since the host operates in the logical address space and the firmware FTL layer handles the pointer update internally in the non-volatile memory storage device, the underlying aspects of the inventive concept are relatively invisible to the host hardware and software. The failing conditions can be preserved for root causing and debugging purposes.

The various embodiments of the inventive concept disclosed herein can be implemented with minimal host software involvement. Variable sizes of the boot partitions/LUs can be supported, for example, as large as hundreds of megabytes or more. In some embodiments, the shadow control logic section can shadow the OS kernel if it is placed in the boot LU. There is little to no performance impact since incremental duplication can be performed in the background and/or during device idle times. Moreover, there is no density loss since the shadowing is dynamic and can be released when the device is full.

The following discussion is intended to provide a brief, general description of a suitable machine or machines in which certain aspects of the inventive concept can be implemented. Typically, the machine or machines include a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine or machines can be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.

The machine or machines can include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits (ASICs), embedded computers, smart cards, and the like. The machine or machines can utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines can be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication can utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth®, optical, infrared, cable, laser, etc.

Embodiments of the present inventive concept can be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data can be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data can be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in a compressed or encrypted format. Associated data can be used in a distributed environment, and stored locally and/or remotely for machine access.

Having described and illustrated the principles of the inventive concept with reference to illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles, and can be combined in any desired manner. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the inventive concept” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the inventive concept to particular embodiment configurations. As used herein, these terms can reference the same or different embodiments that are combinable into other embodiments.

Embodiments of the inventive concept may include a non-transitory machine-readable medium comprising instructions executable by one or more processors, the instructions comprising instructions to perform the elements of the inventive concepts as described herein.

The foregoing illustrative embodiments are not to be construed as limiting the inventive concept thereof. Although a few embodiments have been described, those skilled in the art will readily appreciate that many modifications are possible to those embodiments without materially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of this inventive concept as defined in the claims.