A hard disk bulk firmware upgrade method and system based on MCTP over SMBus

Abstract

The application discloses a hard disk batch firmware upgrading method and system based on MCTP over SMBus, and belongs to the technical field of computer hardware management. The method first carries out identity authentication by checking a firmware image and a hard disk to be upgraded, then broadcasts and transmits the image to data packets with unique identification, switches a unicast mode to query a state and establishes a global state table after sending a preset data unit, broadcast and retransmits missing data packets according to information in the table, and finally instructs the hard disk to verify the image in parallel and activates new firmware uniformly. The system comprises a BMC module, a plurality of hard disk devices and an SMBus network. The scheme combines the advantages of broadcasting and unicasting, improves the batch upgrading efficiency, guarantees the transmission integrity and upgrading reliability, strengthens the security and manageability, adapts to existing standard protocols and hardware interfaces, and is practical.

Description

Technical Field

[0001] This invention relates to the field of computer hardware management technology, and in particular to a method and system for batch firmware upgrade of hard drives based on MCTP over SMBus. Background Technology

[0002] In the current era of accelerated digital transformation, enterprise-level servers and data centers have become core infrastructure supporting various business operations. The amount of data they handle is exploding, and the corresponding scale of hard drive deployment is continuously expanding. As the core carrier of data storage, the firmware of hard drives, as the underlying operating program, directly affects the device's read / write performance, data security, and system compatibility. Therefore, maintaining firmware version consistency and up-to-date status is a crucial link in ensuring the stable operation of the entire IT system, and firmware upgrades have become an important part of daily data center operations and maintenance. Currently, the industry has formed various technical frameworks related to firmware upgrades. MCTP (Management Component Transfer Protocol) over SMBus (System Management Bus), with its standardized communication specifications, low power consumption, and good compatibility, has become the mainstream solution for out-of-band communication between the Baseboard Management Controller (BMC) and peripherals such as hard drives, providing reliable underlying protocol support for batch upgrades. Regarding data transmission methods, existing technologies commonly employ broadcast transmission and unicast transmission modes. Broadcast transmission can send data to multiple devices simultaneously via the common slave address of SMBus, while unicast transmission enables precise point-to-point communication between the master control unit and a single device. Each mode has its own application scenarios, providing basic technical support for firmware upgrades.

[0003] However, existing batch firmware upgrade technologies for hard drives still face many critical issues that urgently need to be addressed in practical applications, directly impacting the upgrade outcome. From the perspective of balancing transmission efficiency and reliability, relying solely on broadcast transmission, the master control unit employs a "send and forget" mechanism, unable to obtain the data packet reception status of each target hard drive, and unable to confirm whether the data has been completely received and processed correctly. Failure of any hard drive to receive data will result in an incomplete upgrade, severely affecting reliability. Conversely, using unicast transmission requires sending complete firmware data to each hard drive individually, resulting in a large amount of redundant transmission, excessive bus load, low upgrade efficiency, and difficulty in adapting to large-scale deployment scenarios. From a process control perspective, existing solutions lack a centralized status management mechanism, making it impossible to track the upgrade progress of each hard drive in real time, and difficult to accurately locate devices with reception anomalies and corresponding missing data. This leads to an inability to address anomalies effectively, resulting in a chaotic and uncontrollable upgrade process. From the perspective of the upgrade completion stage, existing technologies lack a coordinated mechanism for firmware verification and activation of each hard drive. The verification process is fragmented and time-consuming, and activation operations are asynchronous. Premature activation of some devices may cause system compatibility issues, affecting business continuity. These problems are intertwined, making it difficult for existing technologies to simultaneously meet the requirements of efficiency, reliability, controllability, and business continuity for large-scale hard drive firmware upgrades. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method and system for batch firmware upgrade of hard drives based on MCTP over SMBus.

[0005] The objective of this invention is achieved through the following technical solution:

[0006] A method for batch firmware upgrade of hard drives based on MCTP over SMBus is provided, which includes the following steps:

[0007] S1. Obtain the firmware image file and perform a security verification operation, and complete the identity handshake authentication with each hard drive to be upgraded through unicast;

[0008] S2. The verified firmware image data is divided into multiple data packets and broadcast sequentially to all hard drives to be upgraded via the public slave address of SMBus;

[0009] S3. After sending the preset data unit, switch to unicast mode to query the reception status of each hard drive to be upgraded one by one, receive the response information fed back by the hard drive and establish a global status table to record the relevant status of each hard drive.

[0010] S4. Based on the global status table, identify the hard drive with abnormal reception and the corresponding missing data packet. After retransmitting the missing data packet in broadcast mode, confirm the reception status again in unicast mode.

[0011] S5. After all data packets are transmitted, a verification command is sent to each hard drive to verify the firmware image in parallel. After successful verification, a broadcast command is sent to coordinate all hard drives to activate the new firmware in a unified manner.

[0012] Furthermore, step S1 includes:

[0013] S1.1: Decrypt the obtained firmware image file and verify its digital signature to confirm that the firmware image file is from a legitimate source and has not been tampered with;

[0014] S1.2: Send an authentication request to each hard drive to be upgraded in unicast form via the MCTP over SMBus protocol, receive the identity information returned by each hard drive to be upgraded, and complete two-way authentication.

[0015] Furthermore, step S2 includes:

[0016] S2.1: According to the data packet length limit of the SMBus transmission protocol, the firmware image data is divided into multiple independent data packets of equal length, and a unique identifier is assigned to each data packet;

[0017] S2.2: Switch the SMBus controller of the baseboard management controller to broadcast mode, and broadcast each data packet sequentially to the common slave address so that all hard drives to be upgraded can synchronously receive the firmware data stream.

[0018] Furthermore, step S3 includes:

[0019] S3.1: The preset data unit is a sequence of data packets or a complete data block. After the preset data unit is sent, the SMBus controller is switched to unicast mode.

[0020] S3.2: Access the dedicated address of each hard drive to be upgraded in a preset order and send a status query command;

[0021] S3.3: Receive confirmation responses, retransmission requests, or error status information from each hard drive to be upgraded, and record the upgrade progress, receiving status, and error flag of each hard drive to be upgraded in the global status table.

[0022] Furthermore, step S4 includes:

[0023] S4.1: Traverse the global status table, filter out the hard drives to be upgraded that have returned retransmission requests or timed out without response, and extract the missing data packet identifiers corresponding to these hard drives to be upgraded;

[0024] S4.2: Switch the SMBus controller to broadcast mode, first send a retransmission notification command, and then broadcast the missing data packets accordingly;

[0025] S4.3: After retransmission, switch to unicast mode, only query the status of the hard drives to be upgraded that have received abnormally, update the global status table, and repeat until all hard drives to be upgraded report successful reception.

[0026] Furthermore, in step S1.1, the decryption process of the firmware image file adopts an asymmetric encryption algorithm, and the digital signature verification is achieved by comparing the preset legal signature information with the signature information attached to the image file.

[0027] Furthermore, in step S2.1, a unique identifier assigned to each data packet is generated in association with the content of the data packet, and the identifier information includes the sequence number of the data packet and the data range characteristics.

[0028] Furthermore, in step S4, when retransmitting missing data packets, the broadcast retransmission notification instruction contains a unique identifier of the missing data packet, and the hard disk to be upgraded determines whether it needs to receive subsequent retransmitted data packets based on this identifier.

[0029] Furthermore, in step S5, when each hard drive to be upgraded verifies the firmware image in parallel, the integrity of the image data and its compatibility with its own hardware are verified according to the preset verification rules, and the verification results are fed back to the baseboard management controller through the MCTP over SMBus protocol.

[0030] In some embodiments, a hard disk bulk firmware upgrade system based on MCTP over SMBus is provided, the system including a baseboard management controller module, multiple hard disk devices and an SMBus network;

[0031] The SMBus network connects the baseboard management controller module and all hard disk devices. The baseboard management controller module includes a protocol processing unit, a broadcast / unicast control unit, a status management unit, and a security authentication unit. The protocol processing unit is used for encapsulating and decapsulating MCTP / PLDM messages. The broadcast / unicast control unit is used for switching the SMBus communication mode. The status management unit is used for maintaining a global status table. The security authentication unit is used for firmware image verification and device authentication. The hard disk devices support the MCTP over SMBus protocol and include a firmware storage area and a receive buffer.

[0032] The beneficial effects of this invention are:

[0033] (1) Adopting a hybrid communication mode of “broadcast transmission + unicast confirmation”, coupled with status recording and intelligent retransmission, and a unified activation process, greatly reduces duplicate data transmission, ensures that all target devices receive data completely, and efficiently promotes batch upgrades;

[0034] (2) Integrating firmware image security verification, device identity two-way authentication and transmission data verification mechanisms, it blocks malicious firmware injection and unauthorized access from the source, avoids security risks in the upgrade process, and ensures that the upgrade is trustworthy and controllable;

[0035] (3) Real-time tracking of upgrade status and accurate location of anomalies are achieved by relying on the global status table. It is compatible with existing standard protocols and hardware interfaces, requires no additional hardware investment, reduces the difficulty of operation and maintenance, and takes into account both compatibility and practical value. Attached Figure Description

[0036] Figure 1 A flowchart outlining the specific steps of a batch firmware upgrade method for hard drives based on MCTP over SMBus;

[0037] Figure 2 This is a system architecture diagram for a batch firmware upgrade system for hard drives based on MCTP over SMBus.

[0038] Figure 3 This is a flowchart illustrating the steps of a batch firmware upgrade method for hard drives based on MCTP over SMBus, provided as an example. Detailed Implementation

[0039] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] Example 1

[0041] See Figure 1 This paper provides a method for batch firmware upgrade of hard drives based on MCTP over SMBus, which includes the following steps:

[0042] S1: Obtain the firmware image file and perform a security verification operation, and complete the identity handshake authentication with each hard drive to be upgraded through unicast;

[0043] S2: The verified firmware image data is divided into multiple data packets and broadcast sequentially to all hard drives to be upgraded via the public slave address of SMBus;

[0044] S3: After sending the preset data unit, switch to unicast mode to query the reception status of each hard drive to be upgraded one by one, receive the response information fed back by the hard drive and establish a global status table to record the relevant status of each hard drive.

[0045] S4: Identify the hard drives with reception errors and the corresponding missing data packets based on the global status table. After retransmitting the missing data packets in broadcast mode, confirm the reception status again in unicast mode. S5: After all data packets have been transmitted, send a verification command to each hard drive to verify the firmware image in parallel. After successful verification, send a broadcast command to coordinate all hard drives to activate the new firmware.

[0046] Step S1 includes:

[0047] S1.1: Decrypt the obtained firmware image file and verify its digital signature to confirm that the firmware image file is from a legitimate source and has not been tampered with;

[0048] S1.2: Send an authentication request to each hard drive to be upgraded in unicast form via the MCTP over SMBus protocol, receive the identity information returned by each hard drive to be upgraded, and complete two-way authentication.

[0049] Step S2 includes:

[0050] S2.1: According to the data packet length limit of the SMBus transmission protocol, the firmware image data is divided into multiple independent data packets of equal length, and a unique identifier is assigned to each data packet;

[0051] S2.2: Switch the SMBus controller of the baseboard management controller to broadcast mode, and broadcast each data packet sequentially to the common slave address so that all hard drives to be upgraded can synchronously receive the firmware data stream.

[0052] Step S3 includes:

[0053] S3.1: The preset data unit is a sequence of data packets or a complete data block. After the preset data unit is sent, the SMBus controller is switched to unicast mode.

[0054] S3.2: Access the dedicated address of each hard drive to be upgraded in a preset order and send a status query command;

[0055] S3.3: Receive confirmation responses, retransmission requests, or error status information from each hard drive to be upgraded, and record the upgrade progress, receiving status, and error flag of each hard drive to be upgraded in the global status table.

[0056] Step S4 includes:

[0057] S4.1: Traverse the global status table, filter out the hard drives to be upgraded that have returned retransmission requests or timed out without response, and extract the missing data packet identifiers corresponding to these hard drives to be upgraded;

[0058] S4.2: Switch the SMBus controller to broadcast mode, first send a retransmission notification command, and then broadcast the missing data packets accordingly;

[0059] S4.3: After retransmission, switch to unicast mode, only query the status of the hard drives to be upgraded that have received abnormally, update the global status table, and repeat until all hard drives to be upgraded report successful reception.

[0060] In step S1.1, the decryption of the firmware image file adopts an asymmetric encryption algorithm, and the digital signature verification is achieved by comparing the preset legal signature information with the signature information attached to the image file.

[0061] In step S2.1, a unique identifier is generated by associating the unique identifier assigned to each data packet with the content of the data packet. The identifier information includes the sequence number of the data packet and the data range characteristics.

[0062] In step S4, when a missing data packet is retransmitted, the broadcast retransmission notification instruction contains a unique identifier of the missing data packet. The hard disk to be upgraded determines whether it needs to receive subsequent retransmitted data packets based on this identifier.

[0063] In step S5, when each hard drive to be upgraded verifies the firmware image in parallel, the integrity of the image data and its compatibility with its own hardware are verified according to the preset verification rules. The verification results are fed back to the baseboard management controller through the MCTP over SMBus protocol.

[0064] In some embodiments, see Figure 2 This paper presents a hard drive batch firmware upgrade system based on MCTP over SMBus, which includes a baseboard management controller module, multiple hard drive devices and an SMBus network;

[0065] The SMBus network connects the baseboard management controller module and all hard disk devices. The baseboard management controller module includes a protocol processing unit, a broadcast / unicast control unit, a status management unit, and a security authentication unit. The protocol processing unit is used for encapsulating and decapsulating MCTP / PLDM messages. The broadcast / unicast control unit is used for switching the SMBus communication mode. The status management unit is used for maintaining a global status table. The security authentication unit is used for firmware image verification and device authentication. The hard disk devices support the MCTP over SMBus protocol and include a firmware storage area and a receive buffer.

[0066] Example 2

[0067] See Figure 3This paper provides a method for batch firmware upgrades of hard drives based on MCTP over SMBus, and a corresponding system setup. This embodiment is based on the MCTP (Management Component Transport Protocol) over SMBus (System Management Bus) protocol architecture, providing a complete and standardized implementation process for batch firmware upgrades in large-scale hard drive deployment scenarios. This embodiment uses the Baseboard Management Controller (BMC) as the upgrade master control terminal, fully utilizing the standardized advantages of the MCTP protocol in inter-component communication and the low-cost, low-power characteristics of the SMBus bus. Through a hybrid communication mode combining broadcast transmission and unicast confirmation, coupled with centralized status management and a full-process security control mechanism, it achieves efficient and reliable upgrades of multiple hard drive devices supporting the MCTP over SMBus protocol. Throughout the implementation process, the various functional units of the BMC (protocol processing unit, broadcast / unicast control unit, status management unit, and security authentication unit) will work collaboratively according to a preset timing logic. Each hard drive to be upgraded responds to the BMC's instructions through its own MCTP endpoint and SMBus interface module, completing a series of operations such as data reception, verification, authentication, and activation. Figure 3 As shown, the specific steps are as follows:

[0068] S1. Upgraded Preprocessing and Security Authentication:

[0069] Step S1 serves as the foundational safeguard for the entire batch upgrade process. Its core objective is to ensure the legitimacy and integrity of the firmware image and the authorization of the hard drive to be upgraded, mitigating upgrade risks from the outset and laying a secure and reliable foundation for subsequent upgrade operations. The execution quality of this step directly impacts the security and stability of the entire upgrade process; therefore, it must strictly adhere to preset security specifications and operational sequences. This step mainly comprises two sub-steps: security verification of the firmware image and identity authentication of the hard drive to be upgraded. The entire process is led by the BMC's security authentication unit, with the protocol processing unit providing data transmission and format conversion support. The two components achieve real-time data interaction and status synchronization through an internal data bus.

[0070] S1.1: Firmware Image Decryption and Digital Signature Verification. The BMC first obtains the firmware image file to be deployed, which is the core data carrier for subsequent upgrade operations. To prevent malicious firmware injection or tampering of the image file during transmission, the BMC performs strict security verification on the obtained firmware image file. The decryption process uses an asymmetric encryption algorithm, employing a preset decryption key to decrypt the encrypted firmware image, ensuring that only authorized BMC devices can obtain complete firmware data. Digital signature verification is achieved by comparing preset legitimate signature information with the signature information attached to the firmware image file. The BMC's security authentication unit extracts the digital signature from the image file and matches it with the locally stored legitimate signature public key. If the verification matches, the firmware image is confirmed to be legitimate and untampered; if the verification does not match, the upgrade process is terminated directly, and a security verification failure log is recorded to prevent unauthorized images from entering subsequent transmission stages.

[0071] In practical implementation, the transmission channel for obtaining the firmware image file can be flexibly selected according to the actual deployment scenario. It can be obtained by reading from local storage media or by transmitting via an encrypted network. Regardless of the method used, data encryption protection must be enabled during the transmission process to prevent the image file from being intercepted and tampered with. At the same time, the key for the asymmetric encryption algorithm must be stored in the BMC's secure encryption chip, and hardware-level protection must be used to prevent key leakage. During the decryption process, data integrity must also be verified in real time. If data corruption is detected, the process will be terminated immediately and an alarm will be triggered.

[0072] S1.2: Identity Handshake Authentication for Hard Drives to be Upgraded. After completing the security verification of the firmware image, the BMC needs to confirm the legitimacy of all hard drives to be upgraded to prevent unauthorized devices from accessing the upgrade process. The BMC sends an identity authentication request to each hard drive in the list of hard drives to be upgraded via unicast, based on the MCTP overSMBus protocol. This request message is encapsulated into a standard MCTP / PLDM message format by the BMC's protocol processing unit and transmitted to the target hard drive's dedicated address via the SMBus network. Upon receiving the identity authentication request, each hard drive to be upgraded extracts a unique identifier (such as device serial number and hardware model identifier) ​​and supported protocol version information from its stored device information, encapsulates it via the MCTP endpoint, and sends it back to the BMC. After receiving the identity information from each hard drive, the BMC's security authentication unit compares it with a preset list of authorized devices to verify whether the hard drive is a legitimate target allowed to participate in this upgrade. BMC will only complete two-way authentication with the hard drive and include it in the set of valid upgrade targets if the identity information completely matches the authorized list. If the identity information does not match or no feedback is received within the time limit, the hard drive will be marked as an illegal device or a device with communication abnormality, excluded from the subsequent upgrade process, and the corresponding authentication abnormality status will be recorded.

[0073] In practice, the list of hard drives to be upgraded needs to be imported into the BMC in advance using the system configuration tool. Besides the hard drive device identifier and its unique SMBus address, the list also needs to include basic information such as the hard drive's hardware model and manufacturing batch, facilitating the BMC's rapid compatibility pre-assessment during the certification process. The authentication request message encapsulation also needs to include a timeout field. The timeout period can be dynamically configured based on the bus transmission distance and environmental interference, typically set to 1-3 seconds. If no response is received after the preset time, it is automatically determined to be a communication anomaly, and the device identifier is recorded.

[0074] S2. Broadcast transmission of firmware data:

[0075] The core of step S2 is to utilize the broadcast function of SMBus to efficiently distribute firmware data to all legitimate hard drives awaiting upgrade. This "one-to-many" transmission mode reduces redundant data transmission on the bus, lowers bus occupancy, and improves overall upgrade efficiency. The key to this step is balancing transmission efficiency and data stability, requiring strict control over data packet size, transmission timing, and format specifications to ensure all legitimate hard drives can receive firmware data synchronously and accurately. This step is executed under the coordinated control of the BMC's broadcast / unicast control unit and protocol processing unit. The status management unit monitors the transmission status in real time, and the security authentication unit verifies the transmitted data in real time. Each unit synchronizes data and status through an internal coordination mechanism. Specifically, it includes the following two sub-steps:

[0076] S2.1: Firmware Image Data Segmentation and Identification Assignment. Firmware image data that has passed security authentication in step S1 must be segmented according to the data packet length limits of the SMBus transmission protocol, forming multiple independent data packets of equal length. The segmentation process strictly adheres to the SMBus protocol's specifications for single-transmission data volume, ensuring that each data packet can be transmitted stably on the bus and avoiding transmission timeouts or data loss due to excessively long data packets. Simultaneously, to facilitate subsequent status tracking and retransmission control, a unique identifier must be assigned to each segmented data packet. This unique identifier is generated in association with the data packet content, and the identifier information includes the data packet's sequential number and data range characteristics, enabling each data packet to be accurately identified by the BMC and hard disk device, providing a basis for subsequent reception status confirmation and missing data packet location.

[0077] In practice, the size of the data packet segment is not a fixed value and needs to be dynamically adjusted based on the actual transmission rate of the SMBus bus and the capacity of the hard disk receive buffer. For example, when the bus transmission rate is low or the hard disk buffer is small, the data packet size can be set to a smaller value to reduce the pressure of a single transmission; if the transmission environment is stable and the hard disk buffer is sufficient, the data packet size can be appropriately increased to improve transmission efficiency. A checksum field can also be added to the generation of the unique identifier to further ensure the uniqueness and accuracy of the identifier information and avoid data packet confusion caused by duplicate identifiers.

[0078] S2.2: Broadcast Mode Switching and Firmware Data Transmission. The BMC's broadcast / unicast control unit switches the SMBus controller's communication mode to broadcast mode, targeting the SMBus's common slave address to prepare for data transmission. Before transmission, the protocol processing unit encapsulates each uniquely identified data packet into a transmission format conforming to the MCTP over SMBus protocol specification, ensuring that the hard drive device can correctly parse the data content. Subsequently, the BMC sequentially sends all data packets through the SMBus network in broadcast mode, numbered according to their order. Due to the "one-to-many" transmission characteristic of broadcast mode, all authenticated hard drives to be upgraded synchronously listen to the data stream on the common slave address, receiving firmware data packets sent by the BMC in real time, and temporarily storing the received data in their own receive buffer. During this process, all target hard drives receive the same firmware data stream, eliminating the need for the BMC to send data to each hard drive individually, significantly reducing bus transmission pressure and data transmission time.

[0079] In practical implementation, after the SMBus controller switches to broadcast mode, it must first send a mode switch confirmation frame. Only after all legitimate hard drives awaiting upgrade provide confirmation responses will the broadcast transmission of firmware data packets begin. This prevents some hard drives from missing data due to incomplete mode switching. The data packet transmission interval needs to be pre-calibrated through bus load testing, typically set to 5-10 milliseconds. This ensures that the hard drives have sufficient time to receive and process data without excessively reducing transmission efficiency. Simultaneously, the BMC monitors the bus transmission status in real time. If a bus conflict or transmission error is detected, transmission is immediately paused and a resynchronization command is sent. Transmission resumes only after the bus stabilizes.

[0080] S3. Unicast Polling Confirmation and Status Collection:

[0081] While a simple broadcast transmission mode can improve transmission efficiency, it suffers from the inherent "fire-and-forget" flaw. The BMC cannot know the actual reception status of each hard drive to be upgraded. If data packets are lost or corrupted due to bus interference, buffer overflow, or other reasons, the integrity of the upgrade will be directly affected. Therefore, step S3 uses unicast polling to accurately obtain the data packet reception status of each hard drive to be upgraded, establishing a centralized global status management mechanism to provide accurate data for subsequent error handling and intelligent retransmission. This step is crucial for ensuring upgrade reliability and requires comprehensive, accurate, and efficient status querying. This step is led by the BMC's status management unit, which is responsible for the initialization, updating, and analysis of the status table. The broadcast / unicast control unit is responsible for switching communication modes and controlling polling timing. The protocol processing unit is responsible for encapsulating query commands, decapsulating response messages, and transmitting data. These units work closely together through internal collaborative interfaces, specifically including the following three sub-steps:

[0082] S3.1: Communication Mode Switching and Polling Preparation. After the BMC completes the broadcast transmission of a preset data unit (which can be a sequence of data packets or a complete data block), the broadcast / unicast control unit switches the SMBus controller from broadcast mode to unicast mode, preparing to initiate the reception status query for each hard drive to be upgraded. Simultaneously, the status management unit initializes a global status table. This table records information such as the device identifier, current upgrade progress, list of received data packet identifiers, reception status, and anomaly identifiers for each hard drive to be upgraded, providing a data carrier for subsequent status tracking and management.

[0083] In practical implementation, the size of the preset data unit can be dynamically configured according to the upgrade scale. For large-scale hard disk cluster upgrades, the preset data unit can be set to a sequence containing 10-20 consecutive data packets to reduce the number of polling times; for small-scale upgrades, it can be set to a complete data block to improve polling efficiency. The global status table is stored in a structured database, supporting fast querying and batch updates. A "last interaction time" field can also be added to the table to facilitate BMC's quick identification of abnormal hard disks that have been unresponsive for a long time. The update operation of the status table needs to add a locking mechanism to avoid data corruption caused by multi-threaded concurrent updates.

[0084] S3.1.1: Polling Parameter Configuration and Command Pre-generation. After completing the polling preparation, the status management unit transmits polling parameters to the protocol processing unit, including the unique address of each hard drive to be upgraded, query timeout, and retry threshold. The protocol processing unit pre-generates corresponding status query commands based on these parameters. The commands are pre-filled with fixed fields such as the target address and data unit identifier, retaining only the dynamically verified fields after the response is received, thereby reducing the time spent on real-time command generation and improving polling efficiency. Simultaneously, the protocol processing unit performs format verification on the pre-generated commands to ensure they conform to the MCTP / PLDM protocol specifications, avoiding query failures due to incorrect command formats.

[0085] S3.2: Unicast Status Query. The BMC accesses the dedicated address of each hard drive to be upgraded in a preset order (which may be based on the sorting rules of the hard drive device identifier), sending a status query command via unicast. This command is encapsulated into MCTP / PLDM format by the protocol processing unit and transmitted to the target hard drive via the SMBus network. Upon receiving the status query command, each hard drive to be upgraded verifies the data packets in its receive buffer to confirm the integrity and continuity of the received data packets, and generates corresponding response information based on the verification results. Response information includes an acknowledgment response (ACK, indicating that the corresponding data unit has been successfully received and verified), a retransmission request (NACK, indicating that some data packets are missing or verification failed, requiring retransmission), or an error status (indicating hardware malfunctions or protocol parsing failures).

[0086] In practical implementation, the preset order of unicast queries can be customized through configuration files, supporting various sorting methods such as ascending / descending order by hard drive physical location and device identifier, facilitating maintenance personnel to track upgrade status according to actual management needs. The status query command must carry the identifier information of preset data units to ensure the hard drive can accurately locate the range of data packets requiring verification. The hard drive's verification process for the receive buffer must employ a fast verification algorithm to shorten verification time while ensuring accuracy, avoiding BMC query timeouts due to excessively long verification times.

[0087] S3.3: Status Information Reception and Global Status Table Update. After receiving the response information from each hard drive to be upgraded, the BMC's SMBus controller transmits it to the protocol processing unit. The protocol processing unit decapsulates the response information, extracting key status data such as device identifier, response type, data packet identifier list, and error information. Simultaneously, it verifies the completeness and timeliness of the response information. If the response information is found to be corrupted or the timestamp expired, it is marked as an invalid response, and the corresponding device identifier and reason for invalidity are recorded. Valid status data that passes verification is transmitted by the protocol processing unit to the status management unit. The status management unit updates the corresponding hard drive entries in real time based on the extracted status data and existing records in the global status table: For hard drives that return ACK, their upgrade progress is updated to "current data unit received successfully," the list of received data packet identifiers is updated synchronously, the reception status is marked as "successful," and the last response time is recorded; for hard drives that return NACK, the list of missing data packet identifiers is accurately recorded, the reception status is marked as "retransmission required," the reason for failure is recorded, and the upgrade progress remains at the percentage of currently received data packets; for hard drives that return error status or timeout without response, their status is marked as "abnormal," and the abnormality type (hardware failure / protocol parsing failure / no response), fault code (if any), and occurrence time are recorded in detail, and the upgrade progress update is paused. During the update process, the status management unit cross-validates the status data to ensure data consistency, for example, by comparing the list of received data packet identifiers with the total data packet list to confirm the accuracy of the upgrade progress calculation. Through this process, the BMC can comprehensively and accurately grasp the reception status of each hard drive to be upgraded, achieving transparent management of the upgrade process and providing accurate abnormal data support for subsequent intelligent retransmission. In addition, the state management unit regularly backs up the global state table to prevent the loss of state data due to temporary BMC failures. The backup data is stored in a non-volatile storage module, which can quickly restore the state table after the failure is recovered.

[0088] S4. Intelligent retransmission and error handling:

[0089] For hard drives exhibiting reception anomalies (NACK feedback or timeout failure) detected in step S3, failure to address these anomalies can lead to incomplete upgrades for some drives, impacting the overall upgrade outcome. Therefore, step S4 employs intelligent analysis and targeted retransmission mechanisms to accurately locate missing data packets. It utilizes a "broadcast retransmission + unicast confirmation" model to ensure each hard drive to be upgraded receives all firmware data packets, guaranteeing the reliability of the upgrade process. This step requires accurate anomaly analysis, efficient retransmission, and real-time status updates to avoid wasting bus resources and increasing upgrade time due to indiscriminate retransmission. This step is executed collaboratively by the BMC's status management unit, broadcast / unicast control unit, and protocol processing unit. The security authentication unit performs real-time verification of the retransmitted data. Each unit ensures smooth execution of the retransmission process through internal data interaction and status synchronization mechanisms. Specifically, it includes the following three sub-steps:

[0090] S4.1: Anomaly Information Analysis and Missing Data Packet Extraction. The state management unit traverses the global state table, filtering out hard drives awaiting upgrade that have responded with a retransmission request (NACK) or have timed out and failed to respond, forming a list of abnormal hard drives. For hard drives that responded with a NACK, the missing data packet identifiers are extracted from their response information; for hard drives that timed out and failed to respond, the possible missing data packet identifiers are inferred by combining the list of received data packet identifiers with the complete data packet sequence. The state management unit summarizes and statistically analyzes the missing data packet identifiers of all abnormal hard drives to determine the set of data packets that need to be retransmitted, avoiding inefficiency caused by blind retransmission.

[0091] In practical implementation, the anomaly analysis process needs to distinguish between temporary and permanent anomalies. For hard drives that fail to respond to a single timeout due to transient bus interference, they can be marked as "suspected anomalies" and given priority for secondary queries. For hard drives that return NACK multiple times or fail to respond to two consecutive timeouts, they should be marked as "confirmed anomalies" and included in the priority retransmission list. The summary statistics of missing data packets should use a deduplication algorithm to prioritize data packets that are missing from multiple abnormal hard drives in the retransmission sequence to reduce the number of retransmissions. At the same time, the frequency of missing data packets should be recorded. If a data packet is missing from multiple hard drives, it is necessary to investigate whether there is a problem with the initial broadcast transmission process of that data packet.

[0092] S4.2: Targeted Broadcast Retransmission of Missing Data Packets. The BMC's broadcast / unicast control unit switches the SMBus controller back to broadcast mode. The protocol processing unit first generates a retransmission notification command, which contains the unique identifier of the data packet to be retransmitted. After encapsulation, this command is broadcast to all hard drives to be upgraded via the common slave address. Upon receiving the retransmission notification command, each hard drive to be upgraded parses the data packet identifier to determine if it is missing the corresponding data packet: for hard drives that do not need the data packet, subsequent retransmissions are automatically ignored; for abnormal hard drives that are indeed missing the data packet, preparations are made to receive it. Subsequently, the BMC sends the aggregated missing data packets sequentially via broadcast mode. Abnormal hard drives receive these packets in real time and replenish them in their receive buffers, completing the repair of missing data.

[0093] In practical implementation, a confirmation mechanism needs to be added to the retransmission notification command. After the BMC sends the notification command, it waits for the abnormal hard drives to provide confirmation within a preset time. If a sufficient number of confirmation responses are not received, the notification command is resent to ensure that all abnormal hard drives are accurately aware of the retransmission data packets that need to be received. The transmission rate of retransmission data packets can be appropriately lower than the initial broadcast rate, typically reduced to 70%-80% of the initial rate, and the data packet transmission interval is extended to improve the success rate of retransmission data reception. At the same time, the bus status is monitored in real time during the retransmission process to avoid excessive bus load due to retransmission.

[0094] S4.3: Retransmission Result Unicast Confirmation and Status Update. After the missing data packet is broadcast retransmitted, the protocol processing unit sends a mode switching request to the broadcast / unicast control unit. The broadcast / unicast control unit then switches the SMBus controller to unicast mode again, completes parameter configuration, and sends back a ready signal. Unlike the full polling in step S3, to improve confirmation efficiency and reduce bus resource consumption, the BMC only sends status query commands to the abnormal hard drives selected in S4.1, without needing to poll all hard drives. The status query command is generated by the protocol processing unit, using the same MCTP / PLDM format as step S3. The command content includes the query type (retransmission result confirmation), a list of retransmitted data packet identifiers, and the device-specific address, ensuring that only the target abnormal hard drive responds. After receiving the query command, each abnormal hard drive performs integrity and continuity checks on the supplementary received data packets and regenerates the reception status response information: if all missing data packets are successfully received and verified, an ACK response is sent, containing the device identifier, retransmission success identifier, and an updated list of received data packet identifiers; if some data packets are still missing or verification fails, a NACK response is sent, specifying the identifiers of the remaining missing data packets; if no response is received within the timeout period or an error status is reported, it is marked as a persistent abnormality. The response information from each abnormal hard drive is transmitted to the BMC via the SMBus network, where the protocol processing unit decapsulates and verifies it, extracting the valid status data and transmitting it to the status management unit. The status management unit updates the global status table based on the feedback results: If the abnormal hard drive returns ACK, it means that the missing data packet has been successfully received and verified, and its reception status is updated to "normal". The upgrade progress and the list of received data packet identifiers are updated simultaneously, and the retransmission completion time is recorded. If it still returns NACK, its list of missing data packet identifiers is updated, the reception status is kept at "retransmission required", and the number of retransmissions is recorded. If the number of retransmissions reaches a preset threshold and still fails, its status is upgraded to "critically abnormal", and the subsequent retransmission process is suspended. If an error status is returned or there is no response after a timeout, the "abnormal" status is maintained, and the duration of the continuous abnormality and related information are recorded. This retransmission and acknowledgment process is executed cyclically until the reception status of all hard drives to be upgraded in the global status table is marked as "normal", that is, all data packets have been successfully received, or some hard drives have reached the retransmission threshold and are marked as "critically abnormal" and isolated. During the loop, the state management unit dynamically adjusts the retransmission strategy. For example, for data packets that fail to be retransmitted multiple times, the transmission rate can be appropriately reduced or the sending interval can be increased to improve transmission stability. For hard drives that are continuously abnormal, they will be isolated from the upgrade process in a timely manner to avoid affecting the upgrade progress of other hard drives.

[0095] S5. Batch Verification and Activation:

[0096] After all firmware data packets have been successfully transmitted to each hard drive to be upgraded, batch verification is required to ensure the integrity and availability of the firmware image. Then, a unified activation operation is performed to achieve a smooth rollout of the new firmware, minimizing the impact on system business continuity. Step S5, as the final stage of the upgrade process, directly determines the final upgrade outcome and requires strict control over the comprehensiveness of verification and the synchronization of activation. This step is uniformly scheduled by the BMC, with each hard drive to be upgraded executing collaboratively. The BMC's status management unit monitors the verification and activation progress in real time, the protocol processing unit is responsible for transmitting instructions and parsing response messages, and the security authentication unit performs a secondary verification of the verification results to ensure the reliability and security of the entire process. The specific process is as follows:

[0097] S5.1: Firmware Image Verification Command Distribution and Parallel Verification Initiation. The BMC first sends a firmware image verification command to all hard drives to be upgraded via unicast. The command includes integrity verification rules and compatibility verification requirements for the firmware image. Upon receiving the command, each hard drive initiates a parallel verification process: on one hand, it reassembles all firmware data packets in the received buffer according to preset verification rules to restore the complete firmware image and verifies the integrity of the image data, confirming that the reassembled image is consistent with the original image sent by the BMC, with no missing or tampered data; on the other hand, it verifies the compatibility of the firmware image with its own hardware, confirming that the firmware version matches the hardware model and protocol version, and that it can operate normally. After each hard drive completes verification, it feeds back the verification result (verification passed or failed) to the BMC via the MCTP over SMBus protocol. The BMC's protocol processing unit decapsulates the feedback message, and the status management unit updates the verification result record in the global status table.

[0098] In practical implementation, the parallel execution of the batch verification process needs to be achieved through the multi-threaded processing mechanism inside the hard drive. Image reconstruction, integrity verification, and compatibility verification are distributed to different threads for synchronous processing, shortening the verification time for a single hard drive. Integrity verification employs a combination of overall verification and comparison with segmented verification. Segmented verification first quickly locates potentially problematic segments, and then performs precise verification on those segments, improving verification efficiency. Compatibility verification needs to cover the core hardware modules of the hard drive, including the storage controller, interface module, and cache module, ensuring that the new firmware is compatible with all hardware components of the hard drive.

[0099] S5.2: Unified Activation Command Sending and Synchronous Reboot Execution. Once the BMC confirms that the firmware images of all hard drives to be upgraded have passed verification, it sends a unified activation command via broadcast. This command includes a preset reboot cycle, specifying the activation time for the new firmware. Each hard drive to be upgraded, upon receiving the activation command, writes the verified firmware image from its receive cache into its own firmware storage area and, according to the reboot cycle specified in the command, synchronously completes the reboot operation without affecting current business operations. During the reboot process, each hard drive maintains communication with the SMBus network, providing real-time feedback on activation progress and results to the BMC. Once all hard drives have successfully rebooted and activated the new firmware, the BMC's status management unit marks the upgrade status of all hard drives in the global status table as "Upgrade Complete," officially ending the batch firmware upgrade process. If some hard drives fail verification or activation, the BMC records the identifier of the failed device and the reason for the failure for subsequent targeted troubleshooting and handling.

[0100] In practice, the preset restart cycle needs to be optimized to avoid peak business periods. Typically, a restart window is set during off-peak hours. The restart cycle includes preparation time, restart execution time, and recovery time, ensuring the hard drive has sufficient time to complete firmware writing and system restart. During activation, the hard drive must first back up its current operating status data to a temporary storage area. If activation fails, the system can be quickly restored to its pre-upgrade state using the backup data, reducing upgrade risks. When receiving activation progress feedback, if the BMC detects a hard drive stuck in an activation phase for an extended period, it will send a status query command to obtain detailed information and, if necessary, send a forced restart or recovery command.

[0101] The hard drive batch firmware upgrade method based on MCTP over SMBus described in this embodiment achieves multiple technical benefits through a hybrid communication mode combining broadcast transmission and unicast confirmation, a centralized status management mechanism, and an end-to-end security authentication process. In terms of transmission efficiency, leveraging the "one-to-many" transmission advantage of broadcast mode, firmware data is distributed to all target hard drives at once, avoiding the repetitive data transmission caused by traditional unicast's one-to-one transmission, significantly reducing bus transmission pressure and upgrade time. Simultaneously, the intelligent retransmission mechanism only broadcasts missing data packets, eliminating the need to retransmit complete data. Combined with accurate unicast confirmation after retransmission, this further improves overall upgrade efficiency, making it particularly suitable for large-scale hard drive deployment scenarios. Regarding reliability, the unicast polling confirmation mechanism allows the master control unit to fully grasp the reception status of each hard drive, completely solving the problem of unknown reception status caused by the "send and forget" approach of simple broadcast. Combined with real-time updates of the global status table and a cyclic retransmission mechanism, it ensures that all hard drives to be upgraded can completely receive firmware data, avoiding incomplete upgrades due to the failure of a single node. Furthermore, the retransmission threshold setting effectively isolates continuously malfunctioning devices, ensuring the smooth progress of the overall upgrade process. In terms of security, the pre-upgrade firmware image decryption, digital signature verification, and two-way device identity authentication construct a dual security protection system, effectively preventing malicious firmware flashing and unauthorized device access. This avoids security risks during the upgrade process from the source, ensuring the security and reliability of the upgrade process. Real-time verification of transmitted data during the upgrade process further enhances data security, preventing data tampering or damage during transmission. Regarding manageability, the establishment of a global status table makes the status of each node in the upgrade process clear and traceable, facilitating real-time monitoring of upgrade progress, accurate location of abnormal nodes and causes of failures, and reducing the complexity and difficulty of operation and maintenance management. The time-series coordination and unit linkage mechanism of each step makes the entire upgrade process highly controllable. Operation and maintenance personnel can quickly grasp the overall upgrade situation through the status table without having to check the device status one by one. In terms of compatibility and practicality, this method is built on the existing SMBus hardware interface and MCTP / PLDM standard protocol, requiring no additional hardware costs. Large-scale batch upgrades of hard drives can be achieved solely through process and mechanism innovation. It can adapt to different models and batches of hard drive devices supporting the MCTP over SMBus protocol, possessing broad compatibility and strong engineering practicality. In addition, the unified activation mechanism ensures that all hard drives are switched to the new firmware simultaneously, avoiding system compatibility issues caused by premature activation of some hard drives, minimizing the impact of upgrade operations on business continuity, and ensuring the stability of system operation.

[0102] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for batch firmware upgrade of hard drives based on MCTP over SMBus, characterized in that, Includes the following steps: S1. Obtain the firmware image file and perform a security verification operation, and complete the identity handshake authentication with each hard drive to be upgraded through unicast; S2. The verified firmware image data is divided into multiple data packets and broadcast sequentially to all hard drives to be upgraded via the public slave address of SMBus; S3. After sending the preset data unit, switch to unicast mode to query the reception status of each hard drive to be upgraded one by one, receive the response information fed back by the hard drive and establish a global status table to record the relevant status of each hard drive. S4. Based on the global status table, identify the hard drive with reception error and the corresponding missing data packet. After retransmitting the missing data packet in broadcast mode, confirm the reception status again in unicast mode. S5. After all data packets are transmitted, a verification command is sent to each hard drive to verify the firmware image in parallel. After successful verification, a broadcast command is sent to coordinate all hard drives to activate the new firmware in a unified manner. Step S1 includes: S1.1: Decrypt the obtained firmware image file and verify its digital signature to confirm that the firmware image file is from a legitimate source and has not been tampered with; S1.2: Send an authentication request to each hard drive to be upgraded in unicast form via the MCTP over SMBus protocol, receive the identity information returned by each hard drive to be upgraded and complete the two-way authentication; Step S3 includes: S3.1: The preset data unit is a sequence of data packets or a complete data block. After the preset data unit is sent, the SMBus controller is switched to unicast mode. S3.2: Access the dedicated address of each hard drive to be upgraded in a preset order and send a status query command; S3.3: Receive confirmation responses, retransmission requests or error status information from each hard drive to be upgraded, and record the upgrade progress, receiving status and error identifier of each hard drive to be upgraded in the global status table; Step S4 includes: S4.1: Traverse the global status table, filter out the hard drives to be upgraded that have returned retransmission requests or timed out without responding, and extract the missing data packet identifier corresponding to the hard drive to be upgraded; S4.2: Switch the SMBus controller to broadcast mode, first send a retransmission notification command, and then broadcast the missing data packets accordingly; S4.3: After retransmission, switch to unicast mode, only query the status of the hard drives to be upgraded that have received abnormally, update the global status table, and repeat until all hard drives to be upgraded report successful reception.

2. The method according to claim 1, characterized in that, Step S2 includes: S2.1: According to the data packet length limit of the SMBus transmission protocol, the firmware image data is divided into multiple independent data packets of equal length, and a unique identifier is assigned to each data packet; S2.2: Switch the SMBus controller of the baseboard management controller to broadcast mode, and broadcast each data packet sequentially to the common slave address so that all hard drives to be upgraded can synchronously receive the firmware data stream.

3. The method according to claim 1, characterized in that, In step S1.1, the decryption of the firmware image file adopts an asymmetric encryption algorithm, and the digital signature verification is achieved by comparing the preset legal signature information with the signature information attached to the image file.

4. The method according to claim 1, characterized in that, In step S2.1, a unique identifier is generated by associating the unique identifier assigned to each data packet with the content of the data packet. The identifier information includes the sequence number of the data packet and the data range characteristics.

5. The method according to claim 1, characterized in that, In step S4, when a missing data packet is retransmitted, the broadcast retransmission notification instruction contains a unique identifier of the missing data packet. The hard disk to be upgraded determines whether it needs to receive subsequent retransmitted data packets based on this identifier.

6. The method according to claim 1, characterized in that, In step S5, when each hard drive to be upgraded verifies the firmware image in parallel, the integrity of the image data and its compatibility with its own hardware are verified according to the preset verification rules. The verification results are fed back to the baseboard management controller through the MCTP over SMBus protocol.

7. A hard disk batch firmware upgrade system implementing the method of any one of claims 1-6, characterized in that, Includes a baseboard management controller module, multiple hard disk devices, and an SMBus network; The SMBus network connects the baseboard management controller module to all hard disk devices; the baseboard management controller module includes a protocol processing unit, a broadcast / unicast control unit, a status management unit, and a security authentication unit; the protocol processing unit is used for encapsulating and decapsulating MCTP / PLDM messages, the broadcast / unicast control unit is used for switching the communication mode of SMBus, the status management unit is used for maintaining a global status table, and the security authentication unit is used for firmware image verification and device identity authentication. The hard disk device supports the MCTP over SMBus protocol and includes a firmware storage area and a receive cache.

Images