JPH04336655A - Firmware loading system for loosely coupled multiprocessor - Google Patents

Abstract

PURPOSE:To eliminate the need for the replacement of firmware files at every processor at the time of updating the firmware by providing a function delivering the firmware to every processor with a system operation controller controlling the operation of a power source contol systems. CONSTITUTION:For example, three processors 1 are connected by a system connection bus 104, and the processor 1 is connected so as to control a filing device 106 and a front end processor 107 (FEP). A system operation controller 3 is connected through the power source part 120 of the processor 1 and a power source control interface 122 and through a service processor 2 and firmware load interfaces 4 provided on every processor. Then the system operation controller 3 transfer firmware to every processor. Thus, the version number can be managed in a batch as a system.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a firmware loading method for a loosely coupled multiprocessor system.

0002

2. Description of the Related Art When loading firmware in a conventional loosely coupled multiprocessor system, a service processor built into each processor reads firmware from a magnetic disk device or the like under control of the service processor and stores it in a control store.

FIG. 9 is a block diagram illustrating an example of such a conventional technique.

In this example, three identical processors 101 are connected by an intersystem connection bus 104, and a file device 10
A loosely coupled multiprocessor system is configured in which each processor 101 can control the processor 6 and the front-end processor 107.

[0005] The processor 101 has a CPU 112 and a C
It is composed of a memory 113 connected to the PU 112, an intersystem connection bus adapter 111, an IOP 114, a service processor (SVP) 115, a magnetic disk device 116 under SVP control, and a flexible disk device 117. The CPU 112 has an internal control store (CS) 117 and is controlled by a microprogram (firmware) on the control store 117.

The firmware of the control store 117 is stored in the magnetic disk device 11 under the control of the SVP 115.
Read the firmware from 6 and scan path 119
The data is stored in the control store 117 via the . The firmware is updated via a flexible disk medium from the flexible device 117 to the magnetic disk device 11.
This is done by transferring and storing the data in 6.

[0007]

[Problems to be Solved by the Invention] In the conventional firmware loading method described above, since a firmware file must be provided for each processor, there is a problem that the firmware file must be replaced for each processor when updating the firmware, and the firmware There was a problem in that version number management had to be performed for each processor.

[0008]

[Means for Solving the Problems] A firmware loading method for a loosely coupled multiprocessor system according to the present invention provides a firmware loading interface between each processor and a system operation control device, and a method for controlling system operation such as power supply control. The system operation control device has a function of distributing firmware to all processors.

[0009]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the present invention will be explained with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of a first embodiment of the present invention. In this example, three processors 1 are connected by an intersystem connection bus 104, and the processor 1 connects to the file device 106 and the front end processor 1.
07 to form a loosely coupled multiprocessor system.

[0011] The processor 1 includes a CPU 112 and a CPU
Intersystem connection bus adapter 111 connected to 112
, memory 113, IOP114 and SVP2, and SV
A flexible disk device 118 connected to P2,
It is composed of a magnetic disk device 116 and a power supply section 120.

[0012] The CPU 112 has an internal control store (CS) 117 and is operated by firmware on the CS. S to CS 117 via scan path 119
Firmware is loaded under the control of VP2.

The system operation control device 3 is connected to the power supply section 120 of the processor 1 via a power supply control interface 122, and also connects to the SVP 2 and a firmware load interface 4 provided for each processor.
connected via.

FIG. 2 is a detailed block diagram of SVP 2 in FIG. 1. The SVP 2 includes a microprocessor 21, ROM 22, RAM 23, a flexible disk controller (FDC) 25, a magnetic disk controller 26, a scan path adapter 27, a system operation control device interface adapter 28, and an operation unit 29, which are connected to an internal bus 24. Ru.

The microprocessor 21 controls the controllers 25 and 26 and the adapters 27 and 28 according to programs stored in the ROM 22 and RAM 23. Further, it is connected to the CPU 112 via a scan path 119 via a scan path adapter 27, and loads the firmware of the CS 117. The system operation control device 3 is connected to the firmware load interface 4 via a system operation control device adapter 28 .

FIG. 3 is a detailed block diagram of the system operation control device 3 of FIG. 1. The system operation control device 3 includes a microprocessor 31 and a ROM 3 connected to an internal bus 34.
2, RAM 33, flexible controller 35, magnetic disk controller 36, power supply control adapter 37, S
VP interface adapter 38 and operation unit 38;
It consists of a flexible disk 40 connected to a flexible disk controller 35 and a magnetic disk device 41 connected to a magnetic disk controller 36.

The microprocessor 31 controls each controller 35, 36 and each adapter 37, 38 according to the programs stored in the ROM 32 and RAM 33. In addition, the power supply section 120 of the processor 1 is the power supply control adapter 37.
The SVP 2 is connected to the firmware load interface 4 provided for each processor 1 via the SVP interface adapter 38 . Firmware for each processor 1 is stored on the magnetic disk device 41.

Next, the operation of the first embodiment will be explained. When the processor 1 needs to load an initial program due to a human instruction from the operation unit 29 of the SVP 2 or power-on, the SVP 2 controls the system operation control device interface adapter 28 and loads the system via the firmware load interface 4. A firmware load request is sent to the operation control device 3.

The system operation control device 3 sends the firmware stored on the magnetic disk device 41 to the SVP 2 via the firmware load interface 4. S
The VP2 controls the scan path adapter 27 and sends the received firmware to the CS 11 via the scan path 119.
Transfer the firmware to 7. The firmware stored in the system operation control device 3 is updated by reading it from the flexible disk device 40 using a flexible disk medium and storing it on a magnetic disk.

FIG. 4 is a block diagram showing the configuration of a second embodiment of the present invention. In this embodiment, a bus-type local area network (LAN) 5 is provided in place of the firmware load interface 4 provided for each processor 1 in the first embodiment, and the SVP 6 of each processor 1 and the system operation control device 3 are provided. is connected to the branch. As shown in FIG. 5, the SVP 7 is provided with a LAN adapter 50 in place of the system operation control device interface adapter 28 in the SVP 2 of the first embodiment.
It is connected to the system operation control device 7 via AN5. Further, as shown in FIG. 6, the system operation control device 7 is provided with a LAN adapter 51 in place of the SVP interface adapter 38 in the system operation control device 3 of the first embodiment, and is connected to the SVP 6 via the LAN 5.

Next, the operation of the second embodiment will be explained. When the processor 1 needs to load an initial program due to a human instruction from the operation unit 29 of the SVP 6 or power-on, the SVP 6 controls the LAN adapter 50 and sends a message to the system operation control device 7 via the LAN 5. Send a firmware load request.

When the system operation control device 7 receives a firmware load request from two or more processors 1 at the same time, and when the system operation control device 7 instructs a plurality of processors 1 to turn on the power, the system operation control device 7 instructs the plurality of processors 1 to turn on the power. When a firmware load request is received from all of the processors 1, the firmware is read from the magnetic disk device 41 and outputted to the LAN 5 via the LAN adapter 51 by omnidirectional communication.

The SVP 6 of the processor 1 requesting the firmware transfers the firmware sent by omnidirectional communication to the scan path 1 via the scan path adapter 27.
19, the data is transferred to the CS 117 of the CPU 112. The SVP 6 of the processor 1 that does not request firmware discards the firmware sent through omnidirectional communication.

In the first embodiment, since the firmware is distributed from one system operation control device 3 to all the processors 1, there is a problem that it takes time to start up the system. In this method, when a plurality of processors request firmware loading at the same time, it is not necessary to transfer the firmware to each processor, so the system start-up time can be reduced.

Next, a third embodiment of the present invention will be described with reference to the drawings. The configuration of the third embodiment is the same as that of the second embodiment except for the SVP. FIG. 7 shows a detailed block diagram of the SVP section of the third embodiment. This SVP has a buffer memory 61 connected to the internal bus 24 of the SVP 6 of the second embodiment.
are connected.

Next, the operation of the third embodiment will be explained. S.V.
Regardless of the operating state of the processor 1, if the SVP is in an operating state, P stores the firmware sent from the system operation control device 7 through omnidirectional communication in the buffer memory 61.

When the processor 1 is in a state requiring an initial program load, the SVP checks the contents of the buffer memory 61 and, if valid firmware is stored, reads the firmware from the huffer memory 61 and loads the scan path adapter 27. The firmware is loaded into the CS 117 of the CPU 112 via the intermediary scan path 119 .

When there is no valid firmware in the buffer memory 61, the LAN adapter 50 is controlled;
A firmware load request is sent to the system operation control device 7 via the LAN 5. System operation control device 7
When receiving the firmware load request, it sends the firmware onto the LAN 5 using omnidirectional communication. The SVP stores the firmware in the buffer memory 61 and transfers it to the CS 117 of the CPU 112.

When updating the firmware stored in the magnetic disk device 41, the system operation control device 7 sends the firmware onto the LAN 5 through omnidirectional communication. In this example, the buffer memory 61 is connected to the internal bus, but a buffer area may be provided in a part of the RAM 23 and used as a buffer memory.

In the second embodiment, the operating processor 1
Since operation cannot be guaranteed if firmware is transferred to a machine, firmware transferred during operation must be discarded. Therefore, when reloading the initial program, there is a problem that the firmware must be loaded again from the system operation control device 7.
In this embodiment, by providing the buffer memory 61 in the processor, there is no need to transfer firmware from the system operation control device each time an initial program is loaded, so that the start-up time of the processor 1 can be reduced.

Next, a fourth embodiment of the present invention will be described with reference to the drawings. The fourth embodiment is the third embodiment except for the SVP section.
This is the same as the embodiment. FIG. 8 is a detailed block diagram of the SVP section of the fourth embodiment, and is provided with a battery 71 for backing up the buffer memory 61 when the power is turned off.

As a result, the buffer memory 61 is backed up by the battery 71 and its contents are retained even when the power is turned off. The rest is carried out in the same manner as in the third embodiment.

In this example, the buffer memory 61 is backed up by a battery 71 to prevent erasure of the firmware when the power is turned off. However, even if a rewritable ROM (EEPROM), flexible disk, or magnetic disk is used as a buffer, The same can be achieved.

In the third embodiment, there is a problem that if the buffer memory 61 is erased when the power is turned off, the firmware must be loaded again from the system operation control device when the power is turned on again. By retaining the firmware even when the power is turned off, there is no need to transfer the firmware from the system operation control device when the processor is powered on, and the startup time of the processor can be shortened.

In all the embodiments described above, the processor 1
The SVP controls the firmware loading to the CS 117 of the CPU 112 in the CPU 112.
The firmware may be loaded by providing a firmware load interface adapter on the internal bus of the computer and a boot load program on the ROM of the CPU.

[0036]

As explained above, in the present invention, since the system operation control device transfers the firmware to all processors, there is no need to replace the firmware for each processor when updating the firmware.
Version number management has the effect of being able to be performed all at once as a system.

[Brief explanation of drawings]

FIG. 1 is a block diagram of a first embodiment of the present invention.

[Figure 2] Detailed block diagram of the SVP section in Figure 1

[Figure 3] Block diagram of the system operation control device in Figure 1

FIG. 4 is a block diagram of a second embodiment of the present invention.

[Figure 5] Detailed block diagram of the SVP section in Figure 4

[Figure 6] Block diagram of the system operation control device in Figure 4

[
FIG. 7: Block diagram of the SVP section of the third embodiment of the present invention

[
FIG. 8: Block diagram of the SVP section of the fourth embodiment of the present invention

[
Figure 9: Block diagram explaining conventional technology

[Explanation of symbols]

1,101 Processor 2,6,115 Service Processor (SVP)
3,7,121 System operation control device 4
Firmware load interface 5 Local area network (LAN) 21, 31
Microprocessor 22, 32 ROM 23, 33 RAM 24, 34 Internal bus 25, 35 Flexible disk controller (FDC) 26, 36 Magnetic disk controller (DKC)
) 27 Scan path adapter 28 System operation control device interface adapter 29, 39 Operation unit 37 Power supply control adapter 38 SVP interface adapter 40, 11
8 Flexible disk device 41, 116
Magnetic disk devices 50, 51 LAN adapter 61 Buffer memory 71 Battery 104 Inter-system connection bus 106 File device 107 Front-end processor (FEP) 1
11 Inter-system connection bus adapter 112
CPU 113 Memory (MEM) 114 IOP 117 Control store (CS) 119
Scan path 120 power supply section

Claims (4)

[Claims] Claim 1: A firmware load interface is provided between each processor and a system operation control device,
A firmware loading method for a loosely coupled multiprocessor system, characterized in that one system operation control device that supervises system operation such as power supply control has a function of distributing firmware to all processors. [Claim 2] Each processor and a system operation control device are connected by a bus-type local area network,
2. The firmware loading method for a loosely coupled multiprocessor system according to claim 1, wherein firmware loading is performed via omnidirectional communication via said LAN. 3. When the system operation control device transmits the firmware, a buffer is provided for each processor to store the firmware regardless of the operating state of the processor, and the firmware is stored in the buffer when the initial microprogram of each processor is loaded. When the firmware is stored in the buffer, the firmware is loaded into the control store from the buffer, and when no firmware is stored in the buffer, the firmware load request is sent to the system operation control device and the firmware is loaded from the system operation control device. Firmware loading method for the loosely coupled multiprocessor system described. 4. The firmware loading method for a loosely coupled multiprocessor system according to claim 3, wherein the buffer for temporarily storing the firmware uses a storage medium that is not erased when the power is turned off.