KR100601626B1 - Software upgrade method and computer-readable medium therefor - Google Patents

Abstract

As a result of performing an XOR operation on a bit unit basis between an original software image and a new software image, a software upgrade method using the image is disclosed.

The software upgrade method according to the present invention is a method for upgrading an original software image stored in a nonvolatile memory into a new software image of a new version, comprising: (a) bit-wise converting the original software image and the new software image; Storing a first resultant image having a XOR operation on the nonvolatile memory; (b) backing up the original software image in units of blocks of a predetermined size; And (c) replacing the original software image in units of blocks of a predetermined size using a second result image in which the original software image and the first result image are subjected to an XOR operation in bit units. Steps (b) and (c) are characterized by repeating a plurality of times until all software images are replaced.

According to the present invention, the memory space required for performing the software upgrade can be greatly reduced. It also provides a mechanism that can perfectly cope with error situations that may occur during software upgrades.

Description

Software upgrade method and computer-readable medium therefor}

FIG. 1 schematically illustrates data written or stored in a memory during a software upgrade process according to an exemplary embodiment of the present invention.

2 is a flowchart of a software upgrade method according to a preferred embodiment of the present invention.

The present invention relates to a software upgrade method, and more particularly, to a software upgrade method using an image obtained by performing an XOR operation on a bit unit of an original software image and a new software image.

In general, software (software or software) is a general term for a program executed through a hardware (hardware or hardware) device. However, the following description will focus on software related to an operating system that controls the operation of a specific hardware device, for example, a mobile communication terminal such as a digital TV (DTV) or a performance communications service (PCS) phone. . Operating system software for this particular hardware device is usually a binary image, or form of executable code, in non-volatile memory, such as electrically erasable and programmable ROM (EEPROM) or Flash ROM. It is stored in the RAM and mounted in RAM together with the operation of the system to control the operation of the system.

The operating system software of a specific hardware device needs to be continuously upgraded, that is, replacing the old version of the software with a newer version of the software as the technology develops. Same as

First, a new software image is received from the outside and stored (hereinafter referred to as first step). Next, the entire original software image is backed up (hereinafter referred to as the second step). Finally, the new software image is replaced with the original software image (hereinafter referred to as the third step).

The required capacity of the storage medium in the conventional software upgrade scheme will be described. Here, the storage medium refers only to nonvolatile memory in which software is primarily stored, and is described based on the most widely used flash ROM (DRAM is ignored because it is relatively inexpensive compared to a flash ROM). Non-volatile, re-writable memory, such as flash ROM, is very expensive compared to conventional DRAM, so minimizing the required amount is an important factor in reducing the cost of the product. For convenience of explanation, it is assumed that the original software image and the new software image are N megabytes of the same binary size.

According to the conventional method, N megabytes in which the original software image is stored, N megabytes necessary for storing a new software image inputted from the outside in the first step, and the original software image in the second step are backed up. N megabytes of space needed, and therefore 3N megabytes of flash ROM in total, are required, and no additional memory is used in the third stage.

Therefore, in order to perform a software upgrade in a conventional manner, a memory space for storing two software images is additionally required in addition to a memory space for storing an original software image.

If, in the conventional method, to reduce the size of the flash ROM, for example, using only 2N megabytes of flash ROM, there is a problem that can not sufficiently cope with an error situation that may occur during the software upgrade.

Error situations that can occur during software upgrade are as follows. In other words, there is a case where a sudden power cut occurs during the software upgrade, and because of the error of the new software itself, it is necessary to restore the original software image.

Suppose that if only the original software image is backed up to the flash ROM and the new software image is stored using DRAM, the power is cut off during the software upgrade process. In this case, the new software image stored in the DRAM disappears with the power off. Therefore, after recovering the original software image through the original software image backed up in the flash ROM, the new software image is input again from the outside. The upgrade process must be repeated from the beginning.

Suppose that if only a new software image is stored in the flash ROM and the original software image is backed up using DRAM, the power is cut off during the software upgrade process. In this case, the new software image stored in the DRAM is extinguished with power off, so there is no way to recover the original software image. Therefore, if it is found that there is an error in the new software image itself, it is impossible to revert to the original software image.

Therefore, various modifications to reduce the memory space required in the conventional method may not sufficiently cope with error situations that may occur during software upgrade.

The technical problem to be solved by the present invention is to solve the above problems, by using the result of performing the XOR operation of the original software image and the new software image bit-by-bit image, when upgrading the software while using the minimum memory space The present invention provides a method for upgrading a software that can cope with an error situation that may occur, and a recording medium therefor.

In order to solve the above technical problem, the software upgrade method according to one aspect of the present invention in the method of upgrading the original software image of the original version stored in the non-volatile memory to a new version of the new software image, (a) the Storing a first resultant image obtained by performing an XOR operation on the original software image and the new software image bit by bit in the nonvolatile memory; (b) backing up the original software image in units of blocks of a predetermined size; And (c) replacing the original software image in units of blocks of a predetermined size using a second result image in which the original software image and the first result image are subjected to an XOR operation in bit units. Steps (b) and (c) are characterized by repeating a plurality of times until all software images are replaced.

In addition, the nonvolatile memory is preferably a flash ROM.

In addition, the step (b) includes the step of storing the block number to perform the backup before performing the block-by-block backup in order to manage the backup situation, the step (c) is a block unit to manage the replacement situation Storing the block number to be replaced before performing the replacement of the method; or (b) storing the block number in which the backup is completed after performing the block unit backup to manage the backup situation. In addition, the step (c) preferably comprises the step of storing the block number of the replacement is completed after performing the block-by-block replacement to manage the replacement situation.

In addition, the step (a) may include (a1) receiving the new software image from the outside; (a2) generating the first result image by performing an XOR operation on the original software image and a new software image input from the outside in the step (a1) in units of bits; (a3) compressing the first resultant image generated in step (a2); And (a4) storing the first resultant image compressed in the step (a3) in the nonvolatile memory.

According to another aspect of the present invention, a software upgrade method includes upgrading an original software image stored in a nonvolatile memory to a new software image of a new version, the method comprising: (a) the original software image and the new software image; Receiving a compressed image of the first result image obtained by performing an XOR operation in units of bits from the outside and storing the image in the nonvolatile memory; (b) decompressing the image input from the outside in step (a) to restore the first resultant image; (c) backing up the original software image in units of blocks of a predetermined size; And (d) replacing the original software image by the block unit of the predetermined size using the original software image and the second result image of which the XOR operation is performed in bit units on the first result image restored in the step (b). And the steps (c) and (d) are repeated a plurality of times until all software images are replaced.

In addition, step (b) may include: (b1) reading an image stored in the nonvolatile memory by receiving an input from the outside in the step (a); And (b2) decompressing the image read out in the step (b1) to restore the first resultant image.

In order to solve the above other technical problem, a computer-readable recording medium in one aspect of the present invention includes (a) upgrading the original software image stored in a nonvolatile memory to a new software image of a new version. Storing a first resultant image obtained by performing an XOR operation on the original software image and the new software image bit by bit in the nonvolatile memory; (b) backing up the original software image in units of blocks of a predetermined size; And (c) replacing, by the computer, the original software image by the block unit of the predetermined size using a second resultant image obtained by performing an XOR operation on the original software image and the first resultant image bit by bit. Characterized in that it records the program for the purpose.

In another aspect of the present invention, a computer-readable recording medium includes (a) the original software image and the new software in order to upgrade the original software image stored in the nonvolatile memory with a new version of the new software image. Receiving an image obtained by compressing the first resultant image after performing an XOR operation on a bit basis from an external source and storing the image in the nonvolatile memory; (b) decompressing the image input from the outside in step (a) to restore the first resultant image; (c) backing up the original software image in units of blocks of a predetermined size; And (d) replacing the original software image by the block unit of the predetermined size using the original software image and the second result image of which the XOR operation is performed in bit units on the first result image restored in the step (b). And recording a program for executing the step by the computer.

Hereinafter, with reference to the accompanying drawings will be described in detail the configuration and operation of the preferred embodiment of the present invention.

FIG. 1 schematically illustrates data written or stored in a memory during a software upgrade process according to an exemplary embodiment of the present invention.

As shown in FIG. 1, the capacity of the flash ROM 100 required in the software upgrade process according to the present embodiment is a space for storing the original software image 110, and for storing the compressed image of the XORed new software image. Space 140, a backup space 120 for storing one block of the original software image, and a space 130 for recording upgrade status information.

Here, the new software image XORed refers to an image obtained by performing an XOR operation on a bit unit of the original software image and the new software image. Therefore, if the XOR operation is performed once again bit by bit on the new software image and the original software image, the new software image becomes. These new XORed software images are preferably stored in the flash ROM in a compressed state to save memory space. If the number of bits that differ between the original software image and the new software image is small, it will be understood by those skilled in the art that the new software image XORed according to the present embodiment has a high compression efficiency. Could be.

Memory access units in DRAMs and the like are the smallest units such as bits, bytes, or words, but nonvolatile memories such as flash ROMs can be accessed or erased at once. It is in units of kilobytes to 256 kilobytes (hereinafter, a block means a minimum access unit in a specific flash ROM). In this embodiment, since the original software image is upgraded on a block basis, only a memory space 120 capable of backing up the original software image on a block basis is sufficient.

In this embodiment, the current upgrade status is managed. Since the memory space required to manage the upgrade situation is only a few bytes to several tens of bytes, it is preferable to use a non-volatile memory having a fast access speed to reduce the number of accesses to a relatively slow flash ROM. will be. In addition, if the block size is small, the backup space may be utilized as a nonvolatile memory having a high speed of contact without a backup space in the flash ROM.

The DRAM 150 shows the space 160 for storing the XORed new software image. Of course, since all computations are done in DRAM, it is natural that the operators and operands for XOR operations, for example, must be temporarily stored in DRAM.

Subsequently, a software upgrade process according to an embodiment of the present invention in the memory configuration of the DRAM and flash ROM shown in FIG. 1 will be described with reference to FIG.

2 is a flowchart of a software upgrade method according to a preferred embodiment of the present invention.

First, a new software image is received from the outside (step 200). The external input method in step 200 is generally using a smart card or the like which stores a new software image. However, it will be appreciated by those skilled in the art that preferably it is possible to receive new software images from a server or service center via a communication network. The external input method through such a communication network may be, for example, a direct transmission or a multiplex transmission method through a serial cable, ethernet, and a wireless network.

In addition, the new software image input from the outside in step 200 is preferably an image form in which the original software image and the new software image are compressed as a result of performing an XOR operation on a bit-by-bit basis (that is, the XORed new software image). However, the present invention can operate with compatibility with conventional methods. That is, when a new software image having no XOR operation is directly input from the outside, generating a result image of performing the XOR operation bitwise on the input new software image and the original software image, and compressing the resulting image. Performing steps internally (not shown). Of course, if the new software image is compressed in its own way, you will need to decompress and perform the XOR operation.

Next, the XORed new software image is stored in a compressed form in a flash ROM (step 210).

If the new software image XOR received from the outside is received in a compressed form in step 200, the process is decompressed (step 220). However, when the new software image is directly input from the outside as in the conventional method, the result image of the internally performed XOR operation may be used, and thus it is not necessary to perform step 220.

Since the new software image input from the outside in step 200 is temporarily stored in the DRAM before being stored in the flash ROM in step 210, the new software image stored in the flash ROM must be read in step 210. You will not need to read it into RAM.

However, in order to process the step of receiving a new software image from the outside and upgrading the original software image to the new software image as a separate process, the new software image input from the outside is stored in the flash ROM and stored in the flash ROM. It will be understood by those skilled in the art that the new software image may be read again, mounted in RAM, and then further processed.

Next, one block of the original software image stored in the flash ROM is backed up (step 230). Here, the backup space may be used as the backup space of the flash ROM, and when the block unit is small, other nonvolatile memory having a relatively high access speed may be used as described above.

In addition, step 230 includes managing the status information of the backup (status). This backup situation can be managed in two ways. It is possible to save the block number to be backed up before performing the backup in block units or to save the block number in which the backup is completed after performing the backup in block units. Regardless of which method is used, the present embodiment may refer to the alternative situation information managed in step 250, which will be described later, to determine the exact time of occurrence of an error. This will be described later.

If it is determined that an error such as a power failure occurs in the backup process of step 230, the software upgrade method according to the present embodiment is stored in the flash ROM, unlike the conventional method in which the entire software upgrade process should be repeated. This allows for an error recovery method that reads the new XORed software image back into DRAM, decompresses it, and resumes the backup process from that block.

Next, an XOR operation is performed on the original software image and one block of the new software image XORed in bit units to generate one block of the new software image (step 240), and the corresponding block of the original software image stored in the flash ROM is generated. Replace with one block of the new software image created in step 240 (step 250).

Step 250 also includes a process of managing alternative contextual information. This alternative situation can be managed in two ways. It is possible to store the block number to be replaced before performing the replacement in block units or to store the block number in which the replacement is completed after performing the replacement in block units. Regardless of which method is used in the present embodiment, as mentioned above, it is possible to identify the exact time of occurrence of error by referring to the backup status information in step 230 together.

If it is determined that an error such as power off occurs in the replacement process of step 250, the software upgrade method according to the present embodiment is stored in the flash ROM, unlike the conventional method in which the entire software upgrade process should be repeated. After the new XOR software image is read back into DRAM and decompressed, XOR operation is performed on the corresponding block data of the original backed-up software image and the corresponding block data of the new XORed software image to generate the corresponding block of the new software image. And an error recovery method that resumes the replacement process from the point where the error occurred.

Finally, the process of determining whether the replacement of all the software images is completed (step 260) is repeated in the block-by-block backup and replacement process for the entire software image.

Subsequently, when the software upgrade method according to the embodiment of the present invention is adopted, a method of determining a time point at which an error occurs in the software upgrade process will be described. The status information of the backup block and the replacement block managed in the software upgrade process according to an embodiment of the present invention may be (N, N) and (N, N-1). Because backup and replacement are repeated sequentially, the replacement proceeds after the backup. Here, N means a block number.

First, if the situation information in steps 230 and 250 is managed in such a way that the block number is stored before performing the backup or replacement, the situation information (N, N) is an error during the replacement of the Nth block. It can be understood that the error has occurred, and that the situation information (N, N-1) indicates that an error has occurred in performing the backup of the N-th block.

If the situation information in steps 230 and 250 is managed in such a manner that the corresponding block number is stored after the backup or replacement is performed, the situation information (N, N) is performed in the process of performing the backup of the N + 1th block. It will be understood that an error has occurred, and the situation information (N, N-1) means that an error has occurred in the course of performing replacement of the N-th block.

Therefore, according to the present invention, it is possible to determine the exact time of occurrence of the error, and to proceed with the software upgrade process from that time.

In addition, according to the present invention, when it is found that there is an error in the new software image itself after the software upgrade is completed, the resultant image (that is, the new software image XORed) is obtained by XORing the original software image and the new software image bit by bit. By using the new software image and the new software image, it is also possible to perform an XOR operation on a bit basis again to restore the original software image.

Embodiments of the present invention can be written as a program executable in a computer system. In addition, the program can be read from a computer readable recording medium having recorded such a program and executed in a general-purpose digital computer system. Such recording media include magnetic storage media (e.g., ROM, floppy disk, hard disk, etc.), optical reading media (e.g., CD-ROM, DVD, etc.) and carrier waves (e.g., transmission over the Internet). Media is included.

So far, the present invention has been described with reference to the preferred embodiment (s). Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

According to the present invention, a software upgrade is performed by using a result image of performing an XOR operation on an original software image and a new software image bit by bit, and managing the status information while repeatedly performing a backup and replacement process on a block basis. It is possible to greatly reduce the memory space required to perform the operation.

It also provides a mechanism that can perfectly cope with error situations that may occur during software upgrades.

Claims (13)

In the method of upgrading the original version of the original software image stored in non-volatile memory to the new version of the new software image, (a) storing a first resultant image obtained by performing an XOR operation on the original software image and the new software image bit by bit in the nonvolatile memory; (b) backing up the original software image in units of blocks of a predetermined size; And (c) replacing the original software image in units of blocks of a predetermined size using a second result image in which the original software image and the first result image are subjected to an XOR operation in bits; The steps (b) and (c) are repeated multiple times until all software images are replaced. The method of claim 1, And wherein the nonvolatile memory is a flash ROM. The method of claim 1, Step (b) includes storing a block number to be backed up before performing the backup in block units in order to manage the backup progress, The step (c) of the software upgrade method comprising the step of storing the block number to be replaced before performing the block-by-block replacement to manage the replacement progress. The method of claim 1, Step (b) includes the step of storing the block number of the backup is completed after performing a block-by-block backup to manage the backup progress, The step (c) of the software upgrade method comprising the step of storing the block number of the replacement is completed after performing the block-by-block replacement to manage the replacement progress. According to claim 1, wherein the step (a), (a1) receiving the new software image from an external source; (a2) generating the first result image by performing an XOR operation on a bit basis between the original software image and a new software image input from the outside in the step (a1); (a3) compressing the first resultant image generated in step (a2); And (a4) storing the first resultant image compressed in the step (a3) in the nonvolatile memory. In the method of upgrading the original version of the original software image stored in non-volatile memory to the new version of the new software image, (a) receiving an image obtained by compressing a first resultant image obtained by performing an XOR operation on the original software image and the new software image in units of bits from the outside and storing the image in the nonvolatile memory; (b) decompressing the image input from the outside in step (a) to restore the first resultant image; (c) backing up the original software image in units of blocks of a predetermined size; And (d) replacing the original software image by the block unit of the predetermined size using the original software image and the second result image obtained by performing an XOR operation on a bit-by-bit basis with the first result image reconstructed in step (b) Including steps The steps (c) and (d) are repeated multiple times until all software images are replaced. According to claim 6, wherein step (b), (b1) reading an image stored in the nonvolatile memory by receiving an input from the outside in the step (a); And (b2) decompressing the image read out in the step (b1) to restore the first resultant image. The method of claim 6, Step (c) includes storing a block number for performing a backup before performing a block-by-block backup to manage the backup situation, The step (d) of the software upgrade method comprising the step of storing the block number to be replaced before performing the block-by-block replacement to manage the replacement situation. The method of claim 6, Step (c) includes the step of storing the block number of the backup is completed after performing a block-by-block backup to manage the backup situation, The step (d) of the software upgrade method comprising the step of storing the block number of the replacement is completed after performing the block-by-block replacement to manage the replacement situation. (a) a first result image of performing an XOR operation on a bit-by-bit basis between the original software image and the new software image in order to upgrade the original software image stored in the nonvolatile memory to the new software image of the new version. Storing in the nonvolatile memory; (b) backing up the original software image in units of blocks of a predetermined size; And (c) causing the computer to replace the original software image by the block unit of the predetermined size by using the second result image in which the original software image and the first result image are subjected to an XOR operation in bit units. A computer-readable recording medium that records a program for the program. The method of claim 10, Step (b) includes the step of storing the block number of the backup is completed after performing a block-by-block backup to manage the backup situation, The step (c) includes storing a block number in which the replacement is completed after performing block-by-block replacement in order to manage the replacement situation. The method of claim 10, wherein step (a) comprises: (a1) receiving the new software image from an external source; (a2) generating the first result image by performing an XOR operation on a bit basis between the original software image and a new software image input from the outside in the step (a1); (a3) compressing the first resultant image generated in step (a2); And (a4) storing the first resultant image compressed in the step (a3) in the nonvolatile memory. (a) a first result of performing an XOR operation on a bit basis of the original software image and the new software image to upgrade the original software image stored in the nonvolatile memory to the new software image of the new version; Receiving the compressed image from an external source and storing the compressed image in the nonvolatile memory; (b) decompressing the image input from the outside in step (a) to restore the first resultant image; (c) backing up the original software image in units of blocks of a predetermined size; And (d) replacing the original software image by the block unit of the predetermined size using the original software image and the second result image obtained by performing an XOR operation on a bit-by-bit basis with the first result image reconstructed in step (b) A computer-readable recording medium having recorded thereon a program for executing a step by a computer.

Images