Control program, control method, and control device

Abstract

Avoid memory access contention. [Solution] The BMC20 controls the hardware component 10 by executing the firmware stored in the operational FMEM30a. The PLD60 maintains the reset state of the BMC20 in response to detection of a reset operation by the BMC20, which is a reset operation on the BMC20 itself. Subsequently, the PLD60 releases the reset state of the BMC20 in response to detection of completion of the firmware update operation by the PFR40, which manages the firmware, writing the updated firmware to the operational FMEM30a.

Description

Technical Field

[0001] The present invention relates to the technology of reset control.

Background Art

[0002] Techniques for avoiding startup failures from the execution of platform firmware recovery are known (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The BMC (Baseboard Management Controller) is widely known as a device that controls the hardware of a computer device. The BMC performs this control by executing software called firmware, etc. The firmware is stored in the memory of the computer device, and the integrity of this firmware may be confirmed using a dedicated device called PFR (Platform Firmware Resilience). There may be competition for access to the memory in which the firmware is stored between this PFR and the BMC. For example, if the BMC detects an abnormality in its own operation and causes a reboot of itself while the PFR is accessing the memory to confirm the integrity of the firmware, competition for access to the memory will occur. Such competition for access may cause a malfunction in the operation of the computer device.

[0005] In one aspect, the present invention aims to avoid competition for access to the memory.

Means for Solving the Problems

[0006] In one embodiment, the control program causes the processor to perform two processes: one to maintain the reset state of the controller, which controls the hardware by executing firmware stored in a first memory, and another to release the reset state. The process of maintaining the controller's reset state is performed in response to the detection of a reset operation by the controller, which is a reset operation on the controller itself. The process of releasing the reset state is performed in response to the detection of the completion of the operation by the management unit, which manages the firmware, of writing an updated version of the firmware to the first memory. [Effects of the Invention]

[0007] In one respect, the present invention can avoid contention for memory access. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagram showing a first example of the configuration of a computer system. [Figure 2] This is a timing chart showing a first example of the operating timing of each component of a computer system. [Figure 3] This is a sequence diagram showing the flow of the first example of a firmware update operation. [Figure 4] This is a timing chart showing a second example of the operating timing of each component of a computer system. [Figure 5] This is a sequence diagram showing the flow of a second example of a firmware update operation. [Figure 6] This timing chart shows a third example of the operating timing of each component of a computer system. [Figure 7] This is a diagram showing a second example of the configuration of a computer system. [Figure 8] This figure shows an example of the functional configuration of a PLD. [Figure 9] This is a sequence diagram showing the flow of a third example of a firmware update operation. [Figure 10] This is a timing chart showing a fourth example of the operating timing of each component of a computer system. [Figure 11] This figure shows an example of a processor hardware configuration. [Modes for carrying out the invention]

[0009] The embodiments will be described in detail below with reference to the drawings.

[0010] Figure 1 shows a first example of the configuration of computer system 1.

[0011] The first example of computer system 1 includes hardware components 10, a BMC 20, an operational FMEM 30a, a standby FMEM 30b, a PFR 40, and a multiplexer 50. "FMEM" is an abbreviation for Flash Memory.

[0012] Hardware components 10 are various hardware components of the computer system 1, such as the CPU, memory, hard disk, and communication interface. "CPU" is an abbreviation for Central Processing Unit, and "I / F" is an abbreviation for Interface.

[0013] The BMC20 is a device that manages the hardware component 10, and is an example of a controller that performs processing to control the hardware component 10 by executing firmware.

[0014] Both the operation - side FMEM30a and the standby - side FMEM30b are memories for storing firmware. The BMC20 performs a process of controlling the hardware component 10 by reading and executing the firmware stored in the operation - side FMEM30a. The standby - side FMEM30b is a memory for storing a backup of the firmware stored in the operation - side FMEM30a. The operation - side FMEM30a and the standby - side FMEM30b are examples of the first memory and the second memory, respectively.

[0015] The PFR40 is an example of a management unit that manages the firmware stored in each of the operation - side FMEM30a and the standby - side FMEM30b, and is a device for verifying the integrity of the firmware. Details of the operation of the PFR40 will be described later.

[0016] The multiplexer 50 is a circuit that selects either the BMC20 or the PFR40 and connects it to the operation - side FMEM30a and the standby - side FMEM30b. Note that, if necessary, the multiplexer 50 may have the function of SPI (Serial Peripheral Interface).

[0017] The reset signal is a signal driven by the PFR40 and is a signal for maintaining the reset state of the BMC20. In this embodiment, the reset signal is a signal with two different signal levels, that is, a signal with either a high - level or a low - level signal level, and the BMC20 maintains its reset state while the reset signal received from the PFR40 is at the high level.

[0018] The reset - state signal is a signal driven by the BMC20 and is a signal indicating whether the operating state of the BMC20 is in the reset state. In this embodiment, the reset - state signal is a signal with either a high - level or a low - level signal level, and the reset - state signal with a high - level signal level indicates that the operating state of the BMC has reached the reset state.

[0019] Next, we will explain how the PFR40 works.

[0020] Figure 2 is a timing chart showing a first example of the operating timing of each component of the computer system 1, and is for the time when the computer system 1 is powered on.

[0021] When the power is turned on at time T1 and the computer system 1 starts up, the BMC20 first initiates a reset operation on itself. At this time, the PFR40 outputs a high-level reset signal to the BMC20 to maintain the reset state of the BMC20, and at the same time, it starts accessing the operation side FMEM30a to read the firmware and authenticate the read firmware.

[0022] In this embodiment, the firmware stored in the operational FMEM30a includes a digital signature, and the PFR40 authenticates the firmware by verifying this signature. However, the firmware authentication by the PFR40 may be performed using other methods.

[0023] Upon successful firmware authentication, PFR40 terminates its access to the operator-side FMEM30a at time T2. Subsequently, at time T3, PFR40 changes the signal level of the reset signal from high to low, releasing the reset state of BMC20. Then, at time T4, BMC20 terminates its reset operation and begins control processing, starting access to the operator-side FMEM30a to read and execute the firmware.

[0024] If authentication of the firmware stored in the operational FMEM30a fails, the PFR40 restores (copies) the firmware stored as a backup in the standby FMEM30b to the operational FMEM30a. Then, the PFR40 reads the restored firmware from the operational FMEM30a and performs authentication. If authentication is successful, it terminates access to the operational FMEM30a. The PFR40 then changes the signal level of the reset signal from high to low to release the reset state of the BMC20. The BMC20 then finishes its reset operation and starts its normal control processing operation, accessing the operational FMEM30a to read and execute the firmware.

[0025] Once the control process by the BMC20 begins as described above, subsequent access to the operational FMEM30a and standby FMEM30b is performed by the BMC20. However, when updating the firmware stored in the operational FMEM30a and standby FMEM30b, the PFR40 may also access them. Next, the operation of the PFR40 during the firmware update operation in the computer system 1 shown in Figure 1 will be explained.

[0026] Figure 3 is a sequence diagram showing the flow of a first example of firmware update operation, illustrating the interactions between the various components of the computer system 1 when the BMC20 performs a firmware update.

[0027] When the firmware update operation is initiated, first the BMC20 accesses the standby FMEM30b and writes the updated firmware received by the computer system 1 from the external device to the standby FMEM30b (step S11). Next, the BMC20 stops accessing the standby FMEM30b and instructs the PFR40 to authenticate the updated firmware written to the standby FMEM30b (step S12).

[0028] Upon receiving this instruction, PFR40 accesses the standby FMEM30b, reads the updated firmware from it, and performs authentication (step S13). Once authentication is complete, PFR40 sends an authentication completion notification from the standby FMEM30b to BMC20 to notify it of the authentication result (success or failure) (step S14).

[0029] Figure 4 is a timing chart showing a second example of the operating timing of each component of the computer system 1, after the BMC20 receives the authentication completion notification sent by the operation of step S14 described above. In the following explanation, both the sequence diagram in Figure 3 and the timing chart in Figure 4 will be used.

[0030] When BMC20 is notified of the successful authentication of the firmware update, it instructs PFR40 to copy the firmware update to the operational FMEM30a and to authenticate the copied firmware update (step S15).

[0031] Upon receiving this instruction, PFR40 initiates access to the standby FMEM30b at time T11 and reads the firmware update from the standby FMEM30b (step S16). PFR40 then accesses the operational FMEM30a and copies the read firmware update to the operational FMEM30a by writing it (step S17). Furthermore, PFR40 reads the copied firmware update from the operational FMEM30a and authenticates it (step S18). Once this authentication is complete, PFR40 terminates access to the standby FMEM30b at time T12, and if authentication is successful, instructs BMC20 to reboot (restart) (step S19).

[0032] Subsequently, BMC20, following instructions, initiates its own reboot at time T13 (step S20), and after the reset operation is complete, at time T14, it begins accessing the operational FMEM30a to read the firmware (step S21) and starts execution.

[0033] In the computer system 1 shown in Figure 1, the PFR40 operates as described above, enabling verification of the integrity of the firmware stored in the operational FMEM30a and the standby FMEM30b.

[0034] Incidentally, the BMC20 has a function to monitor its own operating status and detect abnormalities by using methods such as a widely known watchdog timer. If an abnormality is detected, the BMC20 reboots itself, performs a reset operation on itself, reads the firmware from the operator-side FMEM30a, and starts execution. If such a reboot by the BMC20 due to an abnormality occurs in the firmware update operation described above, access to the operator-side FMEM30a may conflict between the PFR40 and the BMC20. Next, specific examples of such memory access conflicts will be explained using Figures 5 and 6.

[0035] Figure 5 is a sequence diagram showing the flow of a second example of firmware update operation, and Figure 6 is a timing chart showing a third example of the operating timing of each component of the computer system 1.

[0036] The sequence from step S11 to step S15 in Figure 5 is the same as the sequence in the first example shown in Figure 3, but the second example shows the operation flow when the BMC20 hangs up after the instruction operation to the PFR40 in step S15. Figure 6 shows the operation timing after the instruction operation in step S15.

[0037] When PFR40 receives the instruction from BMC20 in step S15, it starts accessing the standby FMEM30b at time T11 and reads the firmware update from the standby FMEM30b (step S16). PFR40 then accesses the operational FMEM30a and copies the read firmware update to the operational FMEM30a by writing it (step S17). Furthermore, PFR40 reads the copied firmware update from the operational FMEM30a and authenticates it (step S18).

[0038] The sequence from step S16 to step S18 described above is identical to the sequence in the first example shown in Figure 3. However, during this sequence, the BMC20 hangs up. The BMC20 then detects its own malfunction and starts rebooting at time T21 (step S20).

[0039] When BMC20 initiates its own reboot, it first performs a reset operation on itself. Once the reset operation is complete, at time T22, it begins accessing the operational FMEM30a to attempt to read the firmware. However, at this time, the operational FMEM30a is already receiving access from PFR40 for copying and authenticating the firmware update, resulting in an access conflict. When access to the operational FMEM30a conflicts, BMC20 cannot read and execute the firmware from the operational FMEM30a, causing it to fail to start up and malfunction. Additionally, PFR40 also experiences a failure in its firmware update copying and authentication operations.

[0040] Therefore, in the embodiment described below, the BMC20 is configured to detect a reset operation on itself, and when a reset operation is detected, the reset state of the BMC20 is maintained. In addition, the PFR40 is configured to detect the completion of the firmware update copy and authentication operation, and when the completion of the operation is detected, the maintained reset state of the BMC20 is released. In this way, the period of the BMC20's reset state is extended until the firmware update copy and authentication operation by the PFR40 is completed, thereby avoiding conflicts in access between the BMC20 and the PFR40 to the operation-side FMEM30a. Consequently, operational failures of the computer system 1 caused by this access conflict are prevented.

[0041] Now, let's explain Figure 7. Figure 7 shows a second example of the configuration of computer system 1.

[0042] The second example computer system 1, like the first example shown in Figure 1, includes hardware components 10, BMC20, operational FMEM30a, standby FMEM30b, PFR40, and multiplexer 50. These components have the same functions as those in the first example shown in Figure 1.

[0043] The second example computer system 1 further includes a PLD60 and an OR circuit 70. "PLD" is an abbreviation for Programmable Logic Device, and "OR" is an abbreviation for Logical Sum.

[0044] PLD60 is an integrated circuit in which basic logic circuits, memory circuits, wiring, switches, etc., are formed, and a logic configuration for providing a predetermined function can be constructed by programming. There are various types of PLD60, such as PAL (Programmable Array Logic), GAL (Generic Array Logic), CPLD (Complex Programmable Logic Device), and FPGA (Field Programmable Gate Array), and any of these may be used in this embodiment.

[0045] The OR circuit 70 outputs a signal which is the logical OR of two input signals. In this embodiment, the OR circuit 70 outputs a signal which is the logical OR of the reset signal driven by the PFR40 and the reset signal driven by the PLD60 to the BMC20.

[0046] Next, an example of the functional configuration of the PLD60 will be explained using Figure 8.

[0047] In this embodiment, the PLD60, which functions as a control device, includes a reset state continuation unit 61, a reset operation occurrence notification unit 62, and a reset state release unit 63.

[0048] The reset state continuation unit 61 maintains the reset state of the BMC20 in response to the detection of a reset operation performed by the BMC20. When the BMC20 starts a reset operation, it outputs a reset state signal as notification of the start of this reset operation. The PLD60 detects the reset operation performed by the BMC20 by detecting this reset state signal. In response to the detection of the reset operation, the PLD60 maintains the reset state of the BMC20 by outputting a reset signal with a high signal level to the BMC20 via the OR circuit 70. The reset signal driven by the PLD60 is also a signal with two different signal levels, namely a high level and a low level. The BMC20 maintains its reset state as long as the reset signal received from the OR circuit 70 is high level.

[0049] The reset operation notification unit 62 sends a notification to the PFR 40 that a reset operation has occurred in the BMC 20. The PLD 60 sends a notification to the PFR 40 that a reset operation has occurred by outputting an interrupt signal to the PFR 40.

[0050] The reset state release unit 63 releases the reset state that has been maintained in the BMC20 in response to the detection of the completion of the operation by the PFR40 to write the updated firmware to the operational FMEM30a. When the PFR40 completes the operation to write the updated firmware to the operational FMEM30a, it outputs a reset extension release signal to the PLD60 as a notification of the completion of the writing operation. The PLD60 detects the completion of the operation by the PFR40 to write the updated firmware to the operational FMEM30a by detecting this reset extension release signal. In addition, in response to the detection of the completion of the writing operation, the PLD60 changes the signal level of the reset signal output to the BMC20 via the OR circuit 70 from a high level to a low level, thereby releasing the reset state of the BMC20.

[0051] In this embodiment, the operation of writing the firmware update version to the operator-side FMEM30a by the PFR40 includes an authentication operation for the firmware update version written to the operator-side FMEM30a. Accordingly, the PLD60 releases the reset state that has been maintained in the BMC20 upon detection of the completion of the authentication operation for the firmware update version written to the operator-side FMEM30a.

[0052] Next, using Figures 9 and 10, we will explain how the PFR40 and BMC20 access the operational FMEM30a when the BMC20 reboots during a firmware update operation in the second example computer system 1 shown in Figure 7.

[0053] Figure 9 is a sequence diagram showing the flow of a third example of firmware update operation, and Figure 10 is a timing chart showing a fourth example of the operating timing of each component of the computer system 1.

[0054] The sequence from step S11 to step S15 in Figure 9 is identical to the sequence in the second example shown in Figure 5. Furthermore, the sequence in Figure 9, like the second example shown in Figure 5, shows the flow of operation when the BMC20 hangs up after the instruction operation to the PFR40 in step S15. Figure 10 shows the timing of the operation after this instruction operation in step S15.

[0055] When BMC20 receives notification of successful authentication of the firmware update, it instructs PFR40 to copy the firmware update to the operational FMEM30a and authenticate the copied firmware update (step S15). Upon receiving this instruction from BMC20, PFR40 begins accessing the standby FMEM30b at time T11 and reads the firmware update from the standby FMEM30b (step S16). PFR40 then accesses the operational FMEM30a and copies the read firmware update by writing it to the operational FMEM30a (step S17). Furthermore, PFR40 reads the copied firmware update from the operational FMEM30a and authenticates it (step S18). However, during the sequence from steps S16 to S18, BMC20 hangs up. BMC20 then detects its own malfunction and begins rebooting at time T21 (step S20). The sequence up to this point is identical to the sequence in the second example shown in Figure 5.

[0056] When BMC20 initiates its own reboot at time T21, it performs a reset operation on itself and outputs a reset status signal as notification that the reset operation has started. PLD60 performs a process to detect the reset status signal (step S31), and upon detecting the signal, it starts the reset extension process.

[0057] When PLD60 starts the reset extension process, it first performs a process at time T31 to keep the BMC20 in the reset state by setting the signal level of the reset signal output to BMC20 via the OR circuit 70 to a high level (step S32). As long as the signal level of this reset signal is high, BMC20 remains in the reset state, and therefore access from BMC20 to the operational side FMEM30a to read the firmware update does not occur.

[0058] Next, at time T32, PLD60 outputs an interrupt signal to PFR40 to notify PFR40 that a reset operation has occurred on itself by BMC20 (step S33). Upon receiving this interrupt signal, PFR40 starts interrupt processing.

[0059] Subsequently, the process of writing the firmware update to the operational FMEM30a, including the authentication operation of the firmware update by PFR40, as described in the sequence from step S16 to step S18, is completed at time T33. Then, at the following time T34, PFR40 performs an interrupt process, outputting a reset extension release signal to PLD60 as notification of the completion of the writing operation.

[0060] PLD60 performs a process to detect the reset extension release signal output from PFR40 (step S34). Upon detecting the reset extension release signal through this process, PLD60 terminates the reset extension process at time T35. Then, at the following time T36, it changes the signal level of the reset signal from a high level to a low level, thereby releasing the reset state that has been maintained in BMC20 (step S35).

[0061] When the signal level of the reset signal sent from PLD60 changes to a low level, BMC20 terminates the reset operation at time T37, starts accessing the operational side FMEM30a to read the firmware (step S21), and starts execution.

[0062] As described above, in the second example of the computer system 1 shown in Figure 7, the operation of reading the firmware from the operation-side FMEM30a by the BMC20 begins after the operation of writing the firmware to the operation-side FMEM30a by the PFR40 is completed. Therefore, a conflict in access to the operation-side FMEM30a by the PFR40 and the BMC20 is avoided, and the occurrence of operational failures of the computer system 1 caused by such a conflict in access is prevented.

[0063] The computer system 1 may also be configured by replacing the PLD60 in the configuration shown in Figure 7 with a processor 80 having a hardware configuration as illustrated in Figure 11.

[0064] In the configuration example shown in Figure 11, the processor 80 includes a CPU core 81, ROM 82, RAM 83, and I / O port 84. "ROM" is an abbreviation for Read Only Memory, "RAM" is an abbreviation for Random Access Memory, and "I / O port" is an abbreviation for Input / Output Port.

[0065] In the processor 80, the CPU core 81 controls the I / O port 84 by executing a program stored in the ROM 82 using the RAM 83, thereby acquiring signals sent from the device connected to the I / O port 84 and outputting signals to the device.

[0066] When configuring the computer system 1 using this processor 80, a control program is created in advance to cause the processor 80 to perform the processing steps S31 to S35 that the PLD60 performs, as explained with reference to Figure 9. The created control program is stored in the ROM 82. In addition, I / O ports 84 are connected to each component to enable the acquisition of the reset status signal output from the BMC20 and the reset extension release signal output from the PFR40, as well as the output of the interrupt signal to the PFR40 and the output of the reset signal to the OR circuit 70. Then, when the processor 80 starts up, the control program stored in the ROM 82 is read and executed by the CPU core 81, so that the processor 80 can perform the control method that the PLD60 performs.

[0067] Although embodiments of the disclosure and their advantages have been described in detail above, those skilled in the art will be able to make various modifications, additions, and omissions without departing from the scope of the invention as clearly stated in the claims. [Explanation of Symbols]

[0068] 1. Computer System 10 Hardware Components 20 BMC 30a Operation side FMEM 30b Standby FMEM 40 PFR 50 Multiplexer 60 PLD 61 Reset state continuation section 62 Reset operation notification unit 63 Reset state release section 70 OR circuit 80 processors 81 CPU cores 82 ROM 83 RAM 84 I / O ports

Claims

1. A reset operation by a controller that performs processing to control hardware by executing firmware stored in a first memory, and a process that continues the reset state of the controller in response to detection of the reset operation on the controller itself, Upon detection by the management unit managing the firmware that the operation of writing the updated version of the firmware to the first memory has been completed, the process of releasing the reset state is performed. A control program characterized by having the processor perform the following action.

2. Upon detection of the reset operation, the processor is further instructed to send a notification of the occurrence of the reset operation to the management unit. The process of releasing the reset state is performed in response to the detection of a completion notification output by the management unit upon receiving the notification of the occurrence of the reset, when the write operation to the first memory is completed. The control program according to feature 1.

3. The controller performs the operation of writing the updated firmware to the second memory, and performs the reset operation in response to the detection of an abnormality in the operation of the controller itself after the operation of writing to the second memory. When the operation to write the updated firmware to the second memory is completed, the management unit reads the updated firmware from the second memory and starts the operation to write it to the first memory in response to a predetermined instruction output from the controller. The process of releasing the reset state is performed in response to the detection of a completion notification output from the management unit when the operation of writing the updated firmware to the first memory is completed. The control program according to feature 1.

4. The control program according to claim 1, characterized in that the process of maintaining the reset state is performed in response to the detection of a start notification output from the controller when the reset operation is started.

5. The process of maintaining the reset state is a process of outputting a predetermined signal to the controller. The process of releasing the reset state is a process of changing the predetermined signal to a different signal. The control program according to feature 1.

6. The writing operation includes an authentication operation for the updated firmware written to the first memory. The process of releasing the reset state is performed in response to the detection of the completion of the authentication operation. A control program according to any one of claims 1 to 5.

7. A reset operation by a controller that performs processing to control hardware by executing firmware stored in a first memory, wherein the controller maintains the reset state in response to detection of the reset operation on the controller itself. Upon detection by the management unit managing the firmware that the operation of writing the updated version of the firmware to the first memory has been completed, the reset state is released. A control method characterized in that the processor performs the control.

8. A reset operation by a controller that performs processing to control hardware by executing firmware stored in a first memory, and a reset state continuation unit that continues the reset state of the controller in response to detection of the reset operation on the controller itself, A reset state release unit releases the reset state in response to the management unit that manages the firmware detecting the completion of the operation to write the updated version of the firmware to the first memory. A control device characterized by comprising:

Images