JP2006277216A - Automatic fw update method for multi-os installable platform - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the setup man-hour of a system while preventing artificial mistakes in a FM (firmware) confirmation or replacement work for OS installation in a multi-OS environment. <P>SOLUTION: This automatic FW update method comprises an installation OS information acquisition means 21 in which a FW 20 acquires OS information from an OS installation medium; a support OS confirmation means 22 in which the FW 20 acquires its own support OS information in reference to an FW support OS information table and compares it with the installation OS information, and when the FW itself is matched to an OS to be installed, startup is instructed to an OS installer starting means 26; an FW switching means 23 in which, when the FW is mismatched, whether an FW matched to the OS to be installed is stored in a ROM or not is retrieved in reference to the table, and when an FW matched to the OS to be installed is stored in a ROM, this FW is switched to an active FW to restart the system; a Web access means 23 in which, when no FW matched to the OS to be installed is stored, an appropriate FW is installed from a FW server to update and restart the table; and an FW installation means 25. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an automatic FW (firmware) update method in a platform capable of installing a multi-OS.

  In recent years, with the opening, an increasing number of servers are capable of mounting different types of OSs on a single computer.

  However, there are cases where the FW that manages the system activation control requires a FW corresponding to each current OS.

  In that case, when installing different types of OSs, it is necessary to always be aware of the FW version that is operating and the FW version corresponding to the OS that is scheduled to be installed.

  Therefore, when setting up a platform on which a plurality of different types of OSs can be installed, it may be necessary to check in advance whether the operating FW is suitable for the OS to be installed. In this case, manual confirmation is common.

  In addition, when the operating FW does not correspond to the OS to be installed, replacement with an appropriate FW is manually performed.

  As described above, confirmation of FW at the time of OS installation and replacement of FW in a multi-OS environment are usually performed manually.

  For this reason, a procedure error at the time of FW replacement, an OS installation error due to not being aware of the FW version in operation, and the like occurred, and it took a great deal of man-hours to set up the system.

  The automatic FW update method in the platform capable of installing the multi-OS according to the present invention is a method in which the FW obtains OS information from the OS installation medium and sets the OS information to be installed, and is stored in the nonvolatile memory. Refer to the support OS information table that holds the OS information and the operation state flag, obtain the corresponding OS information of the FW, compare the two OS information, and if the FW supports the OS to be installed, the OS installer And a means for referring to the support OS information table and confirming whether or not the FW corresponding to the OS to be installed is stored in the ROM when the OS is not compatible with the OS to be installed; If the FW was stored, switch it to the active FW and switch the system If the FW is not stored, if the FW is not stored, the FW server is accessed via the network, the appropriate FW is installed, the support OS information is added to the table, and the FW is Means for installing, switching the operating state of the table to active and restarting the system.

  An effect of the present invention is that in a system in which OSs of different types can be installed, various OSs can be freely installed without the user being aware of the FW version in operation.

  In addition, the frequency of OS installation failures is reduced, and the number of man-hours required for system setup can be reduced.

  The reason is that the FW itself holds support OS information, and by reading the OS information from the installation medium, it is possible to determine whether the FW itself is compatible with the OS to be installed, and the installation is scheduled automatically. This is because it can be replaced with the FW corresponding to the OS.

  Next, the best mode for carrying out the present invention will be described in detail with reference to the drawings.

  Referring to FIG. 1, in one embodiment of the present invention, a ROM 10 storing single or plural types / generations of FW (firmware), an installed OS information obtaining means 21, a support OS confirmation means 22, and an FW switching means. 23, FW 20 provided with Web access means 24, FW installation means 25, OS installer activation means 26, OS installation medium 30 provided with header section 31, NVRAM 40 provided with FW support OS information table 41, and FW list The FW server 50 includes 51 and FW 52, and a network 60 that connects the system and the FW server 50.

  Referring to FIG. 2, the ROM 10 stores a plurality of types of FW 20.

  The installed OS information obtaining unit 21 has a function of reading OS information such as the OS type and version from the header section 31 of the OS installation medium 30 inserted in the medium reading device.

  The support OS confirmation unit 22 has a function of referring to the FW support OS information table 41 stored in the NVRAM 40 and confirming OS information supported by various FWs stored in the ROM 10.

  The FW switching unit 23 has a function of switching an appropriate FW to the Master FW and restarting the system when the operating FW does not correspond to the OS to be installed.

  The Web access unit 24 has a function of accessing the FW server 50 via the Web and searching the FW list 51 in the FW server 50 and downloading the FW and support OS information when there is no FW that supports the OS to be installed in the ROM 10. is doing.

  The FW installation unit 25 has a function of installing the FW downloaded by the Web access unit 24 in the system and storing the latest OS support information in the NVRAM.

  The OS installer starting unit 26 has a function of starting an installer from the OS installation medium 30 inserted in the medium reading device.

  As shown in FIG. 3, the header unit 31 provided in the OS installation medium 30 includes an OS type 311 and a version 312 as OS information.

  Referring to FIG. 2, the FW support OS information table 41 provided in the NVRAM 40 includes the FW file name 411, the FW version 412, the corresponding OS type 413 supported by the FW, its version 414, and the FW active information 415. It is composed of

  The FW file name 411 is a file name of various FWs stored in the ROM 10.

  The Active information 415 stores “ON” if the FW is currently operating, and stores “OFF” if the FW is in a standby state.

  As shown in FIG. 4, the FW list 51 provided in the FW server 50 includes an FW file name 511, an FW version 512, OS information 513 corresponding to the FW, and its version 514.

  The FW 52 is the FW itself listed in the FW list 51.

  Next, the operation of the best mode for carrying out the present invention will be described with reference to the drawings.

  The overall operation of this embodiment will be described in detail with reference to the flowcharts of FIGS. 1 to 4 and FIG. 5.

  First, the FW 20 acquires the OS information to be installed from the OS installation medium 30 inserted in the medium reading device by the installation OS information acquisition unit 21 (step A1).

  Referring to FIG. 2, the header 31 of the OS installation medium 30 includes the OS type and version information. In each field, for example, information such as “Windows (registered trademark) XP” and “build X.xxxyy” is stored.

  Next, the FW 20 obtains OS information supported by the FW 20 from the FW support OS information table 41 stored in the NVRAM 40 by the support OS confirmation unit 22 (step A2 in FIG. 4).

  The FW support OS information table 41 includes information such as the FW version, the support OS type, the support OS version, and whether or not it is operating.

  Here, the OS information supported by the FW file in which “ON” indicating that the FW is currently operating is described in the field Active 415 of the FW support OS information table 41 is obtained.

  Next, the FW 20 compares both pieces of information and confirms whether or not the FW 20 is compatible with the OS to be installed (step A3 and step A4 in FIG. 4).

  If the FW 20 supports the OS, the installer stored in the OS installation medium 30 is activated by the OS installer activation means 26 (step A10 in FIG. 4).

  Thereafter, the OS installation is started and the setup is continued.

  On the other hand, if the FW 20 does not support the OS, a search is made with reference to the support OS information table 41 in the NVRAM 40 to determine whether an appropriate FW is stored in the ROM 10 (step A5 in FIG. 5).

  When an appropriate FW is stored in the ROM 10, the FW switching unit 23 sets the FW active information 415 in the FW support OS information table 41 to “ON”, and the FW active information 415 that has been operating so far. Is changed to “OFF”, the FW is switched to the Master FW, and the system is restarted (step A9 in FIG. 5).

  As a result, the FW corresponding to the OS scheduled to be installed is replaced. On the other hand, if an appropriate FW is not stored, the Web access means 24 accesses the FW server 50 via the network 60, refers to the FW list 51 held by the FW server 50, and supports an appropriate FW. Download OS information to the system.

  Next, the FW 20 installs the downloaded FW in the ROM by the FW installation unit 25 and updates the FW support OS information table 41.

  When the installation of FW and the update of the FW support OS information table are completed, the FW switching unit 23 sets the Active information 415 of the FW in the FW support OS information table 41 to “ON” in the same manner as described above. After the FW Active information 415 is changed to “OFF”, the FW is switched to the Master FW and the system is restarted (step A9 in FIG. 4).

  As a result, the FW corresponding to the OS to be installed is replaced, and the OS installation is started without any problem.

  The operation of this embodiment will be described using a specific example.

  Referring to FIG. 3, the installation medium header 31 stores “Windows (registered trademark) XP” as the OS type 311 and “X.xxxyy” as the version 312. In step A1, these pieces of information are obtained.

  Next, in step A2, OS information supported by the currently operating FW 20 is obtained from the FW support OS information table 41 shown in FIG.

  Here, the corresponding OS type, “HP-UX”, OS version, and “Y.yyyyyy” of the FW and FWbbb in which “ON” indicating that the Active information 415 is in operation are stored are obtained.

  Next, in steps A3 and A4, both OS types and OS versions are compared. In the specific example, the OS scheduled to be installed is “Windows (registered trademark) XP” and the OS supported by the operating FW 20 is “HP-UX”. Therefore, the OS to be installed corresponds to the operating FW 20. The operating system type does not match.

  Therefore, in step A5, the FW support OS information table 41 is referred to and it is confirmed whether or not the FW that supports the installation scheduled OS type “Windows (registered trademark) XP” is stored in the ROM 10.

  Referring to the FW support OS information table 41 in FIG. 2, it is found that no FW that supports “Windows (registered trademark) XP” is stored in the ROM 10.

  Next, in step A7, the FW server 50 is searched for web access for an appropriate FW. Referring to the FW list 51 held by the FW server 50, the corresponding OS type, “Windows (registered trademark) XP”, and the corresponding OS version, FW that supports “X.xxxyy”, FWA. It turns out that there is aaa.

  The FW and support OS information are temporarily downloaded into the system memory.

  Next, in step A8, the downloaded FW is installed in the ROM 10, the support OS information is stored, and the FW support OS information table 41 is updated.

  The support OS information table 41 already has FWA. Although the aaa information is already stored, the FW support OS information table 41 is also updated to the latest information by overwriting this information.

  Finally, in step A9, the currently operating FW, FWB. bbb Active information 415 is set to “OFF”, and the downloaded FWA. bbb Active information 415 is changed to “ON”, and FWA. Switch MasterFW to aaa.

  After that, the system was restarted, and FW was installed on the OS to be installed, FW corresponding to “Windows (registered trademark) XP”, FWA. It replaces aaa and OS installation is started.

The figure which shows the whole structure of this invention. FIG. 2 is a diagram illustrating a specific example of FW 20 stored in the ROM 10 of FIG. 1 and a content example of an FW support OS information table 41. The figure which shows the example of OS information of the header part 31 of FIG. The figure which shows the example of the content of the FW list | wrist 51 of FIG. The flowchart which shows the whole operation | movement of this embodiment.

Explanation of symbols

10 ROM
20 FW
21 Installation OS information obtaining means 22 Support OS confirmation means 23 FW switching means 24 Web access means 25 FW installation means 26 OS installer starting means 30 OS installation medium 31 Header part 40 NVRAM
41 FW support OS information table 50 FW server 51 FW list 52 FW
60 network

Claims (1)

FW
Means for obtaining OS information from the OS installation medium and setting the OS information to be installed;
For each FW, for each FW, refer to the support OS information table holding the support OS information and the operation state flag, obtain the corresponding OS information of the FW, compare the two OS information, and the FW itself If it corresponds to the OS to be installed, means for starting the OS installer;
Means for referring to the support OS information table and confirming whether or not the FW corresponding to the OS to be installed is stored in the ROM when the OS to be installed is not supported;
If the FW has been stored, switch it to an active FW and restart the system;
If the FW is not stored, the Web access to the FW server via the network, the appropriate FW is installed, and the support OS information is added to the table;
Means for installing the FW, switching the operation state of the table to active and restarting the system, and an automatic FW update method in a multi-OS-mountable platform.

Images