Abstract:
A method for managing system firmware in a data processing system having a plurality of logical partitions is provided. Responsive to a request to update the system firmware from a first logical partition within the plurality of logical partitions in the data processing system, a determination is made whether the first logical partition within the plurality of logical partitions is present in the data processing system. Responsive to the determination that the first logical partition within the plurality of logical partitions is present in the data processing system, the system firmware is updated from the first logical partition in the data processing system. Then starting of additional partitions within the plurality of logical partitions in the data processing system is inhibited until the firmware update from the first logical partition is complete.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Technical Field  
           [0002]    The present invention relates generally to an improved data processing system and in particular to a method and apparatus in a symmetrical multiprocessing system. Still more particularly, the present invention provides a method and apparatus for updating a processor system firmware in a symmetrical multiprocessing system.  
           [0003]    2. Description of Related Art  
           [0004]    A logical partitioning option (LPAR) within a data processing system (platform) allows multiple copies of a single operating system (OS) or multiple heterogeneous operating systems to be simultaneously run on a single data processing system platform. A partition, within which an operating system image runs, is assigned a non-overlapping subset of the platform&#39;s resources. These platform allocable resources include one or more architecturally distinct processors with their interrupt management area, regions of system memory, and I/O adapter bus slots. The partition&#39;s resources are represented by its own open firmware device tree to the OS image.  
           [0005]    Each distinct OS or image of an OS running within the platform are protected from each other such that software errors on one logical partition can not affect the correct operation of any of the other partitions. This is provided by allocating a disjoint set of platform resources to be directly managed by each OS image and by providing mechanisms for ensuring that the various images can not control any resources that have not been allocated to it. Furthermore, software errors in the control of an operating system&#39;s allocated resources are prevented from affecting the resources of any other image. Thus, each image of the OS (or each different OS) directly controls a distinct set of allocable resources within the platform.  
           [0006]    One method that has been developed to create and maintain separation between the partitions within the data processing system is the use of a firmware component referred to as a hypervisor in the RS/6000 data processing system. The RS/6000 is a product and trademark of International Business Machines Corporation of Armonk, N.Y. This firmware component performs many functions and services for the various operating system images running within the logically partitioned data processing system.  
           [0007]    In the earliest initial power load (IPL) stage, system firmware must perform hardware discovery of the input/output (I/O) subsystem, then initialize and assign system address ranges according to the system memory map for the presenting hardware. Data structures are established and updated when the discovery and initialization are complete.  
           [0008]    Later, in the open firmware stage of the IPL, the open firmware must create its open firmware device tree based on the current hardware in the system. Thus, the open firmware must repeat the discovery of hardware components and store a data structure to describe the hardware.  
           [0009]    Finally, in the last stage of the IPL, the runtime abstraction service (RTAS) firmware needs to know the hardware information so that it can provide services to the operating system during runtime. RTAS also analyzes and isolates hardware problems when the system encounters some error exceptions during runtime. RTAS must also perform the discovery process and create a data structure to describe the hardware.  
           [0010]    With the need for more and more processing power, symmetrical multiprocessing (SMP) systems are being used more often. SMP is a computer architecture in which multiple processors share the same memory, containing one copy of the operating system, one copy of any applications that are in use, and one copy of the data. SMP reduces transaction time because the operating system divides the workload into tasks and assigns those tasks to whatever processors are free.  
           [0011]    SMP systems often times experience failures. Sometimes these failures are so-called hard or solid errors, from which no recovery is possible. A hard error in a SMP system, in general, causes a system failure. Thereafter, the device that has caused the hard error is replaced. On the other hand, a number of failures are recoverable or so-called soft errors, which occur intermittently and randomly. In contrast to a hard error, a soft error, with proper recovery and retry design, can be recovered and prevent a SMP system from failing. Often these soft errors are localized to a particular processor within a SMP system.  
           [0012]    When a Regatta machine is configured to run in the LPAR mode, an update of the System Firmware has to be performed without causing data loss to any running partition of the machine. One method to avoid data loss to any running partition is to reboot the system in a non-LPAR or SMP mode and then perform the update process. However, this may not be desirable since running partitions have to be shut down for the reboot to occur. Therefore, it would be advantageous to have a method and apparatus for updating system firmware when multiple partitions are run to reboot in LPAR mode wherein the partition with service authority updates the firmware.  
         SUMMARY OF THE INVENTION  
         [0013]    The present invention provides a method for managing system firmware in a data processing system having a plurality of logical partitions. Responsive to a request to update the system firmware from a first logical partition within the plurality of logical partitions in the data processing system, a determination is made whether the first logical partition within the plurality of logical partitions is present in the data processing system. Responsive to the determination that the first logical partition within the plurality of logical partitions is present in the data processing system, the system firmware is updated from the first logical partition in the data processing system. Then starting of additional partitions within the plurality of logical partitions in the data processing system is inhibited until the firmware update from the first logical partition is complete.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]    The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:  
         [0015]    [0015]FIG. 1 depicts a block diagram of a data processing system in which the present invention may be implemented;  
         [0016]    [0016]FIG. 2 depicts a block diagram of an exemplary logically partitioned platform in which the present invention may be implemented;  
         [0017]    [0017]FIG. 3 is a block diagram of a firmware arrangement in accordance with a preferred embodiment of the present invention; and  
         [0018]    [0018]FIG. 4 illustrates a flowchart of the operation of a updating firmware in a logically partitioned machine in accordance with a preferred embodiment of the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0019]    With reference now to the figures, and in particular with reference to FIG. 1, a block diagram of a data processing system in which the present invention may be implemented is depicted. Data processing system  100  may be a symmetric multiprocessor (SMP) system including a plurality of processors  101 ,  102 ,  103 , and  104  connected to system bus  106 . For example, data processing system  100  may be an IBM RS/6000, a product of International Business Machines Corporation in Armonk, N.Y., implemented as a server within a network. Alternatively, a single processor system may be employed. Also connected to system bus  106  is memory controller/cache  108 , which provides an interface to a plurality of local memories  160 - 163 . I/O bus bridge  110  is connected to system bus  106  and provides an interface to I/O bus  112 . Memory controller/cache  108  and I/O bus bridge  110  may be integrated as depicted.  
         [0020]    Data processing system  100  is a logically partitioned data processing system. Thus, data processing system  100  may have multiple heterogeneous operating systems (or multiple instances of a single operating system) running simultaneously. Each of these multiple operating systems may have any number of software programs executing within in it. Data processing system  100  is logically partitioned such that different I/O adapters  120 - 121 ,  128 - 129 ,  136 , and  148 - 149  may be assigned to different logical partitions.  
         [0021]    Thus, for example, suppose data processing system  100  is divided into three logical partitions, P 1 , P 2 , and P 3 . Each of I/O adapters  120 - 121 ,  128 - 129 ,  136 , and  148 - 149 , each of processors  101 - 104 , and each of local memories  160 - 164  is assigned to one of the three partitions. For example, processor  101 , memory  160 , and I/O adapters  120 ,  128 , and  129  may be assigned to logical partition P 1 ; processors  102 - 103 , memory  161 , and I/O adapters  121  and  136  may be assigned to partition P 2 ; and processor  104 , memories  162 - 163 , and I/O adapters  148 - 149  may be assigned to logical partition P 3 .  
         [0022]    Each operating system executing within data processing system  100  is assigned to a different logical partition. Thus, each operating system executing within data processing system  100  may access only those I/O units that are within its logical partition. Thus, for example, one instance of the Advanced Interactive Executive (AIX) operating system may be executing within partition P 1 , a second instance (image) of the AIX operating system may be executing within partition P 2 , and a Windows 2000 operating system may be operating within logical partition P 1 . Windows 2000 is a product and trademark of Microsoft Corporation of Redmond, Wash.  
         [0023]    Peripheral component interconnect (PCI) Host bridge  114  connected to I/O bus  112  provides an interface to PCI local bus  115 . A number of Input/Output (I/O) adapters  120 - 121  may be connected to PCI bus  115 . Typical PCI bus implementations will support between four and eight I/O adapters (i.e. expansion slots for add-in connectors). Each I/O Adapter  120 - 121  provides an interface between data processing system  100  and input/output devices such as, for example, other network computers, which are clients to data processing system  100 .  
         [0024]    An additional PCI host bridge  122  provide an interface for an additional PCI bus  123 . PCI bus  123  is connected to a plurality of PCI I/O adapters  128 - 129  by a PCI bus  126 - 127 . Thus, additional I/O devices, such as, for example, modems or network adapters may be supported through each of PCI I/O adapters  128 - 129 . In this manner, data processing system  100  allows connections to multiple network computers.  
         [0025]    A memory mapped graphics adapter  148  may be connected to I/O bus  112  through PCI Host Bridge  140  and EADS  142  (PCI-PCI bridge) via PCI buses  141  and  144  as depicted. Also, a hard disk  150  may also be connected to I/O bus  112  through PCI Host Bridge  140  and EADS  142  via PCI buses  141  and  145  as depicted. EADS is the IBM internal name of a chip which provides  8  PCI-PCI bridges that support hot plugging of PCI adapters on the secondary buses.  
         [0026]    A PCI host bridge  130  provides an interface for a PCI bus  131  to connect to I/O bus  112 . PCI bus  131  connects PCI host bridge  130  to the service processor mailbox interface and ISA bus access pass-through logic  194  and EADS  132 . The ISA bus access pass-through logic  194  forwards PCI accesses destined to the PCI/ISA bridge  193 . The NV-RAM storage is connected to the ISA bus  196 . The Service processor  135  is coupled to the service processor mailbox interface  194  through its local PCI bus  195 . Service processor  135  is also connected to processors  101 - 104  via a plurality of JTAG/I 2 C buses  134 . JTAG/I 2 C buses  134  are a combination of JTAG/scan busses (see IEEE 1149.1) and Phillips I 2 C busses. However, alternatively, JTAG/I 2 C buses  134  may be replaced by only Phillips I 2 C busses or only JTAG/scan busses. All SP-ATTN signals of the host processors  101 ,  102 ,  103 , and  104  are connected together to an interrupt input signal of the service processor. The service processor  135  has its own local memory  191 , and has access to the hardware op-panel  190 . JTAG stands for Joint Test Action Group. This group created the foundation for IEEE 1149.1 standard describing the Test Access Port and Boundary Scan Architecture. I 2 C stands for Inter-IC which is a bus interface specification invented by Philips.  
         [0027]    When data processing system  100  is initially powered up, service processor  135  uses the JTAG/scan buses  134  to interrogate the system (Host) processors  101 - 104 , memory controller  108 , and I/O bridge  110 . At completion of this step, service processor  135  has an inventory and topology understanding of data processing system  100 . Service processor  135  also executes Built-In-Self-Tests (BISTs), Basic Assurance Tests (BATs), and memory tests on all elements found by interrogating the system processors  101 - 104 , memory controller  108 , and I/O bridge  110 . Any error information for failures detected during the BISTs, BATs, and memory tests are gathered and reported by service processor  135 .  
         [0028]    If a meaningful/valid configuration of system resources is still possible after taking out the elements found to be faulty during the BISTs, BATs, and memory tests, then data processing system  100  is allowed to proceed to load executable code into local (Host) memories  160 - 163 . Service processor  135  then releases the Host processors  101 - 104  for execution of the code loaded into Host memory  160 - 163 . While the Host processors  101 - 104  are executing code from respective operating systems within the data processing system  100 , service processor  135  enters a mode of monitoring and reporting errors. The type of items monitored by service processor include, for example, the cooling fan speed and operation, thermal sensors, power supply regulators, and recoverable and non-recoverable errors reported by processors  101 - 104 , memories  160 - 163 , and bus-bridge controller  110 .  
         [0029]    Service processor  135  is responsible for saving and reporting error information related to all the monitored items in data processing system  100 . Service processor  135  also takes action based on the type of errors and defined thresholds. For example, service processor  135  may take note of excessive recoverable errors on a processor&#39;s cache memory and decide that this is predictive of a hard failure. Based on this determination, service processor  135  may mark that resource for deconfiguration during the current running session and future Initial Power Loads (IPLs). IPLs are also sometimes referred to as a “boot” or “bootstrap”.  
         [0030]    Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 1 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.  
         [0031]    [0031]FIG. 2 is a block diagram of an exemplary logically partitioned platform is depicted in which the present invention may be implemented. The hardware in logically partitioned platform  200  may be implemented as, for example, server  100  in FIG. 1. Logically partitioned platform  200  includes partitioned hardware  230 , Open Firmware/Hypervisor  210 , and operating systems  202 - 208 . Operating systems  202 - 208  may be multiple copies of a single operating system or multiple heterogeneous operating systems simultaneously run on platform  200 .  
         [0032]    Partitioned hardware  230  includes a plurality of processors  232 - 238 , a plurality of system memory units  240 - 246 , a plurality of input/output (I/O) adapters  248 - 262 , and a storage unit  270 . Each of the processors  242 - 248 , memory units  240 - 246 , NV-RAM storage  298 , and I/O adapters  248 - 262  may be assigned to one of multiple partitions within logically partitioned platform  200 , each of which corresponds to one of operating systems  202 - 208 .  
         [0033]    Open Firmware/Hypervisor  210  performs a number of functions and services for operating system images  202 - 208  to create and enforce the partitioning of logically partitioned platform  200 . Firmware is “software” stored in a memory chip that holds its content without electrical power, such as, for example, read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), and non-volatile random access memory (non-volatile RAM).  
         [0034]    Open Firmware/Hypervisor  210  is a firmware implemented virtual machine identical to the underlying hardware. Thus, Open Firmware/Hypervisor  210  allows the simultaneous execution of independent OS images  202 - 208  by virtualizing all the hardware resources of logically partitioned platform  200 . Open Firmware/Hypervisor  210  may attach I/O devices through I/O adapters  248 - 262  to single virtual machines in an exclusive mode for use by one of OS images  202 - 208 .  
         [0035]    At startup, in the earliest initial power load (IPL) stage, the system firmware must perform the hardware discovery of the I/O subsystem, then initialize and assign system address ranges according to the system memory map for the presenting hardware. Data structures are established and updated when the discovery and initialization are complete.  
         [0036]    The present invention provides a mechanism to support flash_update and reboot RTAS call from an operating system to perform system firmware update in a LPAR capable machine. In LPAR mode, the mechanism is carried out in a hypervisor code. The hypervisor may enforce protection to make sure that the partition with service authority only performs this specific function. Before the mechanism is to be executed, a partition manager may be informed not to start any new partitions so that the service authorized partition may complete the system firmware update and safely reboot the machine.  
         [0037]    [0037]FIG. 3 is a block diagram of a firmware arrangement in accordance with a preferred embodiment of the present invention. System firmware (FW)  310  performs hardware discovery in the earliest IPL stage and creates data structures in system firmware working area  352  of system memory  350 .  
         [0038]    In the open firmware stage of the IPL, system firmware  310  provides data structure address  312  to open firmware  320  through interface (IF)  314 . Open firmware  320  then creates a copy of the data structures from system firmware  310  into open firmware working area  354  of system memory  350 .  
         [0039]    In the hypervisor firmware stage of the IPL, open firmware  320  provides data structure address  328  to hypervisor firmware  326  through interface  330 . Hypervisor firmware  326  then creates a copy of the data structures from open firmware  320  into hypervisor firmware working area  356  of system memory  350 .  
         [0040]    When a RTAS firmware component is instantiated, hypervisor firmware  326  provides data structure address  328  to RTAS firmware  340  through interface  330 . RTAS firmware  340  then creates a copy of the data structures from hypervisor firmware  326  into RTAS firmware working area  358  of system memory  350 .  
         [0041]    [0041]FIG. 4 illustrates a flowchart of the operation of a updating firmware in a logically partitioned machine in accordance with a preferred embodiment of the present invention. In this example, the operation begins by an operating system performing a flash update (step  402 ). Then a reboot is made by a RTAS call (step  404 ). The RTAS then determines the executing environment (step  406 ). Then a determination is made as to whether or not the executing environment is in a non_LPAR mode (step  408 ). If the executing environment is in a non-LPAR mode (step  408 :YES), then the SMP is executed using a path RTAS code (step  410 ) and thereafter the operation terminates.  
         [0042]    If the executing environment is not in a non_lpar mode (step  408 :NO), the hypervisor is directed to direct the flash update (step  412 ). The hypervisor is then directed to direct the reboot function (step  414 ). Then a determination is made as to whether or not a hypervisor code possesses service authority (step  416 ).  
         [0043]    If the hypervisor code does not possess service authority (step  416 :NO), a mailbox is sent a request to shut down the partition (step  418 ) and thereafter the operation terminates. If the hypervisor code does possess service authority (step  416 :YES), a flag is set to direct a partition manager to refrain from starting a new partition (step  420 ). Then a determination is made as to whether or not additional partitions are running (step  422 ). If additional partitions are not running (step  422 :NO), new system hardware is flashed (step  428 ). Then a mailbox request is sent to reboot the system (step  430 ) and thereafter the operation terminates. If additional partitions are not running (step  422 :NO), the flag is cleared to allow a new partition to start (step  424 ). Then a request is sent to reboot the partition when the operating system is enabled (step  426 ) and thereafter the operation terminates.  
         [0044]    Thus, the present invention solves the disadvantages of the prior art by providing a method and apparatus for updating system firmware when multiple partitions are run to reboot in LPAR mode wherein the partition with service authority updates the firmware. An operating system may reboot in LPAR mode when a partition with service authority updates the firmware and no additional partitions may be started until the firmware update occurs.  
         [0045]    It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such as a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.  
         [0046]    The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.