WO2008058101A2 - Contrôleurs de mémoire pour effectuer des mises à niveau de micrologiciel de façon résiliente dans une mémoire en fonctionnement - Google Patents

Contrôleurs de mémoire pour effectuer des mises à niveau de micrologiciel de façon résiliente dans une mémoire en fonctionnement Download PDF

Info

Publication number
WO2008058101A2
WO2008058101A2 PCT/US2007/083704 US2007083704W WO2008058101A2 WO 2008058101 A2 WO2008058101 A2 WO 2008058101A2 US 2007083704 W US2007083704 W US 2007083704W WO 2008058101 A2 WO2008058101 A2 WO 2008058101A2
Authority
WO
WIPO (PCT)
Prior art keywords
firmware
copy
upgrade
state
mode
Prior art date
Application number
PCT/US2007/083704
Other languages
English (en)
Other versions
WO2008058101A3 (fr
Inventor
Lee Merrill Gavens
Charles Michael Schroter
Shing Wong
Original Assignee
Sandisk Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/594,283 external-priority patent/US8286156B2/en
Priority claimed from US11/594,583 external-priority patent/US20080109647A1/en
Application filed by Sandisk Corporation filed Critical Sandisk Corporation
Publication of WO2008058101A2 publication Critical patent/WO2008058101A2/fr
Publication of WO2008058101A3 publication Critical patent/WO2008058101A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running

Definitions

  • This invention relates generally to non-volatile memory and removable memory devices, and more particularly, to a memory controller for upgrading firmware stored in a non-volatile memory, in phases, and restoring firmware in-situ to compensate for failed firmware upgrades.
  • the memory controller can upgrade and restore the firmware as the non-volatile memory remains functioning.
  • Removable memory devices such as flash memory cards
  • flash memory cards usually implement a file system for managing directories and files, including system files.
  • System files typically contain firmware (i.e., "flashware") instructions for initializing the flash memory card, and for interfacing a host electronic device with a memory space in a non- volatile memory.
  • firmware instructions are upgraded to correct "bugs" and other deficiencies.
  • firmware is frequently corrupted when the flash memory card is disconnected from its power and/or data source while new data is being written to it.
  • Encryption when used, exacerbates the corruption.
  • the corruption of the firmware is irreversible, which renders the flash memory card inoperable. The user has little choice but to ship the flash memory card back to the manufacturer (or some third party) to recover its functionality.
  • a drawback to restoring the firmware at the manufacturer is that the application data stored in the flash memory is usually erased during traditional firmware recovery processes.
  • a multi-mode memory controller includes a firmware selector for selecting a first copy of firmware for accessing in a functional mode, and for selecting a second copy of the firmware for upgrading in an upgrade mode. It also can include a phased upgrade controller being configured to access the first copy in the functional mode coincident or substantially coincident to replacing at least a portion of the second copy with at least a portion of an upgrade firmware in the upgrade mode.
  • FIG. 1 is a block diagram of an apparatus for upgrading firmware stored in a nonvolatile memory, in phases, as the non-volatile memory remains functioning, according to at least one embodiment of the invention
  • FIG. 2 is a flow diagram depicting one example of a method for facilitating the functionality of non- volatile memory during firmware upgrades, according to one embodiment of the invention
  • FIG. 3 is a block diagram of a multi-mode memory controller for upgrading firmware in phases, according to at least one embodiment of the invention
  • FIG. 4 is a flow diagram depicting an example of a method for facilitating the functionality of non- volatile memory during firmware upgrades, according to one embodiment of the invention
  • FIG. 5 is a state diagram depicting the states of an upgrade mode during which firmware can be recovered as a function of the states, according to one embodiment of the invention
  • FIG. 6 is a block diagram of a removable memory device that provides for phased firmware upgrades, according to at least one embodiment of the invention.
  • FIG. 7 is a block diagram of a system including a host and a removable memory card for performing phased firmware upgrades in multiple modes of operation, according to at least one embodiment of the invention.
  • FIG. 1 is a block diagram of an apparatus for upgrading firmware stored in a non- volatile memory, in phases, as a non- volatile memory remains functioning, according to at least one embodiment of the invention.
  • apparatus 100 includes a multi-mode memory controller 110, a phased upgrade controller 120 and a non- volatile memory 130, which includes memory locations for a first copy ("primary copy") 140 of firmware, a second copy ("secondary copy") 142 of firmware, and application data 144 stored for an electronic device (not shown).
  • Multi-mode memory controller 110 is configured to implement an upgrade mode for upgrading firmware in non- volatile memory 130 coincident to, or substantially coincident to, a functional mode during which non-volatile memory 130 functions as a memory store.
  • multi-mode memory controller 110 in whole or in part — can be configured to read data 122 from, and write data 124 to, first copy 140 and/or application data 144 during the functional mode, while multi-mode memory controller 110 replaces at least a portion of second copy 142 with upgraded firmware ("new firmware") 126 during the upgrade mode.
  • non- volatile memory 130 can have a portion 150 of its memory locations functioning as storage in parallel with firmware upgrades to other memory locations in another portion 152.
  • concurrent upgrade and functional modes serve to shield the functionality of non- volatile memory 130 (along with its application) from inefficiencies in performing firmware upgrades in series with implementing non- volatile memory 130 as a memory store.
  • multi-mode memory controller 110 can operate first copy 140 of firmware and application data 144 as a memory store in the functional mode, while restoring the firmware in second copy 142 during a recovery mode.
  • concurrent functional and recovery modes serve to isolate the functionality of non-volatile memory 130 from an interruption, such as a power disruption, during the upgrading of firmware.
  • multi-mode memory controller 110 can be configured to recover firmware in-situ, without removing non- volatile memory 130 from its implementation in apparatus 100 or with an electronic host device (not shown).
  • Phased upgrade controller 120 in whole or in part — can be configured to guide an upgrade mode of operation through a progression of states. Should a disruptive event halt the upgrade mode, phased upgrade controller 120 can continue upgrading the firmware by progressing through a remaining number of states of the upgrade mode. For example, phased upgrade controller 120 can detect a state in which a disruptive event halted a previous upgrade mode, and then resume the firmware upgrade at or near the state at which the disruptive event occurred. As such, phased upgrade controller 120 can omit previously completed states to preserve computational resources of multi-mode memory controller 110 that otherwise would be consumed in repeating states that were successfully completed in the previous upgrade mode.
  • Phased upgrade controller 120 can be further configured to merge at least one portion of the original firmware from either first firmware copy 140 or second firmware copy 142 with upgraded firmware 126 to form at least a portion of an upgraded copy in second copy 142 of firmware.
  • phased upgrade controller 120 is configured to copy a portion ("P") 160 of firmware to another portion ("P") 162 of firmware.
  • phased upgrade controller 120 can reuse old firmware (or portions thereof) to preserve it through multiple upgrade modes.
  • An example of firmware and/or system files that should be preserved is parametric data (e.g., clock trim values) that are initially programmed by the manufacturer and cannot readily be determined independent from the original firmware.
  • multi-mode refers to a characteristic of a memory controller or a process that can perform non-volatile memory operations in multiple modes simultaneously or nearly simultaneously.
  • a multi- mode memory controller can implement two or more of the following substantially in parallel: a functional memory mode, an upgrade mode and a recovery mode.
  • phased upgrade at least in one embodiment, refers to any controller or mode that facilitates firmware upgrades in phases.
  • phase at least in some embodiments, can be used interchangeably with the term "state.” In one embodiment, a single state can form an entire copy of upgraded firmware, with other states reserved for validating the new firmware, and other like operations.
  • the term "disruptive event,” at least in one embodiment, refers to either an unintentional or intentional interruption to a firmware upgrade process. Examples of unintentional disruptive events include power losses, transient-related errors that corrupt data integrity, and the like. Examples of intentional disruptive events include power cycling (e.g., turning power off and on), resetting and/or rebooting a memory controller, and the like.
  • the term "functional mode,” at least in one embodiment, refers to an ability of a non- volatile memory to perform a function (e.g., a data storage function) for which the memory is implemented. During a functional mode, a memory controller, for example, can access firmware and/or application data to facilitate the functionality of the memory.
  • apparatus 100 can execute one or more instructions as well as access data stored in either first copy 140 or application data 144 during a functional mode.
  • the term "upgrade mode,” at least in one embodiment, refers to an ability of a non-volatile memory to update executable firmware instructions that provide enhancements over an earlier version.
  • a non-volatile memory can be selectably upgraded.
  • current executable firmware instructions can be merged with new executable firmware instructions to form upgraded firmware.
  • an upgrade mode is performed in phases, or in a number of states, such that a memory controller can resume a firmware upgrade at a state at which a disruptive event had occurred, thereby omitting at least one state that preceded the disruptive event.
  • the term "recovery mode,” at least in one embodiment, refers to an ability of a non-volatile memory to restore firmware to a fail-tolerant state, such as by recovering a redundant copy of firmware subsequent to an aborted upgrade mode.
  • a recovery mode is implemented as an "in-situ" recovery mode, whereby a memory controller can restore firmware in a non-volatile memory to obtain fail-safe operation during operation in conjunction with a host device, as an example.
  • the upgrade mode and the recovery mode generally occur “in the background,” such that the functionality of non- volatile memory can continue unimpeded, or substantially so.
  • the functional mode can take precedence over either the upgrading or recovering firmware.
  • first copy (“primary copy”) 140 of firmware is used to provide functionality to non- volatile memory 130
  • second copy (“secondary copy”) 142 of firmware is used as a redundant firmware that serves as a back-up copy of firmware should first copy 140 become corrupt or otherwise unusable.
  • first copy 140 and second copy 142 generally include the same firmware data and/or instructions in modes other than the upgrade mode.
  • first copy 140 of firmware or second copy 142 of firmware can be the initial copy subject for a firmware upgrade, with the other copy being upgraded subsequently.
  • firmware at least in one embodiment, refers to executable instructions and/or data used to facility functionality of a removable memory card and/or non- volatile memory as a data store.
  • firmware can be used to implement system files.
  • the one or more of the elements described in FIG. 1 (as well as the elements described subsequent to FIG. 1) can be implemented in either software (firmware) or hardware, or both.
  • the elements and their functionality described in FIG. 1 (and in other figures) can be aggregated with one or more other elements, or, alternatively, the elements and their functionality can be subdivided into constituent sub- elements, if any.
  • FIG. 2 is a flow diagram depicting one example of a method for facilitating the functionality of non- volatile memory during firmware upgrades, according to one embodiment of the invention.
  • flow 200 begins at 202, at which a memory controller, for example, can operate multiple modes of operation in parallel.
  • flow 200 includes two parallel flows: a sub-flow 210 depicting a functional mode and a sub-flow 240 depicting an upgrade mode.
  • Sub-flow 210 and sub-flow 240 begin by respectively selecting a first set of firmware instructions (or memory locations) for execution at 220, such as those instructions and/or data in a primary firmware copy, and a second set of firmware instructions (or memory locations) for upgrading at 250, such as those instructions and/or data in a secondary firmware copy.
  • Sub-flow 210 continues to 222 at which a multi-mode memory controller, for example, executes one or more instructions from the first set of firmware instructions.
  • the multi-mode memory controller can also execute instructions from memory locations containing applications data in a user address space. Further, the controller can write and/or read data from those memory locations of either the user address space or the first firmware copy.
  • Sub-flow 210 continues to access the first set of firmware instructions during the functional mode so long as, for example, a phased upgrade controller designates the first set for execution at 224.
  • Sub-flow 240 continues in parallel, or substantially in parallel, to the execution of the first set of firmware instructions to upgrade the second set of firmware instructions.
  • sub-flow 240 imports upgrade data at 252 from, for example, a host electronic device that is configured to obtain new firmware, and maintains at least some of the original firmware instructions and/or data at 254.
  • sub-flow 240 merges the imported upgrade data (i.e., portions of the new firmware) with the current firmware (i.e., portions of the old firmware) to form an upgrade copy of firmware as the second set of firmware instructions.
  • sub-flow 240 validates the upgrade firmware at 260 to confirm that the firmware upgrade has been successful. If successful, a multi-mode memory controller swaps designations for the first and second sets of firmware instructions.
  • the second set is selected for execution at 226 for participation in sub-flow 210
  • the first set is selected for upgrading at 262 in sub- flow 240.
  • sub-flow 240 terminates at 264 and sub- flow 210 selects the upgraded first set — as a primary copy — for execution at 228 for a normal state of operation.
  • the upgraded second set is available as a redundant, "secondary copy" to ensure fail-safe operation.
  • FIG. 3 is a block diagram of a multi-mode memory controller for upgrading firmware in phases, according to at least one embodiment of the invention.
  • a multi-mode memory controller 300 can include a phased upgrade controller 310 and one or more of the following: a firmware selector 320, an error log manager 330, a multiple-path recovery module 340, and a format converter 350.
  • Multi-mode memory controller 300 is configured to exchange inbound/outbound (“IB/OB") data 302 via a command/data stream with, for example, a host (not shown).
  • IB/OB inbound/outbound
  • Inbound/outbound data 302 can include commands, instructions, and data, which include application data.
  • the host can send inbound/outbound data 302 as host commands to multi-mode memory controller 300 for initiating and completing the upgrade mode, according to one embodiment.
  • the host can also send new firmware as inbound/outbound data 302 for writing into a non- volatile memory (not shown).
  • Inbound/outbound data 302 can also include application data (e.g., image data for a digital camera application) that is to be written into or read from the non-volatile memory, or, alternatively, inbound/outbound data 302 can include instructions for execution by either a processor (not shown) in the host or by multi-mode memory controller 300.
  • Firmware selector 320 is configured to select one of two copies of firmware for upgrading in an upgrade mode, and to select the other copy of the firmware for accessing during a functional mode. Phased upgrade controller 310 and firmware selector 320 cooperate to select memory locations of primary firmware copy 322 and secondary firmware copy 324 as a function of a state of the upgrade mode. In some cases, primary firmware copy 322 operates according to a functional mode and secondary firmware copy 324 operates according to an upgrade mode, or vice versa. According to one embodiment, firmware selector 320 is configured to select one of any number of copies of firmware for upgrading and at least one other copy from the remaining number of copies for supporting a functional mode. Firmware selector 320 can copy portions of firmware from any firmware copy to any firmware copy.
  • firmware selector 320 can also perform a multiplexer-like function in that it can route instructions and/or application data between the host and primary firmware copy 322 during a functional mode, and it can route write data as new firmware to secondary firmware copy 324 in an upgrade mode. Note that firmware selector 320 can route data to and from both copies 322 and 324 simultaneously, or nearly simultaneously, regardless of their specific modes of operation.
  • Phased upgrade controller 310 is configured to identify a state of the firmware upgrade in which a disruptive event occurred in a previously performed upgrade process, and to resume the firmware upgrade where it left off.
  • An error log 332 is configured as a repository to store state information, including an indicator of the state.
  • error log refers to a repository for storing state information.
  • State information can include, for example, identifiers that indicate the last successfully completed phase of an upgrade mode so that a memory controller can resiliently continue the upgrade mode should there be an intervening disruptive event.
  • the error log can be stored in a specific block in flash memory or in a separate memory.
  • An error log manager 330 is configured to store and/or retrieve state information for phased upgrade controller 310.
  • error log manager 330 stores an indicator representing a present state (or phase) of the upgrade mode when a firmware copy is being upgraded. Accordingly, if the upgrade processes is interrupted by a disruptive event, phased upgrade controller 310 can detect the last state (or phase) that was successfully completed before the disruptive event intervened. Then, the upgrade process can continue without repeating successfully completed states.
  • error log manager 330 conveys the state information from error log 332 to phased upgrade controller 310 during the booting- up of multi-mode memory controller 300, which, in turn, determines a course of action as a function of the stored state information. For example, phased upgrade controller 310 and error log manager 330 can cooperate to determine that a firmware upgrade is associated with a state indicative of either a complete (e.g., successful) firmware upgrade or an incomplete (e.g., unsuccessful) firmware upgrade.
  • Multiple-path recovery module 340 is configured to perform in-situ recovery, in whole or in part, in association with a set of locations of a firmware copy (e.g., secondary firmware copy 324) in response to a disruptive event.
  • the firmware copy undergoing an upgrade is a redundant copy of firmware.
  • the redundant copy is erased in preparation for being written with new and old firmware to form an upgraded copy of firmware.
  • the disruptive event interrupts the upgrade process, thereby leaving one known good firmware copy from which to reboot. But a single copy can fail to provide sufficient fault tolerance in some cases. Consequently, multiple-path recovery module 340 is configured to restore firmware to a fail-tolerant state, such as by recovering the redundant copy of firmware.
  • multiple-path recovery module 340 can perform firmware recovery substantially in parallel to the execution of firmware instructions in another firmware copy.
  • multiple-path recovery module 340 implements at least two paths (i.e., multiple paths) to firmware recovery, the selection of a path being a function of a state of the upgrade process. If multiple-path recovery module 340 determines that a state is associated with a first subset of states, then a first path to recovery is taken, whereas if the state is associated with a second subset of states, then a second path to recovery is taken. A disruptive event occurring in a state from either the first subset or second subset can result in storing a state indicative of an incomplete firmware upgrade.
  • the first subset of states includes both an "only old” state and a "try new” state
  • the second subset of states includes an "only new” state.
  • secondary firmware copy 324 is erased in preparation for writing an upgrade to the firmware. If a disruptive event occurs during those states, secondary firmware copy 324 is unavailable for redundancy purposes.
  • multiple-path recovery module 340 takes the first path and recovers the firmware in secondary firmware copy 324 by copying primary firmware copy 322 into memory locations for secondary firmware copy 324.
  • primary firmware copy 322 is erased in preparation for writing an upgrade to the firmware.
  • multiple-path recovery module 340 takes the second path and recovers the firmware in primary firmware copy 322 by copying secondary firmware copy 324 into memory locations for primary firmware copy 322.
  • Format converter 350 can be configured to convert data representing at least a portion of firmware from an old file map format to a new file map format.
  • a "file map” is file that provides a mapping between files and locations (or sectors) in a non-volatile memory, including flash memory.
  • the file map includes a file name (i.e., file ID), the size of the file, the location, and other data for locating the file.
  • file ID i.e., file ID
  • file map is modified to, for example, express a different way to locate a file, then the old firmware files in an old file map format should be converted to a new file map format.
  • old firmware is merged with new firmware to form an upgraded firmware copy.
  • the new firmware includes a new file map format.
  • firmware having an old file map format is copied out of, for example, primary firmware copy 322.
  • format converter 350 converts the firmware having the old file map format into the same firmware having the new file map format.
  • the old firmware in the new file map format is merged with the new firmware, thereby forming an upgraded firmware copy in a new file map format, for example, in secondary firmware copy 324.
  • FIG. 4 is a flow diagram depicting an example of a method for facilitating the functionality of non- volatile memory during firmware upgrades, according to one embodiment of the invention.
  • flow 400 begins at 402, at which a memory controller, for example, can operate to reboot from a disruptive event, regardless of whether a prior firmware upgrade was intentionally or unintentionally interrupted.
  • the memory controller can determine the upgrade state at 404, for example, by accessing an error log to determine whether the non- volatile memory is in a normal state at 410, an upgrade secondary state at 430, a validation state at 450, or an upgrade primary state at 470. If the memory controller is rebooting subsequent to a normal state of operation, then the memory controller will continue to execute a set of firmware instructions and/or data from, for example, a primary firmware copy at 412.
  • the memory controller enters into an "upgrade secondary state" at 430 by storing an indicator "old only” as the state at 432.
  • the "old only” state indicates the old firmware (e.g., the primary firmware copy) is available from which to boot since the redundant copy (e.g., the secondary firmware copy) will be erased at 434.
  • the memory controller selectably copies portions of the old firmware from the primary ("P") into the secondary ("S") firmware locations at 436. If a new file map exists at 440 for the new firmware, then the portions of the old firmware are converted into the new file map format at 442. New firmware is written as upgrade data into other portions of the secondary firmware locations at 438.
  • the new and old firmware are merged together at 444 to form a copy of upgraded firmware.
  • the upgraded firmware is validated at 446 to determine whether the firmware had been successfully upgraded. Note that if the memory controller determines that the error log contains an indicator representing an "upgrade secondary state" upon reboot, then the memory controller had previously begun an upgrade mode that was likely interrupted during this state. According to one embodiment, the memory controller can enter a recovery mode to restore the second firmware copy. In another embodiment, the above-described actions relating to the "old only” can be repeated until the "try new" state is reached, thereby continuing onward to complete the upgrade mode, albeit without redundancy.
  • Flow 400 continues at 450. If the memory controller determines that it is entering a validation state 450, then it stores an indicator "try new" as the state at 452. The "try new" state indicates that the upgrade firmware has been successfully written into the secondary firmware copy. Next, the memory controller reboots using the upgraded firmware (i.e., the upgraded secondary firmware copy) to validate the upgraded firmware at 454. If the firmware upgrade does not pass at 456, then the memory controller enters a recovery mode 458 to replace the invalid upgraded firmware with a copy of the primary firmware copy. Note that if the memory controller determines that the error log contains an indicator representing a "validation state" upon reboot, then the memory controller had previously begun an upgrade mode that might have been interrupted during this state, thereby leaving the upgraded firmware yet to be validated.
  • the memory controller determines that the error log contains an indicator representing a "validation state" upon reboot, then the memory controller had previously begun an upgrade mode that might have been interrupted during this state, thereby leaving the upgraded firmware yet to be validated.
  • the memory controller can enter recovery mode 458 to restore the second firmware copy if a disruptive event occurs.
  • the above-described actions relating to the "try new” can be repeated until the "new only” state is reached, thereby continuing onward to complete the upgrade mode.
  • flow 400 continues at 470, where the primary firmware copy undergoes an upgrade. If the memory controller determines that it is entering an "upgrade primary state" at 470, then it stores an indicator "new only” as the state at 472. The "new only” state indicates that the firmware upgrade has been successful for the secondary firmware copy, and that the primary firmware copy is to be upgraded next. But until the primary firmware copy is successfully upgraded, the new firmware is available from which to boot as the primary firmware copy is erased at 474. Then, the memory controller copies the upgraded secondary firmware copy into the primary firmware copy at 476. At 478, both firmware copies have been upgraded and the error log is reset to a normal state, thereby concluding the upgrade mode at 480.
  • the memory controller determines that the error log contains an indicator representing an "upgrade primary state" upon reboot, then the memory controller had previously begun an upgrade mode that might have been interrupted during this state.
  • the memory can take courses of actions as similarly described with respect to the other states.
  • any of a multiple number of firmware copies that include one or more current firmware copies and one or more new firmware copies can be used during the "old only" state and the "new only” state, respectively.
  • FIG. 5 is a state diagram depicting the states of an upgrade mode during which firmware can be recovered as a function of the states, according to one embodiment of the invention.
  • a memory controller can perform firmware upgrades to a flash memory in accordance with state diagram 500.
  • the memory controller initially operates in a normal state ("Sl") at 510. It awaits an upgrade command at 502, from a host electronic device (not shown). If there is a disruption (i.e., a disruptive event), unintentional or otherwise, the memory controller keeps waiting for the upgrade command. Once it receives that command, the error log manager stores a state identifier (e.g., "S2”) in the error log to indicate that the "old only" state at 520 is underway.
  • Sl normal state
  • S2 state identifier
  • the target firmware e.g., the secondary firmware copy
  • the memory controller can boot up using the "old only” (i.e., current firmware from one or more copies) to enter a multiple-path recovery mode of operation at 560.
  • the memory controller takes a first path to recovery ("fall back") at 562 to write the primary firmware copy into the erased locations of the secondary firmware copy, thereby restoring redundancy. Note that the recovery can occur in parallel to the memory controller operating in a normal state at 510 (i.e., in a functional mode).
  • the memory controller continues to the next state of the upgrade mode, which is the "try new" state ("S3") at 530 during which the error log manager stores the state identifier.
  • S3 the "try new” state
  • the new firmware has been successfully written into the memory locations of the second firmware copy.
  • the upgraded firmware has not yet been validated to confirm its operability.
  • an unintentional disruptive event e.g., a loss of power
  • the memory controller cannot yet boot up using the new firmware as it has yet to be validated. As such, the memory controller takes the first path to recovery (“fall back") at 562 to restore a redundant copy for fault-tolerant operation.
  • the memory controller will continue the upgrade process by resetting itself or by interrupting the power supply (i.e., perform a power cycle) to use the upgraded firmware at 532 upon reboot for validating the upgrade.
  • the upgraded firmware is validated when the memory controller executes the upgraded firmware and moves to the next state, indicating that the upgraded firmware is operable.
  • the upgraded firmware is validated by comparing error correction codes ("ECCs") as well as using other error detection techniques known in the art.
  • ECCs error correction codes
  • the memory controller continues to the next state of the upgrade mode, which is the "new in progress" state ("S4") at 540 during which validation takes place for the new firmware.
  • the error log manager stores the state identifier in the error log when the memory controller boots up to, for example, avoid rebooting into an infinite loop of perpetually using the new firmware for validation purposes.
  • the memory controller equates a faulty firmware upgrade as an unintentional disruptive event. So, if firmware upgrade is invalidated during this state (or if an unintentional disruptive event occurs), the memory controller again takes the first path to recovery ("fall back") at 562 to restore a redundant copy with a known good copy of firmware (i.e., the primary copy).
  • the memory controller does not enter multiple-path recovery mode at 560 using the primary firmware copy. As such, the memory controller takes the second path to recovery ("go forward") at 564 to restore the primary copy with a redundant copy. Note that if the firmware upgrade of the primary copy is faulty at 550, then the memory controller can also take the second path to recovery. In one embodiment, the memory controller can optionally reboot using the new firmware in the primary copy to validate the new firmware. If the firmware upgrade to the primary copy is invalidated, then the memory controller can again take the second path of recovery at 564.
  • a state indicator can be stored either at the beginning, the end, or any time during a state.
  • the "old only” state can be referred to as the "use old” state
  • the "try new” state can be referred to as the "installing new” state
  • the "new in progress” state can be referred to as the "validation” state
  • the "new only” state can be referred to as the "use new” state.
  • the terms "use old” and “use new” are not limited to only old and only new, respectively.
  • removable memory device 600 is a flash memory card that includes a memory controller 610 and a flash memory 650.
  • Memory controller 610 includes a processor 614 that provides much of the functionality of the flash memory card, as well as some aspects of the various embodiments of the invention. Processor 614 can also perform wear-leveling and error correction for flash memory 650.
  • Memory controller 610 also includes a non- volatile memory (“boot ROM code”) 616 for storing a boot ROM code and another memory (e.g., "RAM”) 620 for storing a boot loader code.
  • the code stored in memories 616 and 620 can collectively constitute initialization instructions.
  • processor 614 executes code in memory 616 to load boot loader code ("boot loader”) 656 from either primary copy 652 or secondary copy 654 to a boot loader memory space (“BLR") 622 in memory 620.
  • processor 614 is configured to execute the boot ROM code from memory 616 to determine which firmware copy is designated for modifying its system files. It is at or near the execution of the boot ROM code (i.e., the boot-up mode) that processor 614 accesses an error log 670 to determine the state of an upgrade mode operation, and, thus determines whether to boot-up using system files 690 from either primary firmware copy 652 or secondary firmware copy 654.
  • Memory controller 610 also includes: a host interface (“I/F") 612 for exchanging data and commands with a host, a memory interface (“I/F”) 630 for accessing files stored in a number of sectors of flash memory 650, a transfer buffer (“TRF”) 624 for temporarily storing, for example, new firmware that is sent down from host for upgrading a copy of firmware, and a clock (“elk”) 640 for controlling the timing of the elements in memory controller 610.
  • I/F host interface
  • I/F memory interface
  • TRF transfer buffer
  • elk clock
  • Note that the behavior of clock 640 is governed, at least in part, by clock trim values stored as parameters 660 in flash memory 650.
  • system files 690 include a phased upgrade controller module, an error log manager module, a firmware selector module, a multi-path recovery module, and a format converter module, each of which can include executable instructions that, when executed by processor 614, performs the various functions described herein.
  • these modules can be implemented in hardware (e.g., circuitry) or software, or the combination thereof.
  • FIG. 7 is a block diagram of a system including a host and a removable memory card for performing phased firmware upgrades in multiple modes of operation, according to at least one embodiment of the invention.
  • host 710 can be any electronic device capable of using removable memory card 730 as storage and receiving a downloaded ("d/1") upgrade data stream 702 from a remote source, which can be the manufacturer of the removable memory card 730.
  • host 710 is electrically coupled to removable memory card 730 via a connector 720.
  • Host 710 includes an upgrade manager 712 and a transceiver (“TX/RX”) 714.
  • Removable memory card 730 includes a front end unit 732 configured to, among other things, decrypt the data and command streams from host 710, and a back end unit 734 including a phased upgrade controller 736.
  • Back end unit 734 operates as a multi-mode memory controller in some embodiments. As such, back end unit 734 can access flash memory 740 and its constituent elements that include primary system files (“syst files”) 742, secondary system files (“syst files”) 744, and user data space 746.
  • upgrade manager 712 is configured to issue commands and relay new firmware (from upgrade data stream 702) via transceiver 714 to removable memory card 730.
  • upgrade manager 712 can issue a command to phased upgrade controller 736, for example, to initiate a phased firmware upgrade.
  • upgrade manager 712 can issue another command to conclude the phased firmware upgrade.
  • Transceiver (“TX/RX") 714 operates to send commands and new firmware to removable memory card 730 during an upgrade mode, and operates further to provide host 710 access to user data space 746 during a functional mode.
  • either host 710 or removable memory card 730, or both can each operate concurrently in a functional mode and an upgrade mode, for example.
  • removable memory card 730 can be a flash memory card of any kind using any type of flash memory.
  • flash memory include NOR, AND, Divided bit-line NOR (DINOR), Not AND (NAND), and other flash memories.
  • host 710 can be any electronic device that implements non- volatile memory, such as flash memory 746. Examples of such electronic devices include removable memory devices, such as flash memory cards, universal serial bus (“USB”) flash drives, and the like. The electronic devices implement flash memories for a variety of applications, including digital cameras, MP3 music players, handheld computing devices, cellular phones, and other electronic devices requiring removable storage.
  • flash memory cards examples include a variety of the following trademarked products Secure DigitalTM (compliant with specifications maintained by the SD Card Association of San Ramon, California), MultiMediaCardTM (compliant with specifications maintained by the MultiMediaCard Association (“MMCA”) of Palo Alto, California), MiniSDTM (as manufactured by SanDisk, Inc.), MicroSDTM (as manufactured by SanDisk, Inc.), CompactFlashTM (compliant with specifications maintained by the CompactFlash Association (“CFA”) of Palo Alto, California), SmartMediaTM (compliant with specifications maintained by the Solid State Floppy Disk Card (“SSFDC”) Forum of Yokohama, Japan), xD-Picture CardTM (compliant with specifications maintained by the xD-Picture Card Licensing Office of Tokyo, Japan ), Memory StickTM (compliant with specifications maintained by the Solid State Floppy Disk Card (“SSFDC”) Forum of Yokohama, Japan), TransFlashTM (as manufactured by SanDisk, Inc.), and other flash memory cards.
  • Secure DigitalTM

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

L'invention concerne un appareil, un contrôleur de mémoire et un système pour mettre à niveau un micrologiciel stocké dans une mémoire non volatile, par phases, et restaurer le micrologiciel in situ pour compenser des échecs de mise à niveau de micrologiciel. Dans divers modes de réalisation, cet appareil, ce contrôleur de mémoire et ce système peuvent mettre à niveau et restaurer le micrologiciel tandis que la mémoire non volatile reste en fonctionnement. Dans un mode de réalisation, un contrôleur de mémoire multimode comprend un sélecteur de micrologiciel destiné à sélectionner une première copie d'un micrologiciel pour un accès dans un mode fonctionnel et à sélectionner une seconde copie du micrologiciel pour une mise à niveau dans un mode de mise à niveau. Ce contrôleur de mémoire multimode peut également comprendre un contrôleur de mise à niveau par phases conçu pour accéder à la première copie en mode fonctionnel simultanément ou sensiblement simultanément au remplacement d'au moins une partie de la seconde copie par au moins une partie d'un micrologiciel de mise à niveau en mode de mise à niveau.
PCT/US2007/083704 2006-11-07 2007-11-06 Contrôleurs de mémoire pour effectuer des mises à niveau de micrologiciel de façon résiliente dans une mémoire en fonctionnement WO2008058101A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/594,283 US8286156B2 (en) 2006-11-07 2006-11-07 Methods and apparatus for performing resilient firmware upgrades to a functioning memory
US11/594,283 2006-11-07
US11/594,583 2006-11-07
US11/594,583 US20080109647A1 (en) 2006-11-07 2006-11-07 Memory controllers for performing resilient firmware upgrades to a functioning memory

Publications (2)

Publication Number Publication Date
WO2008058101A2 true WO2008058101A2 (fr) 2008-05-15
WO2008058101A3 WO2008058101A3 (fr) 2009-01-08

Family

ID=39370981

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/083704 WO2008058101A2 (fr) 2006-11-07 2007-11-06 Contrôleurs de mémoire pour effectuer des mises à niveau de micrologiciel de façon résiliente dans une mémoire en fonctionnement

Country Status (2)

Country Link
TW (1) TWI363297B (fr)
WO (1) WO2008058101A2 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101782854A (zh) * 2009-01-19 2010-07-21 英业达股份有限公司 用于选择只读存储器模块间的沟通方法及系统
EP2214101A1 (fr) 2009-01-29 2010-08-04 Siemens Aktiengesellschaft Modification d'objets sur une application
US8286156B2 (en) 2006-11-07 2012-10-09 Sandisk Technologies Inc. Methods and apparatus for performing resilient firmware upgrades to a functioning memory
EP2508990A1 (fr) * 2011-04-04 2012-10-10 Fujitsu Limited Procédé de remplacement d'hyperviseur et dispositif de traitement d'informations
US9116774B2 (en) 2013-05-14 2015-08-25 Sandisk Technologies Inc. Firmware updates for multiple product configurations
CN108170368A (zh) * 2016-12-07 2018-06-15 北京忆恒创源科技有限公司 在线升级固件的方法及系统
IT201800000580A1 (it) * 2018-01-05 2019-07-05 St Microelectronics Srl Metodo di aggiornamento in tempo reale di una memoria differenziale con accessibilita' continua in lettura, memoria differenziale e sistema elettronico
US10811093B2 (en) 2018-01-05 2020-10-20 Stmicroelectronics S.R.L. Method of real-time access to a differential memory, differential memory and electronic system
US11256442B2 (en) 2018-01-05 2022-02-22 Stmicroelectronics S.R.L. Real-time update method for a differential memory, differential memory and electronic system

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8069345B2 (en) * 2008-10-29 2011-11-29 Netapp, Inc. Methods and systems for recovering a computer system using boot volume data from a storage area network

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5600807A (en) * 1990-03-19 1997-02-04 Hitachi, Ltd. Programmable controller capable of updating a user program during operation by switching between user program memories
US5826075A (en) * 1991-10-16 1998-10-20 International Business Machines Corporation Automated programmable fireware store for a personal computer system
US20020092008A1 (en) * 2000-11-30 2002-07-11 Ibm Corporation Method and apparatus for updating new versions of firmware in the background
US20060070058A1 (en) * 2004-09-27 2006-03-30 Corrigent Systems Ltd. Synchronized ring software download

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5600807A (en) * 1990-03-19 1997-02-04 Hitachi, Ltd. Programmable controller capable of updating a user program during operation by switching between user program memories
US5826075A (en) * 1991-10-16 1998-10-20 International Business Machines Corporation Automated programmable fireware store for a personal computer system
US20020092008A1 (en) * 2000-11-30 2002-07-11 Ibm Corporation Method and apparatus for updating new versions of firmware in the background
US20060070058A1 (en) * 2004-09-27 2006-03-30 Corrigent Systems Ltd. Synchronized ring software download

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8286156B2 (en) 2006-11-07 2012-10-09 Sandisk Technologies Inc. Methods and apparatus for performing resilient firmware upgrades to a functioning memory
CN101782854A (zh) * 2009-01-19 2010-07-21 英业达股份有限公司 用于选择只读存储器模块间的沟通方法及系统
EP2214101A1 (fr) 2009-01-29 2010-08-04 Siemens Aktiengesellschaft Modification d'objets sur une application
EP2508990A1 (fr) * 2011-04-04 2012-10-10 Fujitsu Limited Procédé de remplacement d'hyperviseur et dispositif de traitement d'informations
US9116774B2 (en) 2013-05-14 2015-08-25 Sandisk Technologies Inc. Firmware updates for multiple product configurations
CN108170368B (zh) * 2016-12-07 2024-01-23 北京忆恒创源科技股份有限公司 在线升级固件的方法及系统
CN108170368A (zh) * 2016-12-07 2018-06-15 北京忆恒创源科技有限公司 在线升级固件的方法及系统
IT201800000580A1 (it) * 2018-01-05 2019-07-05 St Microelectronics Srl Metodo di aggiornamento in tempo reale di una memoria differenziale con accessibilita' continua in lettura, memoria differenziale e sistema elettronico
US10811093B2 (en) 2018-01-05 2020-10-20 Stmicroelectronics S.R.L. Method of real-time access to a differential memory, differential memory and electronic system
US10824417B2 (en) 2018-01-05 2020-11-03 Stmicroelectronics S.R.L. Real-time update method for a differential memory, differential memory and electronic system
US11256442B2 (en) 2018-01-05 2022-02-22 Stmicroelectronics S.R.L. Real-time update method for a differential memory, differential memory and electronic system
US11645004B2 (en) 2018-01-05 2023-05-09 Stmicroelectronics S.R.L. Real-time update method for a differential memory, differential memory and electronic system
EP3509066A1 (fr) * 2018-01-05 2019-07-10 STMicroelectronics S.r.l. Procédé de mise à jour en temps réel d'une mémoire différentielle à accessibilité de lecture continue, mémoire différentielle et système électronique

Also Published As

Publication number Publication date
TW200832226A (en) 2008-08-01
TWI363297B (en) 2012-05-01
WO2008058101A3 (fr) 2009-01-08

Similar Documents

Publication Publication Date Title
US8286156B2 (en) Methods and apparatus for performing resilient firmware upgrades to a functioning memory
US20080109647A1 (en) Memory controllers for performing resilient firmware upgrades to a functioning memory
WO2008058101A2 (fr) Contrôleurs de mémoire pour effectuer des mises à niveau de micrologiciel de façon résiliente dans une mémoire en fonctionnement
US10146627B2 (en) Mobile flash storage boot partition and/or logical unit shadowing
US6317827B1 (en) Method and apparatus for fault tolerant flash upgrading
US7290097B2 (en) Nonvolatile memory
US6442067B1 (en) Recovery ROM for array controllers
US8266398B2 (en) Method and apparatus for preserving memory contents during a power outage
US7313682B2 (en) Method and system for updating boot memory that stores a fail-safe reset code and is configured to store boot code and boot updater code
CN103299276A (zh) 嵌入式装置的软件更新过程
CN101373451B (zh) 保护双基本输出入系统程序的计算机系统及其控制方法
JP2004152301A (ja) 不揮発性メモリシステムにおいて用いられる電力管理ブロック
CN103678030A (zh) 多系统设备启动系统及其方法
US20070174704A1 (en) Computer program automatic recovery activation control method and system
JP4620430B2 (ja) アダプタの高速ロードのための装置、システム、方法、記録媒体、およびプログラム
CN109582332B (zh) 互联网摄像机的系统升级方法及装置
CN115718610A (zh) 一种可靠的单片机应用程序更新的方法
CN111522690B (zh) 数据储存装置及维持数据储存装置正常开机运作的方法
CN105745616B (zh) 针对存储设备使用作为ram代码的具有破坏性的特征
CN102012823A (zh) 一种快速重新启动计算机的方法和装置
JP5470124B2 (ja) 電子機器及び電子機器用プログラム
TWI489390B (zh) 電子裝置及其系統更新方法
CN102023906A (zh) 便携式终端的微处理器、便携式终端及其修复方法
KR20230001522A (ko) 펌웨어 이미지의 부트 업 활성화를 위한 시스템들 및 방법
CN117331593A (zh) 双备份升级方法、计算机设备及存储介质

Legal Events

Date Code Title Description
NENP Non-entry into the national phase in:

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07863934

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 07863934

Country of ref document: EP

Kind code of ref document: A2