Abstract:
A system, method, and apparatus according to an embodiment of the invention uses a processor to transfer information from a first device to a common area. The information is then transferred from the common area to a second device, thereby bypassing restrictions that may impede a transfer of the information directly from the first device to the second device. In an exemplary implementation, a PCI card initiates the transfer of information from a video frame buffer of an AGP video card to a memory buffer on the PCI card, using an interrupt handler loaded during configuration of the PCI bus.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to the transfer of information from one device to another. Specifically, this invention relates to the transfer of information from a first device to a second device, when access by the second device to the first device is restricted. 
     2. Description of Related Art and General Background 
     A computer  100   a  as shown in FIG. 1 comprises a processor  110  and memory  120 . Processor  110  may comprise one or more microprocessors, for example, while memory  120  may comprise semiconductor memory (read-only memory (ROM) and/or random-access memory (RAM)) arranged in one or more hierarchical levels (e.g. Level 1 cache, Level 2 cache, main memory, Basic Input/Output System (BIOS)). 
     A computer supports input of information from and/or output of information to one or more peripheral hardware devices  200   a ,  200   b ,  200   c . Examples of such devices include video displays; keyboards; devices for input and/or output of audio and/or video; and interfaces for networks, secondary storage media such as disk and/or tape drives, printers, and the like. Several such devices may be linked to the computer through a system bus  300 , which may be a PCI (Peripheral Connect Interface) bus as defined by PCI Local Bus Specification, rev. 2.2, PCI Special Interest Group, Hillsboro, Oreg. These devices may be either integrated into the computer or may be removably connected to system bus  300  having a system bus controller  310  (see FIGS. 1 and 2) through a bus connector provided on the device. 
     It is desirable in many instances for a computer to operate as expected even when it is unattended (i.e. even when a user is not present to control the computer directly through its console). For example, a user may schedule a large computational task to execute overnight. Alternatively, the computer may be connected to a network as a server, operating largely unattended while it supports applications and/or communications for a number of client machines. 
     When an unattended computer fails to function as desired, it may be inconvenient or impossible for a technician to reach the console immediately in order to diagnose and correct the problem, and the resulting downtime may be costly. To enable timely and effective system management, it is desirable to be able to monitor the operation of a computer from a remote location. Specifically, it is desirable to be able to view the video output of a computer remotely. 
     One form of a peripheral device that supports a limited remote capability for a computer  100   a  as shown in FIG. 1 is a remote monitoring device (RMD)  200   a . Such a device  200   a  connects to system bus  300  as shown in FIG.  1  and transmits information to a remote user over a telephone line (not shown). RMD  200   a  may be equipped with its own processor, allowing it to operate independently of host processor  110  and access information stored on video controller  200   b  directly over system bus  300 . 
     It is desirable to use a local bus to support high-bandwidth transfers of information such as video output. One example of such a bus is the Accelerated Graphics Port (AGP) bus as defined in AGP Specification, rev. 2.0, May 4, 1998, Intel Corp. (Santa Clara, Calif.). A local bus  500  may have a dedicated bus controller  510  as shown in the host computer  100   b  of FIG. 2, or control of the local and system buses may be integrated into a single bus controller  610  (where information exchanged between processor  110  and memory  120  does not pass through the bus controller) or  620  (where information may be exchanged between processor  110  and memory  120  via the bus controller) as shown in FIGS. 3 and 4, respectively. By way of example, controller  620  may be implemented using one among the 440BX, 440LX, 440EX, 440MX,  810 ,  820 , or  840  chipsets manufactured by Intel Corp. (Santa Clara, Calif.), wherein system bus  300  is a PCI bus. 
     Because the local and system buses operate at different speeds, a device on system bus  300  (such as RMD  200   a ) cannot directly access a device on local bus  500 . Moreover, in order to protect the performance of local bus  500 , the bus controller may be designed to block requests for access to devices on the local bus by devices on system bus  300 . Consequently, in a case where the host computer uses a local bus video controller  400  such as an AGP video card or an embedded AGP video device, remotely monitoring the video output of the host computer with a device on system bus  300  has been considered to be impossible without the support of the operating system of computer  100   c ,  100   d . For example, such remote monitoring has been considered to be impossible (1) before an operating system of computer  100   c ,  100   d  boots and (2) after the operating system has crashed. 
     It is desirable for a remote monitoring device on a system bus to be able to access the memory of a video controller on a local bus during substantially all stages of operation of the host computer, including periods during which the host computer&#39;s operating system has not yet loaded, has loaded incorrectly, or has crashed. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a block diagram of a computer having a system bus and a remote monitoring device. 
     FIG. 2 shows a block diagram of a computer having local and system buses and a device on each bus. 
     FIG. 3 shows a block diagram of a computer having local and system buses and a device on each bus. 
     FIG. 4 shows a block diagram of a computer having local and system buses and a device on each bus 
     FIG. 5 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 6 shows a block diagram of a system according to an embodiment of the invention. 
     FIG. 7 shows a block diagram of a system according to an embodiment of the invention. 
     FIG. 8 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 9 shows a partial flow chart of a method according to an embodiment of the invention. 
     FIG. 10 a  shows a block diagram of an apparatus according to an embodiment of the invention. 
     FIG. 10 b  shows a block diagram of an apparatus according to an embodiment of the invention. 
     FIG. 11 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 12 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 13 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 14 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 15 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 16 shows a block diagram of a system according to an embodiment of the invention. 
     FIG. 17 shows a block diagram of a system according to an embodiment of the invention. 
     FIG. 18 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 19 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 20 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 21 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 22 shows a flow chart of a method according to an embodiment of the invention. 
     FIG. 23 shows a flow chart of a method according to an embodiment of the invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 5 shows a flowchart for a method according to an embodiment of the invention. Event P 110  occurs before an operating system of computer  100   c ,  100   d  begins to boot. This event causes processor  110  to begin to execute a specified sequence of program instructions or ‘code’ for transferring information. In executing this code (task P 120 ), processor  110  causes information to be transferred from a device on local bus  500  (e.g. local bus video controller (LBVC)  400 ) to a RAM portion  120   a  of memory  120 . In task P 130 , the information is transferred again from RAM  120   a  to a device on system bus  300  (e.g. RMD  700  as shown in FIGS.  6  and  7 ). In this way, a transfer of information from the device on the local bus to the device on the system bus may be initiated or even completed before an operating system of computer  100   c ,  100   d  begins to boot. 
     Event P 110  may occur periodically, with occurrences being separated by a predetermined number of minutes, seconds, or timer clicks, for example. Alternatively, event P 110  may occur according to a schedule: upon completion of a predetermined stage of the Power-On Self Test (POST), for example, or upon completion of the BIOS initialization of computer  100   c ,  100   d . Alternatively, event P 110  may occur in response to a condition (such as the detection of an error or fault) or an external signal (such as the reception by RMD  700  of a signal sent by a remote user requesting an update of video information from LBVC  400 ). 
     By way of example, FIG. 6 shows the path of the information from local bus video controller (LBVC)  400  to RMD  700  when the method of FIG. 5 is used with host computer  100   c  of FIG.  3 . FIG. 7 shows the same path when this method is used with host computer  100   d  of FIG.  4 . System bus  300  may be a PCI bus or may conform to another established standard such as one of the following: 
     MCA (Micro Channel Architecture), a proprietary standard of IBM Corp. (White Plains, N.Y.); 
     ISA (Industry Standard Architecture) and EISA (Extended ISA), as defined in EISA Specification, Version 3.12, available from BCPR Services, Inc. (Spring, Tex.); 
     a variant of PCI such as Mini PCI or PCI-X, as defined in Mini PCI 1.0 and PCI-X 1.0, respectively, both available from PCI Special Interest Group; 
     VME and VME64, as defined in ANSI/VITA 1-1994 (VITA, Scottsdale, Ariz.), IEEE 1014-1987 (IEEE Standards, Piscataway, N.J.), or ISO/IEC15776 (International Organization for Standardization, Geneva, Switzerland); 
     S-Bus, a proprietary standard of Sun Microsystems (Palo Alto, Calif.); and 
     PC/104, and PC/104-Plus, as defined in PC/104 Specification, version 2.3, June 1996 and PC/104-Plus Specification, version 1.1, June 1997, respectively, both available from PC/104 Consortium, Mountain View, Calif.). 
     FIG. 8 shows one general implementation of the method of FIG. 5, wherein event P 110   a  is the assertion of a designated interrupt of processor  110 , as triggered by event P 110 . The vector or table entry associated with the designated interrupt is preconfigured to direct processor  110  to the starting location of the code for performing task P 120 . This starting location may be within ROM or RAM of memory  120  or within a memory aboard RMD  700 . Configuration of the interrupt may be hard-wired; alternatively, configuration of the interrupt may be achieved, for example, during power-on initialization of computer  100 , system bus  300 , or RMD  700 . 
     In one particular implementation as shown in FIG. 9, configuration of the interrupt occurs during a power-on configuration of system bus  300  (which may be, for example, a dynamically configurable bus such as a PCI bus). During bus configuration, processor  110  loads a block of code from an expansion ROM (or ‘option ROM’) aboard RMD  700  into RAM  120   a  (task P 20  in FIG.  9 ). Processor  110  then executes at least a portion of the block (task P 40 ), thereby configuring the designated interrupt to point to an interrupt service routine (‘ISR’) within the block of code (task P 60 ). This ISR remains resident in RAM  120   a  after the configuration and includes the code for performing task P 120 . Such an implementation allows the method of FIG. 5 to be practiced with an existing computer  100  while avoiding a need to upgrade the computer&#39;s BIOS. Additionally, such implementation allows practice of the method of FIG. 5 to be portable with RMD  700  rather than dependent on the contents of a ROM of computer  100   c ,  100   d.    
     The instructions which processor  110  begins to execute in task P 40  may also cause it to perform other initialization tasks, such as the following: 
     Processor  110  may cause a portion of the memory space of RMD  700  to be mapped to a portion of the memory space of processor  110  to enable transfers from one memory space to the other. Processor  110  may also verify that such transfers may be performed successfully. Additionally, in a case where processor  110  executes within a limited memory space during configuration (e.g. in ‘real mode’ as opposed to a ‘protected mode’ of Intel x86 processors), processor  110  may execute instructions as necessary to obtain access to the mapped memory space. (A similar set of instructions may also be executed as a part of the ISR.) 
     In addition to the designated interrupt, processor  110  may allocate and/or configure other system resources such as input/output addresses for use by RMD  760 . 
     Processor  110  may issue a notification to RMD  700  when configuration of the ISR is completed. 
     Loading the ISR code into RAM  120   a  allows processor  110  to execute the ISR more rapidly than if it remained resident only in the expansion ROM of RMD  700 . Note that the transfer of code from the expansion ROM to RAM  120   a  may include a checksum, decryption, and/or decompression operation or the like, such that the form of the information retrieved from the expansion ROM need not literally correspond to the form of the code stored in RAM  120   a.    
     In other implementations, the ISR may reside in a ROM aboard computer  100   c ,  100   d  (e.g. as a part of the BIOS of computer  100   c ,  100   d ), or in a ROM aboard RMD  700  (e.g. as a part of the expansion ROM), rather than within RAM  120   a.  Alternatively, the ISR may reside in RAM aboard RMD  700 , having been copied from ROM during initialization of computer  100   c,    100   d,  system bus  300 , or RMD  700 . Likewise, the code for configuring the ISR (if required) may be executed from ROM or RAM and may be a part of the BIOS of computer  100   c ,  100   d  or of an expansion ROM aboard RMD  700 . 
     Once task P 120  has been performed, some portion of the information from the local bus device (e.g. LBVC  400 ) is available in RAM  120   a . Processor  110  then performs task P 120  by executing further instructions within the ISR, thereby transferring this portion of the information from RAM  120   a  to RMD  700  (e.g. to an onboard RAM or communications port or buffer) or to another device on system bus  300 . 
     FIG,  10   a  shows an apparatus  700   a  according to an embodiment of the invention, including expansion ROM  720  and bus connector  730  which connects to system bus  300 . As processor  110  may have many other tasks to perform, it is desirable to effect the information transfer with a minimal load on processor  110 . In an alternative implementation including expansion ROM  725 , processor  110  interrupts a processor  710   a  board RMD  700   b  (as shown in FIG. 10 b ) (task P 125  of FIG. 11) and returns from the ISR (possibly after write-protecting the area of RAM  120   a  that stores the portion of the information). Processor  710  then executes an ISR associated with the interrupt asserted by processor  110 , thereby transferring the information from buffer area  120   a  to RMD  700   a  over system bus  300  (task P 130 ) and via bus connector  730 . Processor  110  is thus released to do other work while processor  710  completes the transfer to another storage area (e.g. within RMD  700   a ) and/or to the remote user (e.g. by packetizing the data and forwarding it over a network or telephone line connection). Although hardware restrictions (imposed, for example, by bus controllers  610  and  620 ) may prevent a device on system bus  300  from obtaining the information directly from video controller  400 , this implementation bypasses such restrictions by taking advantage of the features that (1) processor  110  has access to devices on local bus  500  and (2) processors  110  and  710  may both access at least some part of memory  120 . 
     By designating a portion within RAM  120   a  to be the common area, the implementations described above allow processor  110  to perform the transfer to the common area as quickly as possible. However, note that practice of the invention is not limited to the use of RAM  120   a  (or even to the use of a portion of memory  120 ) as the area of common access. 
     Depending on the capacities of area  120   a  and any storage area within RMD  700  that may be used to store transferred information, tasks P 120  and/or P 130  may be executed several times for each block of information (e.g. video frame) transferred. In FIG. 12, for example, buffer area  120   a  is smaller than the area required to store a video frame, so that tasks P 120  and P 130  must be executed more than once to transfer a complete video frame. In task P 140 , processor  710  determines whether a complete video frame has been transferred by, for example, (1) checking to see how many bytes have been transferred so far or (2) checking to see whether processor  110  (or another device such as bus controller  610  or  620 ) has indicated that the entire frame was transferred into buffer area  120   a . Task P 140  may also be performed by processor  110  and/or another device such as bus controller  610  or  620 . 
     FIG. 13 shows a method for a case in which buffer area  120   a  is large enough to accommodate an entire block, but processor  710  does not transfer all of the data in area  120   a  at once (e.g. because of storage limits within RMD  700 , or because of a slow connection to the remote user). In task P 150 , processor  710  determines whether the transfer from area  120   a  is complete by, for example, checking to see how many bytes have been transferred so far. In some implementations, it may be necessary to interrupt processor  710  again before executing task P 130  if the test in task P 150  fails. FIG. 14 shows a method for a case in which the capacity limitations discussed with reference to FIGS. 12 and 13 both apply. 
     In practicing an implementation as described above, it may be desirable to perform several exchanges of information between computer  100   c ,  100   d  and RMD  700 . For example, additional information may be required to interpret data downloaded from a video buffer of LBVC  400  (e.g. information pertaining to screen dimensions and palette size). In one embodiment, separate interrupts of processor  110  may be designated and configured to correspond to different types of information. In an alternative embodiment, processor  710  constructs a message in a shared memory area and asserts the designated interrupt of processor  110 . The corresponding ISR causes processor  110  to access the message and respond accordingly. For remote video monitoring, this message may have one of the following forms: 
     Get video mode: indicate whether screen is in text or graphics mode and/or return number of colors in palette (or pixel depth in bits) 
     Get screen size: indicate number of columns and rows (for text mode) or number of horizontal and vertical pixels (for graphics mode) 
     Get cursor position: indicate screen coordinates of cursor 
     Get video memory contents: return information from video buffer of LBVC  400 . 
     Processor  110  constructs a reply to the message and posts it in the shared memory space. This message may comprise an identifying header followed by the forwarded information. Processor  110  then asserts the designated interrupt of processor  710  to indicate that a message is waiting. Processor  710  retrieves the message for local storage and/or delivery to a remote user. This procedure may be repeated until the desired block of information (along with any ancillary information) has been transferred to RMD  700 . For example, successive messages sent by processor  710  may request successive portions of the desired block of information. 
     FIG. 15 shows a flowchart for a method according to an alternative embodiment of the invention. In this embodiment, the transfer of information from the device on local bus  500  to the device on system bus  300  is accomplished by processor  110  in one action (task P 122 ). FIGS. 16 and 17 show the path of information from LBVC  400  to RMD  700  when this method is used with host computer  100   c  of FIG. 3 (wherein the transferred information passes through processor  110 ) and host computer  100   d  of FIG. 4 (wherein the transferred information does not pass through processor  110 ), respectively. 
     FIG. 18 shows one general implementation of this method, wherein event P 110   a  is the assertion event described above. FIG. 19 shows a particular implementation wherein RMD  700  has a shared memory area (i.e. at least some of the memory of RMD  700  is mapped to a window in the main memory space of processor  110 ). In task P 124 , processor  110  transfers the information from the device on local bus  500  to the shared memory area. When the transfer has completed (or possibly as it continues), processor  110  asserts an interrupt of processor  710  (task P 127 ). In task P 132 , processor  710  executes a transfer of the information out of the shared memory area. The transfer of task P 132  may comprise a transfer into another portion of the memory of RMD  700  (e.g. to make room for another incoming transfer), wherein future processing tasks may include storing the information, forwarding it to the remote user, etc. The transfer of task P 132  may also comprise transmission of the information to the remote user directly from the shared memory area. 
     FIG. 20 shows a method for a case in which the shared memory area is too small to accommodate an entire block, such that tasks P 124  and P 132  must be executed more than once to transfer an entire block. In task P 142 , processor  710  (or another device such as processor  110  or bus controller  610  or  620 ) evaluates the status of the transfer as described above with respect to task P 140 . 
     FIG. 21 shows a method for a case in which the shared memory area is large enough to accommodate an entire block, but processor  710  does not transfer all of the information from it at once (e.g. because of bandwidth limitations). In task P 152 , processor  710  determines whether the transfer from the shared memory area is complete by, for example, checking to see how many bytes have been transferred so far. In some implementations, it may be necessary to interrupt processor  710  again before executing task P 132  if the test in task P 152  fails. FIG. 22 shows a method for a case in which the capacity limitations discussed with reference to FIGS. 20 and 21 both apply. 
     Note that a message mechanism as described above may also be used with implementations of the method of FIG.  15 . For example, processor  710  may construct and post the message before asserting the interrupt of processor  110 . Upon completing the transfer (and possibly posting a reply message), processor  110  may interrupt processor  710  to indicate that the requested information (or some portion of it) is available in the shared memory area. 
     Once an operating system of computer  100   c  begins to load, it is possible that an ISR associated with the designated interrupt of processor  110  will no longer function. If processor  110  is an Intel x86 processor, for example, the BIOS configuration may execute in ‘real mode,’ with processor  110  having access to only a limited portion of its total memory space. Loading the operating system may cause the processor to enter ‘protected mode,’ thereby obtaining a wider access to the memory space but also losing access to the existing ‘real-mode’ interrupt vector configuration. Although the interrupts may then be reconfigured to execute similar ISRs in ‘protected mode,’ a malfunction of the operating system may cause this configuration to become unavailable as well (e.g. by causing the interrupts to be masked). It is desirable for remote monitoring capabilities to remain available during loading of the operating system as well as during and after a malfunctioning of the operating system. 
     A method according to an embodiment of the invention continues to support requests for cross-bus transfers both during and after loading of the operating system (i.e. after processor  110  enters ‘protected mode,’ event P 210  of FIG. 23) by modifying the ISR for a non-maskable interrupt (NMI) of processor  110  (task P 220 ). The NMI, which may be a feature of both Intel and non-Intel processors, is distinguished from other interrupts in that the NMI remains operational when another interrupt line or lines of the processor are masked. 
     Computer  100   c  may use the NMI to indicate certain system conditions, such as a memory parity error. Before asserting the NMI, a device desiring to initiate a cross-bus transfer according to the general implementation will record a transfer request indication in an area that is accessible to processor  110  (task P 230 ). For example, a message constructed by processor  710  as described above may serve as such an indication. 
     Upon assertion of the NMI (event P 240 ), processor  110  begins to execute the modified NMI ISR. In executing this code, processor  110  tests whether a transfer request indication is present (task P 250 ). If no such indication is found, then it is assumed that the NMI was asserted in response to a system condition such as a parity error, and processor  110  is directed to perform tasks relating to the original NMI ISR (task P 270 ). Note that it may be possible to perform task P 270  simply by directing processor  110  to the starting location of the original NMI ISR. If a transfer request indication is found, then processor  110  is directed to perform tasks relating to the requested transfer, as described above (task P 260 ). Note that although these tasks may be similar or even identical to those described above (e.g. with respect to tasks P 120  and/or P 130 ), it may not be possible to direct processor  110  to execute the same code in order to perform those tasks, as that code may be incompatible with a present mode of processor  110 . 
     In a general implementation of a method according to an embodiment of the invention, code for modifying an ISR of a NMI of processor  110  is packaged as a device driver. This driver is loaded by an operating system of computer  100   c  into a RAM portion of memory  120  (e.g. from a ROM, from a hard drive within computer  100   c , or over a network connection) for execution by processor  110 . In executing this code, processor  110  causes the ISR of the NMI to be modified (task P 220 ). 
     It is desirable to restore the availability of cross-bus transfers as quickly as possible after processor  110  enters ‘protected mode’ (event P 210 ). Such availability may be obtained by causing processor  110  to modify the NMI ISR as early as possible in the boot process of the operating system. Different particular implementations may be practiced to obtain such early modification depending on which operating system is booting. For a case in which the operating system is Windows NT™ (Microsoft Corp., Redmond, Wash.), it is possible to cause processor  110  to load and execute the device driver during the phase immediately following firmware execution by declaring the driver to be a ‘system bus extender.’ This declaration may be achieved by configuring the operating system&#39;s registry in computer  100   c  to assign the driver a \Services\DriverName\Start value of SERVICE_BOOT_START (0x0). 
     For a case in which the operating system is Netware (Novell Corp., San Jose, Calif., Provo, Utah), early loading and execution of the configuration driver may be obtained by listing the driver as the first file in startup and in the configuration files of the operating system. In this case it may be necessary to list the driver as a disk driver during linking and to avoid the use of any external libraries during compilation of the driver (i.e. to call only those functions that are native to the operating system). 
     As described above, a system, method, and apparatus according to an embodiment of the invention allows cross-bus transfers of information to be conducted (e.g. as needed to perform remote monitoring of the video output of a computer) regardless of whether the operating system has loaded correctly or at all. Such capabilities as the remote selection of an operating system for booting and the remote execution of command-line repair tools and the like are thereby supported. 
     The foregoing description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments are possible, and the generic principles presented herein may be applied to other embodiments as well. For example, the invention may be implemented in part or in whole as a hard-wired circuit, as a circuit configuration fabricated into an application-specific integrated circuit, or as a firmware program loaded into non-volatile storage or a software program loaded from or into a data storage medium as machine-readable code, such code being instructions executable by an array of logic elements such as a microprocessor or other digital signal processing unit. 
     Note that instead of directly performing one or more of the information transfers indicated in tasks P 120 , P 122 , P 124 , P 130 , and P 132 , processors  110  and/or  710  may also cause these transfers by sending data which identify the source and destination addresses to another device (such as bus controller  610  or  620 ) along with a command to effect the transfer. 
     Although the invention is described principally in terms of allowing remote access to video memory on a local device, the invention may be practiced in many other situations wherein it is desired for a first device peripheral to a host processor to access information stored in or available at a second device peripheral to the host processor, and wherein a direct access of the second device by the first device is prevented or restricted. Thus, the present invention is not intended to be limited to the embodiments shown above but rather is to be accorded the widest scope consistent with the principles and novel features disclosed in any fashion herein.