TWI783831B - Processing system and method for verify and management of the firmware - Google Patents

Abstract

The processing system and method for verify and management of the firmware is provided. The processing method comprise the steps. A client sends a firmware file to a server end. The server end fetches a policy information and a hardware information according to analysis the firmware file. The server end modify the policy information to a release information according to an information update request form the client. The server end selects at least of hardware function file according to the hardware information. The server end packs the release information and the hardware function file into a temporary file. The server end transform the temporary file to a confirm file according to an ack request from the client.

Description

System and method for firmware verification and management of server hardware components

The invention relates to a file management system and method, in particular to a firmware verification and management system and method of server hardware components.

With the rapid development of the server, the computing power of the server has also been greatly improved. In order to ensure a stable environment when the server is running, the server also needs to be equipped with a variety of corresponding hardware components, such as sensors, fans, or power supplies. Because each hardware component in the server needs firmware (firmware) control. Therefore, firmware verification and management of hardware components is an important issue.

Taking the fan as an example, since the control of the fan is related to a board management controller (Board Management Controller, BMC). Therefore, in addition to firmware engineering personnel, the fan firmware also needs to be confirmed by the development personnel of the baseboard controller to confirm the firmware content. The firmware file can only be released after the engineers of both parties confirm that it is correct. Due to the lengthy communication process, firmware verification may be difficult, and subsequent releases may be difficult to control.

In view of this, the processing system of firmware verification and management of server components provides firmware verification of hardware components and corresponding management of release version numbers.

In some embodiments, the processing system for firmware verification and management of server components includes a client end and a server end. The client has files to be verified; the server includes a communication unit, a storage unit and a processing unit, the communication unit is connected to the client, the communication unit transmits files to be verified, the storage unit stores multiple hardware function files, and the processing unit is electrically connected Between the communication unit and the storage unit, the processing unit parses the file to be verified, obtains the configuration information and hardware information of the file to be verified, the communication unit transmits the configuration information to the client, and the client responds to the information modification command according to the configuration information, and the processing unit The configuration information is modified according to the information modification command, the processing unit selects at least one hardware function file according to the hardware information, and the processing unit packages the modified configuration information and the selected at least one hardware function file into a target file. The processing system of firmware verification and management of server components provides firmware verification of hardware components and corresponding management of version numbers. In addition to reducing the burden of firmware verification for developers in different departments, it also reduces the cost of back-and-forth communication between different departments. Furthermore, the processing system for verifying and managing the firmware of the server components can automatically compile the corresponding version numbers while generating the firmware files of the hardware components.

In some embodiments, the storage unit further stores verification information, and the processing unit checks the JSON file format of the deployment information according to the verification information to obtain a text verification result.

In some embodiments, the server receives the confirmation request from the client, the processing unit changes the target file into a verified file according to the confirmation request, and the processing unit stores the verified file in the storage unit.

In some embodiments, the storage unit includes at least one verified file, and the processing unit searches the storage unit for the selected file associated with the modified deployment information.

In some embodiments, the storage unit further includes a lightweight directory access program, and the processing unit executes the lightweight directory access program to identify the login information of the client.

In some embodiments, the processing method of firmware verification and management of server components includes transmitting the file to be verified from the client to the server; the server parses the file to be verified, and obtains the deployment information and hardware of the file to be verified information; the server transmits deployment information to the client; the client responds to an information correction command according to the deployment information; the server modifies the deployment information according to the information correction command, and the server selects at least one hardware function according to the hardware information file; the server side encapsulates the modified deployment information and at least one selected hardware function file into a target file.

In some embodiments, the step of transmitting the file to be verified from the client to the server includes: the server receives the user identification request from the client; the server determines whether the user identification request is correct or incorrect according to the directory access procedure If it is a correct client, the server transmits the file to be verified from the correct client; if it is a wrong client, the server rejects the file to be verified from the wrong client.

In some embodiments, the step of packaging the modified deployment information and the selected at least one hardware function file into a target file at the server side further includes: the server side receives a confirmation request from the client side; the processing unit according to the confirmation Request to change the target file to a verified file; the processing unit stores the verified file to the storage unit.

The processing system and method for firmware verification and management of server components provide real-time online verification of firmware and synchronous management of version numbers. The client only needs to upload the file to be verified to the processing system. In addition to confirming whether the file format of the file to be verified is correct, the processing system will also confirm whether the newly modified content is correct. In this way, the user does not need to transmit the file to be verified to different units for verification.

Please refer to FIG. 1 , which is a schematic diagram of the system architecture of this embodiment. The processing system 001 for firmware verification and management of server components includes at least a client 100 and a server 200 . The client 100 is communicatively connected to the server 200 . The client 100 can be, but not limited to, a personal computer, a notebook computer, a mobile phone, a tablet computer, or an embedded system (Embedded System).

The user terminal 100 includes an input unit 110 , a display unit 120 , a first communication unit 130 , a first storage unit 140 and a first processing unit 150 . The first processing unit 150 is electrically connected to the input unit 110 , the display unit 120 , the first communication unit 130 and the first storage unit 140 . The first storage unit 140 stores the operation interface program 141 and at least one file 310 (profile) to be verified. The file to be verified 310 is an unverified firmware file of a hardware component. The hardware component may be but not limited to a fan, a heat sink, a sensor or a communication bus. The hardware component is a general term for related electronic components or devices in the server 200 . Therefore, the first storage unit 140 can store a fan profile to be verified 310 (fan profile), a heat sink or its hardware components to be verified.

The operation interface program 141 is used to receive the control request issued by the user during operation or the verification result of playing the firmware file. The control request may include operations such as selecting a file, transmitting the file 310 to be verified, updating information, or confirming content. The operation interface program 141 can be an independent application program (application), and can also be executed in a browser (browser). The display unit 120 plays the operation interface of the operation interface program 141 , or displays relevant information from the server 200 .

The server 200 includes a second communication unit 210 , a second storage unit 220 and a second processing unit 230 . The second processing unit 230 is electrically connected to the second communication unit 210 and the second storage unit 220 . The second communication unit 210 is communicatively connected to the first communication unit 130 of the user terminal 100 . The second communication unit 210 may be, but not limited to, a wired network, a wireless network, or a mobile communication network. The second communication unit 210 can transmit the file 310 to be verified to the first communication unit 130, or the second communication unit 210 can receive other information or operation requirements.

The second storage unit 220 stores a firmware verification platform program 231 , a verified file 232 and a plurality of hardware function files 233 . The second storage unit 220 can also temporarily store relevant information generated during the firmware verification process. In addition, the verified file 232 is the output result of the verified and packaged file to be verified 310 . The hardware function file 233 is a function library or an application program required by the file 310 to be verified during the firmware packaging process. For the same series of hardware components, different versions of firmware files may require the same function library. Here, the function libraries or application programs that need to be called by the file 310 to be verified are collectively referred to as the hardware function file 233 .

The second processing unit 230 executes the firmware verification platform program 231 . In addition to providing the operation interface, the firmware verification platform program 231 is also used to analyze the content of the file 310 to be verified, and output corresponding messages according to the analysis process. The firmware verification platform program 231 responds to the operation interface program 141 of the client 100 , so that the operation interface program 141 also provides part of the information of the firmware verification platform program 231 . In addition to displaying relevant information of the firmware file, the operation interface can also receive the above-mentioned various control requests, and return the control requests to the server 200 .

In order to clearly illustrate the process of firmware verification and management of server components, please also refer to FIG. 2A and FIG. 2B , which are respectively the processing flowchart and operation diagram of firmware verification and management of server components. Step S210: the client transmits the file to be verified to the server; Step S220: the server parses the file to be verified, and obtains the deployment information and hardware information of the file to be verified; Step S230: the server transmits deployment information to the client; Step S240: the client responds to an information modification command according to the deployment information; Step S250: the server side modifies the deployment information according to the information modification command, and the server side selects at least one hardware function file according to the hardware information; Step S260: The server encapsulates the modified deployment information and at least one selected hardware function file into a target file.

First, the user terminal 100 executes the operation interface program 141 and selects the file 310 to be verified. The operation interface program 141 transmits the file 310 to be verified to the server 200 . The server 200 parses the file 310 to be verified, and obtains deployment information 311 (policy) and hardware information 312 from the file 310 to be verified, which can be matched with that shown in FIG. 2B . Deployment information 311 is for setting various environments of hardware components. For example, the deployment information 311 may be, but not limited to, keep options (keep), delete options (delete), rename options (rename), default options or specification power information. As in the previous example, there is a hardware component of a fan in the server end 200 . Therefore, the configuration information of the fan is also configured in the deployment information (fan policy).

Generally speaking, the deployment information 311 may not be given corresponding setting values when initially obtained. In another case, the profile to be verified 310 is the result of modifying other verified files 232 . Therefore, the default value of the deployment information 311 will inherit the content of the verified file 232 . The hardware information 312 is the type of the hardware component, the model of the hardware component, the model of the motherboard, platform information, project information, host information or environment setting information. The platform information refers to the server model used by the hardware components. Project Information is a development project for server models. The host information department is the person in charge or supervisor of the development project. The environment setting information refers to the environment parameters or setting parameters applicable to the hardware components.

The firmware verification platform program 231 receives the file 310 to be verified, and the firmware verification platform program 231 transmits various environment settings of the deployment information 311 to the operation interface program 141 . Assuming that the hardware information 312 of the hardware component includes "default", "SPECpower", "default0823", "SPECpower0823" and "port 80", each hardware information 312 has corresponding deployment information 311, as shown in FIG. 3A As shown, the options described are illustrative only and not limiting.

The server 200 transmits the content of the deployment information 311 to the client 100 for the client 100 to confirm whether to modify the deployment information 311 . If the deployment information 311 needs to be changed, the client 100 transmits an information modification command to the server 200 according to the deployment information 311 to modify the content of the deployment information 311 . In addition, if the client 100 thinks that the content of the deployment information 311 is correct, the client 100 can transmit an unmodified information correction command to the server 200, so that the server 200 ends the processing of the deployment information 311 at this stage, Refer to step S230 and FIG. 2B.

Next, the firmware verification platform program 231 selects the corresponding hardware function file 233 according to the hardware information 312 . The firmware verification platform program 231 performs packaging according to the selected hardware function file 233 and the deployment information 311 , and the packaging result is called the target file 320 . The second processing unit 230 temporarily stores the target file 320 in the second storage unit 220 . The firmware verification platform program 231 transmits the encapsulation result to the client 100 for the client 100 to play the corresponding screen of the target file 320 , as shown in FIG. 3B .

In some embodiments, the second storage unit 220 further includes at least one verification information 410 . The firmware verification platform program 231 checks the deployment information 311 according to the verification information 410 whether there is a format error in the JSON (JavaScript Object Notation) file format, and obtains a text verification result. The verification information 410 may be a text checking structure formed by regular expressions, as shown in FIG. 3C . If the text verification result is correct, the server 200 will generate corresponding deployment information 311 according to the file 310 to be verified. The server 200 sends an information report to the client 100 to remind the server 200 that the parsing process of the file 310 to be verified has been completed. If the text verification result is an error, the server 200 will also transmit an information report to the client 100 to remind the client 100 that the file 310 to be verified has a format error.

Assume that the deployment information 311 of the hardware component includes "default", "SPECpower", "default0823", "SPECpower0823" and "port 80", and the hardware component only needs to set "default0823", "SPECpower0823" and "port 80" and other parameters. If "default", "SPECpower", "default0823", "SPECpower0823" and "port 80" of the deployment information 311 are all "true". Therefore, the provisioning information 311 will be detected as an error by the firmware verification platform program 231 .

The operation interface program 141 can also display a modification page of the deployment information 311 . The user terminal 100 can adjust and modify various options on the page, as shown in FIG. 3A . FIG. 3D and FIG. 3E are schematic images of the deployment information 311 presented by the operation interface program 141 respectively. 3D and 3E correspond to the underlying file structure of FIG. 3A. FIG. 3D shows wrong deployment information 311 . In FIG. 3D , a tick is used to indicate that the parameter is a true value. FIG. 3E is the underlying file structure of the provisioning information 311 that cancels the wrong parameters.

In one embodiment, the second storage unit 220 further includes a version management program 420 (Stock Keeping Unit, SKU for short). The firmware verification platform program 231 calls the version number management program 420 during the process of packaging the target file 320 . In addition to checking whether the verified file 232 associated with the deployment information 311 is stored in the second storage unit 220, the version number management program 420 can also generate a corresponding firmware version number according to the file 310 to be verified. Cooperate with the steps of "packaging target files" in Figure 2B. The version number management program 420 can record the successfully packaged firmware files (that is, the verified files 232 ), and also record the failed firmware files. The version number management program 420 records the related operations of the file 310 to be verified in the history information. Each piece of history information represents a different hardware component, and the history information can provide the client 100 to query all past file history of the firmware package.

If there is a related verified file 232 in the second storage unit 220 , the version number management program 420 renames the file name of the file to be verified 310 to the file name of the verified file 232 . The verification information 410 is generated according to the hardware information 312 of the file 310 to be verified. The version number management program 420 searches the second storage unit 220 for the verified file 232 of the same hardware component according to the verification information 410 .

The found verified file 232 associated with the modified deployment information 311 is a selected file (no label). If the selected file exists in the second storage unit 220 , the version number management program 420 modifies the file name of the file to be verified 310 to the found file name of the verified file 232 . If the selected file does not exist in the second storage unit 220 , the version management program 420 creates a new file name according to the deployment information 311 . No matter whether the version number management program 420 finds the selected file or not, the version number management program 420 transmits the corresponding file search result to the client terminal 100 .

After establishing the file name of the deployment information 311 , the firmware verification platform program 231 transmits the page to be confirmed to the client 100 , so as to reconfirm to the client 100 whether there is any error in the process of processing the file 310 to be verified. If the client 100 confirms that there is no error in the processing of the file 310 to be verified, the client 100 transmits a confirmation request to the server 200 . The firmware verification platform program 231 changes the target file 320 to a new verified file 232 according to the confirmation requirement. The firmware verification platform program 231 publishes the verified file 232 . If there is an error in the verification process, the client 100 transmits a cancel request to the server 200 . The firmware verification platform program 231 records the target file 320 in the second storage unit 220 and records the target file 320 in the history information. The cancellation request includes verification, parsing or packaging error information of the file 310 to be verified, so that the error information can be recorded in the log.

In one embodiment, the firmware verification platform program 231 calls the version number management program 420 during the process of generating the target file 320 . The version number management program 420 will generate a set of firmware version numbers. The version number management program 420 adds the firmware version number into the target file 320, which can be matched with that shown in FIG. 2B. The firmware version number can be set by the client terminal 100 , it can also be implemented by editing the existing firmware version number with a serial number, or using a time stamp as a number.

In one embodiment, the second storage unit 220 further includes Lightweight Directory Access Protocol (LDAP for short). Please refer to FIG. 4 , which is a schematic diagram of a processing system architecture for firmware verification and management of server components according to an embodiment. When the client 100 is connected to the server 200 , the server 200 executes the LDAP program 511 . The server 200 obtains the login information 521 of the client 100 according to the LDAP program 511 or from the external computer 520 . The LDAP program 511 judges whether the client terminal 100 is correct or incorrect according to the login information 521 . If the user terminal 100 is correct, the second processing unit 230 executes the firmware verification platform program 231 and performs related processing on the file 310 to be verified. Otherwise, the server 200 will transmit an error message to the client 100 . Moreover, the server 200 rejects the file 310 to be verified from the wrong client 100 .

In one embodiment, after the server 200 obtains the file 310 to be verified, the firmware verification platform will invoke the history information of the hardware components. After the firmware verification platform program 231 invokes the history information, the firmware verification platform program 231 will bind the edit lock relationship between the file to be verified 310 and the client terminal 100 . In addition to limiting the client 100 that can edit the file 310 to be verified, the editing lock relationship is also used to confirm whether the file 310 to be verified has been closed. When the firmware verification platform program 231 receives the file 310 to be verified, the firmware verification platform program 231 sets the file 310 to be verified as a locked state, please cooperate with the steps of "encapsulating the target file" in FIG. 2B.

After the client terminal 100 completes all the aforementioned operations, the client terminal 100 transmits a confirmation request to the server terminal 200 . The firmware verification platform program 231 releases the editing lock relationship according to the closing requirements, please cooperate with the steps of "encapsulating the target file" in FIG. 2B. If the client terminal 100 is interrupted during parameter setting or other operations, the firmware verification platform program 231 will maintain the editing relationship until the same client terminal 100 is reconnected. When the firmware verification platform program 231 maintains the editing relationship, other client terminals 100 cannot set relevant parameters of the file 310 to be verified, or perform operations of adding or deleting files.

The processing system and method for firmware verification and management of server components provide firmware verification of hardware components and corresponding management of version numbers. In addition to reducing the burden of firmware verification for developers in different departments, it also reduces the cost of back-and-forth communication between different departments. Furthermore, the processing system for verifying and managing the firmware of the server components can automatically compile the corresponding version numbers while generating the firmware files of the hardware components.

001: Processing system 100: client 110: input unit 120: display unit 130: The first communication unit 140: the first storage unit 150: The first processing unit 141: Operation interface program 200: server side 210: The second communication unit 220: the second storage unit 230: second processing unit 231: Firmware verification platform program 232: Verified file 233:Hardware function file 310: file to be verified 311: Deployment information 312:Hardware information 320: target file 410: Verify information 420: version number management program 511:LDAP procedure 520: external computer 521: login information S210, S220, S230, S240, S250, S260: steps

[FIG. 1] is a schematic diagram of the system architecture of an embodiment. [ FIG. 2A ] is a process flowchart of firmware verification and management of server components according to an embodiment. [ FIG. 2B ] is a sequence diagram of firmware verification and management of server components according to an embodiment. [ FIG. 3A ] is a schematic diagram of hardware information and deployment information in the operation interface program of an embodiment. [ FIG. 3B ] is a schematic diagram of multiple sets of target files in the operation interface program of an embodiment. [ FIG. 3C ] is a schematic diagram of the text structure of the verification information of an embodiment. [ FIG. 3D ] is a schematic picture of the deployment information presented by the operation interface program of an embodiment. [FIG. 3E] is another schematic picture of the deployment information presented by the operation interface program of an embodiment. [ FIG. 4 ] is a schematic diagram of a processing system architecture for firmware verification and management of server components according to an embodiment.

001: Processing system

100: client

110: input unit

120: display unit

130: The first communication unit

140: the first storage unit

150: The first processing unit

141: Operation interface program

200: server side

210: The second communication unit

220: the second storage unit

230: second processing unit

231: Firmware verification platform program

232: Verified file

233:Hardware function file

310: file to be verified

311: Deployment information

312:Hardware information

Claims (15)

A firmware verification and management system for server hardware components, comprising: a user terminal having a file to be verified; and A server end includes a communication unit, a storage unit and a processing unit, the communication unit is connected to the user end, the communication unit transmits the file to be verified, the storage unit stores a plurality of hardware function files, and the processing The unit is electrically connected to the communication unit and the storage unit, the processing unit analyzes the file to be verified, obtains a configuration information and a hardware information of the file to be verified, and the communication unit transmits the configuration information to the client , the client responds to an information modification command according to the configuration information, the processing unit modifies the deployment information according to the information modification command, the processing unit selects at least one hardware function file according to the hardware information, and the processing unit modifies Afterwards, the deployment information and the selected at least one hardware function file are packaged into a target file. The firmware verification and management system for server hardware components as described in Claim 1, wherein the storage unit further stores a verification information, and the processing unit checks the JSON file format of the deployment information according to the verification information, and obtains a text Validation results. The firmware verification and management system for server hardware components as described in Claim 2, wherein the processing unit drives the communication unit to transmit an information report to the client according to the text verification result. The firmware verification and management system for server hardware components as described in Claim 1, wherein the server receives a confirmation request from the client, and the processing unit changes the target file into a verified file according to the confirmation request , the processing unit stores the verified file in the storage unit. The firmware verification and management system for server hardware components as described in Claim 1, wherein the storage unit includes at least one verified file, and the processing unit finds that the storage unit is associated with the modified deployment information is designated as a selected file. The firmware verification and management system for server hardware components as described in claim 5, wherein the processing unit modifies the file name of the target file to the file name of the selected file. The firmware verification and management system for server hardware components as described in Claim 1, wherein the target file further includes a firmware version number. The firmware verification and management system for server hardware components as described in Claim 1, wherein the storage unit further includes a lightweight directory access program, and the processing unit executes the lightweight directory access program to identify the Client login information. A method for verifying and managing firmware of server hardware components, comprising: Transmitting a file to be verified from a client to a server; The server parses the file to be verified, and obtains a deployment information and a hardware information of the file to be verified; the server transmits the deployment information to the client; The client responds to an information modification command according to the provisioning information; The server side modifies the deployment information according to the information modification command, and the server side selects at least one hardware function file according to the hardware information; and The server encapsulates the modified deployment information and the selected at least one hardware function file into a target file. The firmware verification and management method of server hardware components as described in claim 9, wherein the step of transmitting the file to be verified from the client to the server includes: the server receives a user identification request from the client; The server judges whether the user identification request is a correct client or a wrong client according to a directory access program; If it is the correct client, the server transmits the file to be verified from the correct client; and If it is the wrong client, the server rejects the file to be verified from the wrong client. The firmware verification and management method for server hardware components as described in claim 9, wherein the step of transmitting the deployment information from the server to the client further includes: The server side checks the JSON file format of the deployment information according to the verification information, and obtains a text verification result; and The server drives the communication unit to transmit an information report to the client according to the text verification result. The firmware verification and management method for server hardware components as described in claim 9, wherein the modified deployment information and at least one selected hardware function file are packaged as the target file on the server side The steps further include: The server receives a confirmation request from the client; the processing unit changes the target file to a verified file according to the validation request; and The processing unit stores the verified file into a storage unit. The firmware verification and management method for server hardware components as described in claim 12, wherein after the step of changing the target file to the verified file by the processing unit according to the confirmation request, it includes: The server-side finds at least one verified file in a storage unit that is associated with the modified provisioning information and is designated as a selected file; and The server modifies the file name of the target file to the file name of the selected file. The firmware verification and management method for server hardware components as described in claim 12, wherein the step of receiving the confirmation request from the client at the server further includes: The server releases an edit lock relationship of the file to be verified according to the confirmation request. The firmware verification and management method for server hardware components as described in claim 9, wherein the modified deployment information and at least one selected hardware function file are packaged as the target file on the server side The steps later include: The server adds a firmware version number to the target file.

Images