Abstract:
A method and system for upgrading a software component in a computing device are disclosed. Specifically, one embodiment of the present invention sets forth a method, which includes the steps of storing a first software component in a first memory segment, maintaining a second software component in a second memory segment, wherein the second software component enables the computing device to boot up, and modifying at least one of a plurality of address lines to access the second memory segment after exiting a reset condition, if the execution of the first software component fails to satisfy a predetermined test condition.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     Embodiments of the present invention relate generally to product upgrade techniques and more specifically to a method and system for upgrading software in a computing device. 
     2. Description of the Related Art 
     Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
     The consumer electronics marketplace is known to be fiercely competitive. Because of the tremendous and constant pressure to bring new products to the market at a faster pace and also at lower prices, these product offerings are often fraught with reliability issues due to sloppy quality assurance processes, deployment of transient technologies, and buggy designs. Moreover, since consumer electronic products tend to have a user life that lasts several years, these products typically need to go through multiple upgrades to address the reliability issues. With most of the consumer electronic products come equipped with flash memories, a typical upgrade process involves downloading a software image from a source system on a network and loading the software image into the flash memories of the target products without replacing the target products. 
     To further demonstrate the upgrade process,  FIG. 1A  is a conceptual diagram of some components in a computing device  100  that are involved in a conventional upgrade process  150 , and  FIG. 1B  is a flowchart illustrating the method steps in the conventional upgrade process  150 . The components that are involved include a CPU core  102 , a flash memory  104 , and a system memory  106 . The computing device  100  communicates with a source system  110  via a network  108 . When the CPU core  102  comes out of a reset condition, it fetches the instruction from a predetermined address  112  in step  154 . This predetermined address  112  is commonly referred to as a “reset vector.” Executing the instruction then triggers the retrieval of a software image  114 , often in a compressed form, from the flash memory  104 . In step  156 , the software image  114  is decompressed and placed in the system memory  106  for further processing. Suppose the software image  114  includes a boot code segment  116  and an application software segment  118 , which includes some upgrade code. Under normal operating conditions, the CPU core  102  successfully executes the upgrade code, and the computing device  100  proceeds to request a new software image from the source system  110  via the network  108  in step  158 . In step  160 , the computing device  100  receives the new software image from the source system  110  and places the image in the system memory  106  for further processing. Lastly, the new software image is placed in the flash memory  104  to overwrite the software image  114  in step  162 , and the computing device  100  reboots in step  152  so that the new software image can take effect. 
     The conventional upgrade process  150  has flaws that may render the computing device  100  non-operational. For example, if an unexpected system failure, such as a power failure, occurs while the new software image is being written into the flash memory  104 , then the boot code segment  116  may be corrupted with useless and non-operational code. If the instruction at the reset vector is corrupted, then the computing device  100  cannot complete its reboot sequence and remains in an undefined state. At this point, sellers of the computing device  100  mostly likely need to replace the unit for the customer. Especially in a mass deployment situation, if this irrecoverable failure applies to many of the deployed computing devices, then it significantly reduces the appeal of this product to customers and also places tremendous burden on sellers to replace all the failed units. 
     As the foregoing illustrates, what is needed in the art is a software upgrade process that is robust and addresses at least the shortcomings of the prior art approaches set forth above. 
     SUMMARY OF THE INVENTION 
     A method and system for upgrading a software component in a computing device are disclosed. Specifically, one embodiment of the present invention sets forth a method, which includes the steps of storing a first software component in a first memory segment, maintaining a second software component in a second memory segment, wherein the second software component enables the computing device to boot up, and modifying at least one of a plurality of address lines to access the second memory segment after exiting a reset condition, if the execution of the first software component fails to satisfy a predetermined test condition. 
     One advantage of the disclosed method and system is that a software upgrade process for a computing device can be performed in a robust and recoverable manner. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
         FIG. 1A  is a conceptual diagram of some components in a computing device that are involved in a conventional upgrade process; 
         FIG. 1B  is a flowchart illustrating the method steps in a conventional upgrade process; 
         FIG. 2A  is a conceptual diagram of some components in a computing device that are involved in a robust software upgrade process, according to one embodiment of the present invention; 
         FIG. 2B  is a flowchart illustrating the method steps in a robust software upgrade process, according to one embodiment of the present invention; 
         FIG. 3  is a simplified diagram of several memory components in a computing device utilized to enable recovery from a failed upgrade process, according to one embodiment of the present invention; 
         FIG. 4  is a timing diagram illustrating the relationships among some key signals utilized in a robust software upgrade process, according to one embodiment of the present invention; 
         FIG. 5  is a conceptual diagram illustrating the effect of modifying an address bit on a memory system, according to one embodiment of the present invention; and 
         FIG. 6  is a logic gate implementation of address modifier logic, according to one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Throughout this disclosure, one embodiment of the present invention is implemented as a program product for use with a computing device. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computing device) on which information is permanently stored; (ii) writable storage media (e.g., writeable memory devices such as flash memory) on which alterable information is stored. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. Other media include communications media through which information is conveyed to a computing device, such as through a data or telephone network, including wireless communications networks. The latter embodiment specifically includes transmitting information to/from the Internet and other networks. Such communications media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. 
       FIG. 2A  is a conceptual diagram of some components in a computing device  200  that are involved in a robust software upgrade process  250 , according to one embodiment of the present invention.  FIG. 2B  is a flowchart illustrating the method steps in this upgrade process  250 . Without limitation, the computing device  200  may be a game console, set top box, networking device, cellular telephone, hand-held device, mobile device, computer based simulator, desktop computer, laptop computer, palm-sized computer, tablet computer, or the like. The components that are involved mainly include a processing unit  202 , address modifier logic  203 , a flash memory  204 , a watchdog timer  205 , and a system memory  206 . The flash memory  204  has a first segment  214  and a second segment  218 . Suppose the first segment  214  initially contains a version 1 of a particular software code X. Unlike the conventional upgrade process  150 , the upgrade process  250  includes a failure tracking mechanism and a code relocation mechanism. Specifically, after receiving a new software image, a version 2 of the software code X, from the source system  210 , the computing device  200  verifies the integrity of the version 2 code in step  254 . If the integrity of the version 2 code is confirmed, then the processing unit  202  proceeds to store the version 2 code in the flash memory  204 . In one implementation, before storing the version 2 code in the first segment  214 , the version 1 code from the first segment  214  is copied to the second segment  218  as a backup. In another implementation, the version 1 code is not copied to the second segment  218 ; instead, a read-only memory (“ROM”) module of the computing device  200  is pre-loaded with some recovery code before the shipping of the device as shown in  FIG. 3 . The ROM module is configured to occupy the address space of the second segment  218 . In addition, another ROM module is also pre-loaded with a working version of the code, such as the version 1 code. 
     In step  258 , the computing device  200  reboots, so that the version 2 code can take effect. When the processing unit  202  comes out the reset condition, it activates the watchdog timer  205 , causing the watchdog timer  205  to load a pre-determined value and begin counting down. If executing the new instruction at the reset vector  212  leads to successfully bringing up the intended software components of the version 2 code, the software components deactivate the watchdog timer  205  before the count reaches zero in step  260 . The upgrade process  250  is considered a success. On the other hand, if the watchdog timer  205  fails to receive the reset signal timely, signifying serious errors in executing the instructions of the version 2 code, then the watchdog timer  205  counts down to zero and activates a recovery mode flag for the address modifier logic  203  in step  262 . In one implementation, the address modifier logic  203  ensures the execution of the instruction at a relocated reset vector  216  instead of at the default reset vector  216  after the processing unit  202  comes out of a reset condition and also sends a reset signal (“RST”) to the processing unit  202 . If the version 1 code is backed up in the second segment  218  in step  256 , then the address modifier logic  203  also ensures the execution of the version 1 code. Alternatively, as shown in  FIG. 3 , if the recovery code resides within the memory locations of the second segment  218 , then the address modifier logic  203  ensures the retrieval of the recovery code from the ROM module and the subsequent execution of it. The recovery code, when executed, causes the processing unit  202  to perform the basic functions that keep the computing device  200  operational. It may also include instructions, when executed, causes the processing unit  202  to retrieve the pre-loaded version 1 code from the ROM module for further processing. After the processing unit  202  comes out of the reset condition in step  258 , executing the instruction at the relocated reset vector  216  should allow the computing device  200  to boot up successfully. Depending on the state of the recovery mode flag, various implementation options are possible in step  264 . Subsequent paragraphs will provide some examples. 
     In conjunction with  FIG. 2A  and  FIG. 2B ,  FIG. 4  is a timing diagram illustrating the relationships among some key signals utilized in the upgrade process  250 , according to one embodiment of the present invention. It should be noted that some portions of the address lines, A 0 -A n , are marked with “X” in  FIG. 4 , because they are not relevant to the present discussions. Suppose the steps  252 - 258  of  FIG. 2B  have been performed, and the RST is issued to the processing unit  202  of  FIG. 2A  in clock cycle  2 . Suppose further that corrupted data is written to the first segment  214  in step  256 . The processing unit  202  comes out of the reset condition in clock cycle  3 , fetches the default reset vector  212  via the address lines, asserts its read signal to read the default reset vector  212 , and activates the watchdog timer  205  to begin counting down. Suppose the watchdog timer  205  is configured to be deactivated by clock cycle p. Due to the corrupted data in the first segment  214 , the deactivation of the watchdog timer  205  fails to occur. In clock cycle p+1, the watchdog timer  205  reaches zero, sets the recovery mode flag to high, and asserts the RST. Similar to clock cycle  3 , in response to the RST assertion, the processing unit  202  again fetches the default reset vector  212  on the address bus in clock cycle p+2. However, here, the setting of the recovery mode flag triggers the address modifier logic  203  to modify the default reset vector  212  to the relocated reset vector  216  in a region  410  as shown in  FIG. 4 . To ensure the processing unit  202  reads a valid relocated reset vector, in one implementation, the read signal is placed in a delay buffer so that the processing unit  202  does not attempt to read the address lines until the relocated reset vector is valid for a full clock cycle. For the implementation shown in  FIG. 4 , although the processing unit  202  asserts the read signal in clock cycle p+2, the read signal is buffered for one clock cycle, so that the processing unit  202  actually reads the relocated reset vector  216  in clock cycle p+3, not clock cycle p+2. It is worth noting that the processing unit  202  is not aware of the address modification and continues to fetch the default reset vector  212  coming out a reset condition. 
     To perform the address modification in one clock cycle, one embodiment of the address modifier logic  203  of  FIG. 2A  modifies a single bit out of the address lines. To illustrate, suppose the address lines are 32 bits wide and are denoted as bit  0  to bit  31  as shown in  FIG. 5 . Here, the default reset vector  212  corresponds to the memory location 0xBFFF_FFFF, and the relocated reset vector  216  corresponds to the memory location 0xBEFF_FFFF. Also, the first segment  214  for the version 2 code corresponds to the memory locations 0xBF00 — 0000−0xBFFF_FFFF, while the second segment  218  for the version 1 code corresponds to the memory locations 0xBE00 — 0000−0xBEFF_FFFF. One approach to access the relocated reset vector  216  and the second segment  218  is by flipping bit  24  of the address lines from a 1 to a 0 as shown in  FIG. 5 . In other words, since the processing unit  202  is not aware of the address modification, it continues to fetch addresses from the first segment  214 . With the recovery mode flag activated, the address modifier logic  203  “flips” bit  24  of each of these fetched addresses, so that the processing unit  202  in effect accesses the second segment  218 . 
       FIG. 6  is a logic gate implementation of the address modifier logic  203 , according to one embodiment of the present invention. Specifically, an exclusive OR (“XOR”) gate  600  generates a modified address bit based on the logic relationships detailed in the table shown in  FIG. 6 . Continuing with the example discussed above, the two inputs to the XOR gate  600  are the address bit to be modified (e.g., bit  24 ) and also the recovery mode flag. In other words, if the recovery mode flag is not set, then the address modifier logic  203  does not modify any address bit. It should be apparent to a person with ordinary skills in the art to recognize that bits other than bit  24  in the address lines may be modified as long as the storing of the new software image (e.g., the version 2 code) does not overwrite the memory locations in the relocated segment (e.g., the second segment  218  containing the backed up version 1 code) without exceeding the scope of the present invention. 
     As mentioned above, after the computing device  200  successfully recovers from errors during a software upgrade process, some implementation options are possible. In one implementation, the recovery mode flag is deasserted under the following conditions: (1) if the watchdog timer  205  of  FIG. 2A  does not countdown to zero and does not assert its signal high, but the RST is asserted high, then the recovery mode flag is deasserted; (2) if the watchdog timer  205  countdowns to zero and asserts its signal high, and the RST is also asserted high, then the recovery mode flag remains asserted; (3) if the watchdog timer  205  does not countdown to zero and does not assert its signal high, and the RST is also deasserted, then the recovery mode flag remains asserted. In addition, if the version 1 code is backed up in the second segment  218  as discussed above, then one implementation may continue to keep the version 1 code as the working copy code in the second segment  218  for future software upgrades. Also, at any time the address modifier logic  203  is activated, messages can be generated to alert a user of the computing device  200  to provide comfort and information to the user. 
     The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples, embodiments, and drawings should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims.