US 20070094656 A1
A method and apparatus for achieving a non-disruptive code load in a digital electronic device utilizes a copier that modifies itself as it executes. A fixed data section might be left unmodified to preserve a trusted system state. The copier has two parts, a bootstrapper and a dynamic part. As a minimum, the bootstrapper copies the new dynamic part into the runtime area and initiates execution of the new dynamic part. Through the dynamic part, the desired new runtime area configuration for data and code modules is achieved. The bootstrapper is typically static through upgrades, but instruction cache associated with the processor can make self-modification of even the bootstrapper more convenient.
1. An apparatus for upgrading the content of a runtime area in a digital system, comprising:
a) a source area containing a new copier that includes a new copier dynamic code; and
b) an old copier within the runtime area, the old copier including an old copier dynamic code and an old bootstrapper, the old bootstrapper containing logic to cause a processor to:
(i) copy the new copier dynamic code into the runtime area, thereby overwriting an instruction of the old copier dynamic code, and
(ii) thereafter execute the new copier dynamic code from the runtime area.
2. The apparatus of
3. The apparatus of
4. The apparatus of
5. The apparatus of
6. The apparatus of
7. The apparatus of
8. The apparatus of
9. The apparatus of
10. The apparatus of
11. The apparatus of
c) an instruction cache containing a copy of the old bootstrapper, the processor executing the copy of the old bootstrapper contained in the instruction cache.
12. A method for upgrading the content of a runtime area in a digital system, comprising:
a) receiving in a source area a new copier that includes a new copier dynamic code;
b) executing an old bootstrapper in the runtime area, said bootstrapper included within an old copier that also includes an old copier dynamic code;
c) copying, by the old bootstrapper, the new copier dynamic code into the runtime area, thereby overwriting an instruction within the old copier dynamic code; and
d) initiating, by the old bootstrapper, execution of the new copier dynamic code that has been copied into the runtime area.
13. The method of
e) copying by the new dynamic copier code a new runtime content version from the source area into the runtime area.
14. The method of
15. The method of
f) performing an operation by the new dynamic copier code upon a module in the new runtime content version, said operation in the group consisting of compression, decompression, encryption, decryption, encoding, decoding, compilation, and assembly.
16. The method of
17. The method of
18. The method of
19. The method of
20. The method of
21. The method of
22. The method of
e) before executing the old bootstrapper, creating a copy of the old bootstrapper instructions into an instruction cache,
the step of executing the old bootstrapper being performed by a processor using the copy of the old bootstrapper instructions in the instruction cache.
The present application is a continuation-in-part of, and claims benefit from, U.S. patent application Ser. No. 10/228,044, filed Aug. 27, 2002, and incorporated herein by reference in its entirety.
The present invention relates to logic adapted to execution on an electronic digital device for a self-modifying copier. More particularly, it relates to a self-modifying copier used to nondisruptively load code and data into a runtime area of an active digital electronic device.
The field of computing technology advances at almost a lightening pace. Equipment rarely has more than a five year life. In most instances, the life is only two to three years. In some instances, it is possible to replace various pieces of the equipment. In other instances, all that is required is a modification to existing code.
“Smart” devices operating under control of a digital processor today include not just traditional computer systems, but also include, for example, telephones; personal digital assistants; routers, switches, and other networking devices; media presentation, recording, and distribution systems; storage systems, databases, and data warehouses; kiosks; security monitoring equipment, devices supporting web services; space shuttles, and tractors. It is easy to imagine situations in which any of these kinds of equipment might benefit from being able to update information, including running code, on the fly nondisruptively; i.e., without interruption to active operation. We will refer to such a device operating under the control of a processor as a “system.”
It is desirable to provide an apparatus and method that enables running code on such systems to be upgraded to add functionality or fix bugs without any system down time. The device would run or operate in real time and continue to process requests. A process that updates a system without requiring it to shut down is often referred to as a nondisruptive code load (NDCL).
A variety of approaches to NDCL have been implemented. Christeson et al. (U.S. Pat. No. 5,579,522) teach a computer system having two update modes, normal and recovery, selectable from outside the computer's enclosure using a hardware jumper. In a normal update mode, an operating system is transferred to and caused to execute in volatile random access memory. The system's BIOS and flash memory may be used in this initialization. An update program is then executed within the operating system, providing a user with update selections to save, verify or update nonvolatile memory areas, including the system BIOS or flash memory. A recovery update mode causes a special recovery BIOS to be executed in the event that the normal BIOS has been corrupted, thereby overwriting the normal BIOS of a computer system. The normal mode of Christeson is a variety of NDCL that Gabel (U.S. Pat. No. 5,930,504) characterizes as teaching that procedures for updating a logical area within a system may reside within that same logical area; in order to avoid change or corruption during an update process if they were to remain in the affected logical area, however, those procedures are protected by copying them to a safe system memory area from which they execute the update. The recovery mode of Christeson is clearly disruptive, requiring a reboot of the system after a manual change in a hardware jumper setting. In the context of a telecommunications switching system, Nilsson et al. (U.S. Pat. No. 5,410,703) teach maintaining an old software version effectively in parallel with a new version, gradually switching traffic over to the new version. Ishii et al. (U.S. Pat. No. 5,835,761) discuss performance improvements during NDCL that can be achieved by first copying the new code version into a shadow area of fast memory.
The parameters and variables required to keep the system operational must be preserved through a nondisruptive code load. The patent of O'Brien et al. (U.S. Pat. No. 6,141,771) teaches copying a trusted machine state to a second portion of memory, reinitializing some portion of memory that does not include the trusted machine state, and then restoring the trusted machine state to either the original memory area or to a new memory area. O'Brien et al. also allude to an alternative method of preserving a trusted machine state, one that avoids initializing the portion of memory that contains that state; no specific structure or process for reinitializing the system is described, however, for this alternative method, which is not the focus of their invention.
The central concept of the present invention is an executable self-modifying copier, resident in runtime memory. Runtime memory is an area of a digital device from which a processor reads instructions. The word “memory” is being used generically here to include a medium to which instructions can be written and then later written over, such as random access memory or disk storage. Runtime memory might be volatile random access memory, or it could be nonvolatile firmware so that its contents will not be erased when the system is shut down and restarted. The invention applies equally to either alternative. Henceforth without loss of generality this document will describe a single area of runtime memory, while in fact a given system may have a plurality of areas of runtime memory that exploit the benefits of the invention.
The runtime memory has some structure or format that the executing code requires to function properly. For example, the executing code might access within memory certain parameters or variables about the state of the system. For example, within a digital camera, a typical state variable is an aperture setting. The logic requires these variables to be found in portions of runtime memory whose locations are usually known and constant. Another example of a required format within runtime memory is the start of the code that executes when the system is initialized (i.e., rebooted). The structure of runtime memory, therefore, typically consists of a plurality of segments. Both the old version and the new version of what occupies that memory, namely the old runtime version before the update and the new runtime version afterwards, will be some combination taken from code modules, data modules, and modules that combine both code and data. The data might consist of system parameters, but in general it can be virtually anything that can be represented digitally, such as statistical data, transactional data, images, or music.
In one embodiment of the invention, the new version is first loaded into a shadow area of memory. It will often be the case that the memory in the shadow area will have faster and more robust performance than some external medium, such as slow disk, containing the new code version. Thus, the preliminary shadowing operation will both shorten the process of upgrading and reduce the risk of errors. We will refer to the area from which the new version is transferred as the source area, which might be shadow memory or any other medium.
If the arrangement of the segments in the runtime area is unchanging through every upgrade, then the process of copying the new version is fairly straightforward, consisting essentially of copier instructions in the runtime memory superposing segments of the new version into corresponding segments containing the old version. In other words, the copier could be static, and would typically itself occupy a code segment. The copying process in this case is not entirely trivial, however, because consideration must be given to currently executing processes, system interrupts occurring while the transfer is occurring, and so forth.
If, on the other hand, the structure of the runtime area must be changed with the new version, then the upgrade process can be significantly more complicated if it is done in place, that is, by directly overwriting the runtime area. Such a structural modification might include, for example, one or more of the following: a change in the starting address of a segment; a change in the ending address of a segment; the addition of a new code or data segment; and the deletion of an existing code or data segment. The structural modification could obviously leave some segments intact, although the content (i.e., code or data) of such segments might change with the upgrade.
In general, a static copier within the runtime area would not contain logic to anticipate how the segments might be rearranged in the next upgrade iteration, nor, indeed, all succeeding ones. Consequently, there is a puzzle regarding how the processor can execute code in the runtime area that effects the structural change, when the nature of the desired change is embodied only in the new version, residing in the typically nonexecutable source area.
The solution employed by the present invention is for a runtime area copier module to consist of two parts: a bootstrapper and a dynamic copier part. The content of the bootstrapper will typically, but not necessarily, be static through upgrades, while the dynamic copier part has the opportunity to change from one runtime version to the next. Two essential functions of the bootstrapper are to copy the new version of the dynamic copier part into runtime memory and to cause the new dynamic copier part to begin execution. In one embodiment of the invention, the bootstrapper will have fixed start and ending addresses in the runtime area, while the dynamic part (which will be replaced and typically overwritten during the NDCL) will have a fixed start address. In some embodiments, the entire copier will reside within a runtime memory segment having fixed starting and ending addresses, with enough space available for the dynamic part of the copier to expand within the segment over a number of anticipated upgrade cycles. Instructions within the new dynamic part of the copier, once loaded into runtime memory and executed, will produce the intended runtime area structural change and load in the remainder of the new version of code and data.
The content of the bootstrapper can remain static in either of two ways. One alternative is for instructions in the static copier part of runtime memory to be overwritten with identical instructions from the source region as the copier executes. This approach has an advantage of simplicity, in that the entire runtime version is overwritten. The second alternative is for the copier to only overwrite its dynamic part, which will be faster, although usually only slightly faster, than a complete overwrite. Performance of the copier can be improved by the utilization of a processor instruction cache, when available. The processor instruction cache can also facilitate changes to the bootstrapper part of the copier.
In some embodiments of the invention, state information about the system is stored in a trusted system state segment that is left untouched during upgrades of the executable code. The trusted system segment will have fixed start and end addresses. In some embodiments, the copying process involves decompression, decryption, or other similar operations being applied to some or all of the information being copied.
The present invention provides an apparatus and method for installing executable code or data in a manner that is non-disruptive to the system, so that the system is able to continue operating without the need to sacrifice any system down time.
The upgrade process includes copying a new version 101 of runtime area content (hereinafter, “new version”) from a source area 111 into the runtime area 110, replacing portions of the old version 100, but not any fixed content modules 115. It is well-known in the art that other steps and other components will typically be involved for a code upgrade to be done nondisruptively. The scope of the invention encompasses any such ancillary steps and components when used in combination with core concepts of the present invention.
The source area 111 could be located internally within the system 105, or it might be external. The large outer rectangle in the
The new version 101 might have a collection of modules that are in correspondence with the original modules. For example, every old code module could have a corresponding new code module, and conversely. This need not be the case, however.
The invention accomplishes the upgrade, including any concomitant runtime area 110 restructuring, using a self-modifying copier 120. At the start of the upgrade process, there are two versions of the copier 120, an old copier module 130 within the runtime area 110, and a new copier module 131, within the source area 111.
In the embodiment of the invention illustrated in
The new copier dynamic part 151 contains logic for loading the new runtime content version 101 into the runtime area 110, including any restructuring required within the runtime area 110 to accommodate the various modules of the new version 101. For convenience, we will exclude the new version of the copier 120 from the term new runtime content version 101. Logic in the modules in the runtime area 110 can consequently be ignorant about how the runtime area 110 might be reconfigured during an upgrade. In effect, the old copier module 130 knows how to kick off the upgrade process and the new copier module 131, specifically the new copier dynamic part 151, takes over from there. In
The new copier module 131 might also include a new bootstrapper 141. The fact that a new bootstrapper 141 is optional is suggested in
Referring now to
In the embodiment illustrated by
In the exemplary embodiment, the old copier module 130 is divided into an old bootstrapper 140 and an old copier dynamic part 150. The old bootstrapper 140 has static start and end addresses, contained in memory extending up to the start of the old copier dynamic part 150. Because, in this embodiment of the invention, the bootstrapper remains unchanged through the upgrade, the copier expansion area 250 is exclusively dedicated to potential expansion of the copier dynamic part.
A few things are worthy of notice in the source area 111. The sizes of the new copier dynamic part 151, the new code module 161, and the new data module 171 differ from their respective counterparts in the old runtime content version 100. On the other hand, the new bootstrapper 141 is identical in size to the old bootstrapper 140 because it is identical in content. Each content module in the source area 111 would be copied into the runtime area 110, beginning at the start address of the corresponding memory section there. In this configuration, the old copier module 130 would entirely overwrite itself with the new copier module 131 during the upgrade process.
Even in the relatively simple embodiment shown in
In step 360, which is an optional step that has been included in this particular embodiment, the copier 120 decompresses some or all of the modules of the new runtime content version 101. Note that this step might be done at alternative locations in the flowchart. For example, the new copier module 131 might be decompressed by the old bootstrapper 140 between steps 320 and 330. Decompression might be done all at once, or it might be done in smaller bits; for example, code might be decompressed on the fly, one instruction at a time. In fact, steps that are presented for convenience of illustration as sequential in the flowchart might actually occur together in a single step; for example, steps 360 and 370 might be carried out in combination or in parallel. In certain embodiments, some modules within the new runtime content version 101 will need decompression but not others. Analogously to decompression 360, steps (not shown) might be added to the process for decoding or decrypting various modules of the new runtime content version 101, with similar configuration flexibility. Of course, such secondary processes as decompression, decoding, and decryption might not be required at all in some embodiments. In step 370, the new copier dynamic part 151, now resident itself within the runtime area 110, copies the remainder of the new runtime content version 101 modules from the source area 111 to the runtime area 110, reconfiguring the runtime area 110 appropriately.
The discussion so far has not addressed details regarding treatment of cache 400 that might be available to the processor 108. A processor 108 might have instruction cache 410, data cache 420, or, as illustrated by
Despite some perils for the unwary described below, the availability of instruction cache 410 offers advantages in terms of processor 108 performance and a safe area where a small piece of code such as the old bootstrapper 140 can execute. This approach allows the old bootstrapper 140 to conveniently overwrite and even modify itself during the upgrade.
The availability, types, and implementation of cache 400 tend to be specific to a family of processors 108, or even to a single processor 108 model.
The process starts 500 with the new version being staged 510 into a source area 111, which in this embodiment is a shadow area within fast memory to improve performance. In step 515, the old bootstrapper 140 is placed within instruction cache 410. This can be done manually by loading and locking the instruction cache 410, or automatically if the system 105 provides a command to cause the processor 108 to do so according to algorithms of the processor 108. The old bootstrapper 140 within the instruction cache 410 will typically be an instruction loop adapted to copying the new bootstrapper 141 and the new copier dynamic part 151 from the source area 111 into the runtime area 110. Execution of the old bootstrapper 140 is initiated in step 520. In addition to better processor 108 performance, having the old bootstrapper 140 within the instruction cache 410 in effect allows the bootstrapper to be conveniently modified as it overwrites 530 the runtime area 110 copy of itself. Next, the old copier dynamic part 150 is replaced 540 by the new copier dynamic part 151 by being partly or wholly overwritten.
Because the copier 120 is self-modifying code, the distinction between “data” and “instructions” is obscured. Because processors 108 are often configured under the assumption that they will not be overwriting their own instruction set, many processors 108 will behave as if the new version 101 being copied from the source area 111 is data, not instructions. Unless the data cache 420 has been disabled (which may be preferable), the processor 108 might copy at least some portion of the new version 101 into its data cache 420 for faster availability of the “data”. Code in the data cache 420 is not in the runtime area 110, where it is needed for completion of the upgrade. Flushing 545 the data cache 420 fixes this problem, returning the instructions contained therein to the memory of the runtime area 110.
Because the instruction cache 410 still contains the old bootstrapper 140, a command is issued to invalidate 547 the contents of the instruction cache 410, which forces the processor 108 to fetch its instructions from runtime area 110 memory, hence refreshing itself and initiating execution of the new copier dynamic part 151. The system 105 typically provides specific assembly level instructions for operations such as loading and invalidating the instruction cache 410 and for disabling and flushing the data cache 420. As in
The present invention is not limited to all the above details, as modifications and variations may be made without departing from the intent or scope of the invention. For example, the functionality of the tracking camera could be split between two cameras, one dedicated to viewing presets and the other to tracking movement of a presenter, without departing from the central concept of integrating preset sensing zones with tracking away from those zones. As another example, other forms of devices might be used to configure a controller. Consequently, the invention should be limited only by the following claims and equivalent constructions.