KR20000023322A - A method and system for updating memory in a processing system - Google Patents

Abstract

PURPOSE: A system for managing memory update is provided for the system to operate at a first or a second nonvolatile component, which contain the identical code block. CONSTITUTION: A system adoptes a fail safe memory update method using two non-volatile components such as EPROM A and B. Two components contain the identical code block body. If a user updates the microcode in a firmware by loading from a diskette, the memory update is performed only for one of EPROMs, such as EPROM B. When the EPROM B is damaged, no promotion is possible to the system. If a test for the EPROM B is finished, a promotion process starts by the user and the content of the EPROM B is transfered safely to the EPROM A.

Description

A METHOD AND SYSTEM FOR UPDATING MEMORY IN A PROCESSING SYSTEM}

The present invention relates to nonvolatile devices in a processing system, and more particularly, to updating nonvolatile devices.

For today's computer systems, the most important is reliability, applicability, and service availability. To optimize these characteristics, such problems, whether in the customer's environment or potential defects discovered by the development department after shipping the product, must be corrected on site. One important factor in correcting the problem is firmware update, which allows customers or experienced field experts to update the microcode of the shipped computer. Microcode update removes the known problems as described above or adds new functionality to the system by acquiring compiled code from diskette or other portable media and loading it into a flash EPROM for future execution. Can be. Therefore, such an update provides a way to perform a software upgrade to code embedded in a machine that is generally inaccessible from the operating system or a standard user interface.

However, a problem with the memory update process is that, despite all the precautions taken, there is a risk that replacement of a field replacement unit (FRU) containing a system planner may be required due to corruption of the memory EPROM.

In detail, the memory EPROM is generally divided into two parts, a recovery portion and a composite portion. The recovery section contains all the code necessary to update the composite block, and thus most of the functionality is present in the composite block, so even if there are many updates, the contents of the recovery section are never affected. However, there is the ability to update a recovery EPROM and such functionality is often required. This causes a problem. If a power outage occurred while updating the recovery section of the EPROM, no machine could correct the damage due to the correction without replacing the component. The customer has unfortunately found that it is not possible to execute any code because the recovery EPROM can be partially programmed with new and existing code. In this case, there is no way other than replacing the system planner or replacing the FRU containing the EPROM as it can no longer be updated by conventional methods.

Many methods and products have been devised to eliminate this problem. One product developed by Intel Corporation is an EPROM or flash nonvolatile device called a boot block device. The device is divided into several blocks so that all blocks except one small block, called the boot block, can be reprogrammed. Here, the idea was to similarly split the microcode so that only the minimum microcode required to reprogram a changeable partition is stored in the boot block. Such microcode will hereinafter be referred to as critical code. Thus, if an error occurs while reprogramming the changeable partition, the boot block partition remains unchanged and can be used to reprogram the damaged partition. However, these devices have caused another problem because they cannot change all of the microcode. Since the microcode in the boot block partition cannot be changed by the computer, changing such microcode will be at least as difficult as changing the microcode stored in read-only memory.

Other vendors have also attempted to solve the problem by dividing the nonvolatile devices. For example, an improved microdevice provides a flash memory that includes several partitions of equal size. These devices differ from Intel's in that the blocks used to store the threshold code are actually memory blocks that can be write protected on their own. Other vendors, such as Texas Instruments and Mitsubishi, also offer flash nonvolatile devices that are divided into several blocks of the same size.

There has been no device that can solve all the above problems. In particular, there is no device to store the microcode in such a way that all the code can be updated by the host computer while allowing the threshold code to be preserved. Such a device would provide the host computer with the flexibility to update its own microcode while providing a mechanism that allows the host computer to tolerate defects that occur during code changes.

One attempt to solve this problem is to embed a nonvolatile paging mechanism in the EPROM module. By dividing the EPROM device into two blocks and having the positions of the blocks exchanged through paging, one of the two blocks can be used as the boot block. This allows the system to recover from defects that occur during reprogramming, while at the same time allowing complete reprogramming of the device.

Reprogram a block that is not currently used as the boot block with a new threshold code.

2. Swap two blocks using a paging mechanism.

3. At this point, the block containing the new threshold code becomes the new boot block and other blocks can be reprogrammed.

Throughout the process described above, the valid threshold code is always located in the boot block, allowing the computer to recover from errors that may occur during the update. In addition, in order to ensure the integrity of the threshold code located in the boot block, some basic error checking must be performed through a process such as CRC checking for a new threshold code before any block replacement is made.

Blocks can be exchanged using a simple paging mechanism. Using paging, the memory address provided by the microprocessor will be used as an index in the two-entry page table. The entries in the page table specify which blocks of memory operate within a given range of microprocessor addresses.

If the page table remains invalid, the (new or existing) threshold code may not be accessed as required. This will keep the system in a nonfunctional state as described above. To prevent this, some fault tolerance must be included in the paging function. The method used here is to provide only two pages (blocks) to eliminate the possibility of invalid page tables.

This very simple paging mechanism can be implemented using only one bit, and will allow a valid boot block to be accessed with either polarity of that bit. More complex mechanisms can be devised but are not required to achieve the desired function.

Although effective for the purposes presented, these systems rely on paging methods and memory pointers to maintain system integrity but add significant overhead within the system. In addition, if the paging mechanism fails, such a system would have a situation where the code would be in a non-functional state.

Accordingly, what is needed is a system and method for updating nonvolatile devices, such as fail-safe flash memories. These systems must be easy to implement, inexpensive, and adaptable to existing processing systems. The present invention assumes such a need.

The present invention provides a method and system for managing memory updates in a processing system. The method and system include providing first and second nonvolatile devices. Each of the first and second nonvolatile elements includes substantially the same code block. The method and system include causing the memory update process to be initiated only on one of the first and second nonvolatile devices.

By adopting the above-described fail-safe memory update method, there is no possibility of any damage to the firmware. Now, if a customer updates the firmware due to a bug condition or the introduction of new functionality, it is certain that the system can be booted upon completion of the update without damage. The conventional system did not. There is no need to replace the planner, which increases customer satisfaction and reduces service costs, which significantly reduces repair costs. In the event of a power outage, memory capacity can be extended to the entire code body without risking system damage, providing a significant advantage over conventional systems.

1 is a flow chart of an EPROM update process according to the present invention;

2 is a flow chart of an EPROM promoter process in accordance with the present invention;

3 is a flow diagram of a system and method in accordance with the present invention.

Explanation of symbols for the main parts of the drawings

12: operating system 14: engineering software

16: service processor card

The present invention relates to improvements to memory updates in processing systems. The following description is presented to enable any person skilled in the art to make and use the invention, and is described in connection with the present patent application and requirements thereof. Various modifications to the preferred embodiment of the present invention will be readily apparent to those skilled in the art, and the overall principles herein may be applied to other embodiments. Accordingly, the present invention should not be construed as limited to the embodiments shown, but rather the broadest interpretation consistent with the principles and features described herein.

A system and method in accordance with the present invention for managing a memory update process are disclosed. The system and method according to the present invention utilizes a fail-safe memory update technique that does not rely on the synthesis and recovery code blocks as described above, which eliminates the possibility of corruption of the recovery block and also eliminates the possibility of FRU replacement due to the damage. In the following, the present invention will be described in connection with a flash device or an EPROM device. However, it will be readily appreciated by those skilled in the art that any type of nonvolatile device may be used and that it will fall within the spirit and scope of the present invention.

This update method is substantially the same and relies on using two EPROMs on the service processor card that are present in their original state as shipped after manufacture. Both sides will be designated EPROM A and EPROM B. Each of these EPROMs contains the complete code body needed for the firmware to function. To ensure integrity throughout the update process, certain basic rules are followed when updating microcode, which includes logical progression to the failsafe method. In order to fully understand the present invention, reference is now made to FIGS. 1 and 2 in conjunction with the following description.

1 shows a flowchart of a memory update process according to the present invention. The user himself may stop booting EPROM A 18 or EPROM B 20 of the service processor 16 so that the user has two firmware program options for loading the user system. The memory update process, which threatens the integrity of the EPROM as seen by the feature of loading code from the diskette into the EPROM through the operating system, is executed only in EPROM B 20. Once EPROM B 20 has been tested, promotion process 18 is initiated by the user to copy the contents of EPROM B 20 to EPROM A 18 of service processor card 16 as shown in FIG. Can be.

In order to achieve this promotion process, the current boot session must be initiated in EPROM B 20. In other words, if the EPROM B 20 is damaged, the possibility of promotion is eliminated. Although the present invention will be described with reference to the flash update process disclosed in EPROM B 20, those skilled in the art will readily appreciate that EPROM A 18 may be selected as the EPROM to initiate the update process. It is important to note that only one of the EPROMs can be updated to ensure that no corrupted data is transmitted during the promotion process. In addition, since the system must be fully booted prior to the commencement of the promotion operation, source integrity is verified before the update begins.

3 is a flow chart showing the utilization of the memory update management method according to the present invention. First, in step 100 the user decides which of EPROM A and EPROM B to select. Assuming the user has selected EPROM A 18, in step 102 the system will boot using the AIX log in prompt. Subsequently, step 104 determines whether the system is a memory update or a memory promotion. If the system is a memory promotion, an error is logged at step 106 and through step 108 the system is rebooted on the A side. On the other hand, if the system is a memory update, the memory update is started in step 110, and the new image is copied to EPROM B. The system then reboots at EPROM B via step 112.

On the other hand, if the user selects EPROM B, in step 106 the system boots to the AIX log prompt. Next, in step 113, it is determined whether the system is a promoter or a memory update. If the system is a memory update, steps 110 and 112 are repeated. If the system is a promoter, the promotion is initiated at step 114 to duplicate the memory B image to memory A. Next, in step 116, the system is rebooted in memory A.

Note that by these logic rule descriptions, a predetermined state is meant as follows.

EPROM A is only updated by the promotion process and not via diskette. If the update process is terminated (in accordance with regulations, on EPROM B) due to lack of power, the user can return to EPROM A unaffected due to the update failure. Subsequently, when the machine is booted in the operating state in EPROM A, the user can retry the update an infinite number of times. Since no repair block has been destroyed, no damage is required that requires replacement of the FRU. If the promotion process is terminated due to no power (according to regulations, on EPROM A), the user may return to EPROM B, which is known to be valid by successful boot completion (see criteria for promotion). Can be. In addition, the user can continue to boot the system from EPROM B, without any loss of system applicability.

The adoption of the failsafe memory update method described above eliminates the possibility of any damage to the firmware. Now, if a customer updates the firmware due to a bug condition or the introduction of new functionality, it is certain that the system can be booted upon completion of the update without damage. The conventional system did not. Repair costs are significantly reduced, as there is no need to replace the planner, increasing customer satisfaction and reducing service costs. In the event of a power outage, memory capacity can be extended to the entire code body without risking system damage, providing a significant advantage over conventional systems.

Although the invention has been described in accordance with the illustrated embodiments, those skilled in the art will readily recognize that changes may be made to the embodiments and that such changes will fall within the spirit and scope of the invention. Accordingly, many modifications may be made by one skilled in the art without departing from the spirit and scope of the appended claims.

The memory update method and system of the present invention eliminates the need to replace the planner, thereby increasing customer satisfaction and reducing service costs, thereby significantly reducing repair costs. In the event of a power failure, the memory capacity can be extended to the entire code body without risking system damage, providing a significant advantage over conventional systems.

Claims (10)

A method of managing memory updates in a processing system, (1) providing first and second nonvolatile elements, each of the first and first nonvolatile elements comprising substantially the same code block; (Ii) causing the memory update process to be initiated only on one of the first and second nonvolatile devices; How to manage memory updates. The method of claim 1, The first and second nonvolatile devices include first and second EPROM devices. How to manage memory updates. The method of claim 1, The first and second nonvolatile devices include first and second flash devices. How to manage memory updates. The method of claim 1, (3) causing the memory promoter process to be initiated from one of the first and second nonvolatile devices to the other of the first and second nonvolatile devices. How to manage memory updates. The method of claim 4, wherein ④ causing the processing system to reboot in either the first nonvolatile device or the second nonvolatile device; How to manage memory updates. A system for managing memory updates in a processing system, Means for providing first and second nonvolatile elements, each of the first and first nonvolatile elements comprising substantially the same code block; Means for causing a memory update process to be initiated only on one of the first and second nonvolatile devices; Memory update management system. The method of claim 6, The first and second nonvolatile devices include first and second EPROM devices. Memory update management system. The method of claim 6, The first and second nonvolatile devices include first and second flash devices. Memory update management system. The method of claim 6, Means for causing a memory promotion process to be initiated from one of the first and second nonvolatile devices to the other of the first and second nonvolatile devices Memory update management system further comprising. The method of claim 9, Means for causing the processing system to reboot in one of the first nonvolatile device and the second nonvolatile device; Memory update management system.