Firmware upgrade method, system, server, device, medium and product

Abstract

The present application discloses a firmware upgrade method, system, server, device, medium and product, which relates to the field of server technology. As long as there is no response to the incoming instruction, it will not enter the memory of the management controller to wait in at least one network device buffer. When responding to the incoming instruction, at least one data block of a preset size is intercepted from at least one waiting data packet, and verification processing is performed in the form of a data block. There is no need to verify the entire firmware image file, and the granularity of the verification object is reduced to save the memory resources of the management controller. It is necessary to verify and compare the target data block obtained by splitting the second image file stored in the flash memory. If the verification result is the same, the data block is discarded. If the verification result is different, the data block is written to the flash memory to avoid repeated writing in the flash memory, reduce the storage space occupied by the flash memory, and improve the memory space utilization of the management controller.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to a firmware upgrade method, system, server, device, medium, and product. Background Art

[0002] During the firmware upgrade process using the operating system, the user uploads the entire firmware image file remotely or through other interfaces. After the transfer is complete, the entire firmware image file is uploaded to the memory of the management controller to perform an integrity check on the image file to ensure that the entire firmware image file has not been tampered with. Due to the large memory requirements of the entire firmware image file, it consumes a large amount of memory space on the management controller.

[0003] Therefore, how to reduce the memory space occupied by the firmware image file in the management controller is a technical problem that those skilled in the art urgently need to solve. Summary of the Invention

[0004] The present application provides a firmware upgrade method, system, server, device, medium and product to at least solve the technical problem in the related art that manual serial port burning that does not rely on the operating system increases the difficulty and speed of firmware upgrade maintenance.

[0005] This application provides a firmware upgrade method, including:

[0006] receiving a firmware upgrade instruction, obtaining a first image file to be upgraded, splitting the first image file into at least one data packet, and transmitting the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction;

[0007] In response to the incoming instruction, intercepting at least one data block of a preset size from at least one waiting data packet, and storing the at least one data block in a memory of the management controller;

[0008] Obtaining a target data block corresponding to at least one data block, and performing verification processing on the at least one data block and the target data block to obtain a verification result; wherein the target data block is obtained by splitting a second image file, and the second image file is stored in a flash memory;

[0009] If the verification results are the same, the data block is discarded;

[0010] When the verification result is different, the data block is written to the flash memory.

[0011] The present application also provides a dual operating system, the dual operating system comprising a first operating system and a second operating system; wherein the memory resources accessible by the first operating system are greater than the memory resources accessible by the second operating system;

[0012] In the case that the first operating system fails to start the management controller, the second operating system is started to execute the steps of the above-mentioned firmware upgrade method to complete the firmware upgrade of the management controller.

[0013] The present application also provides a server including a dual operating system.

[0014] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned firmware upgrade methods when executing the computer program.

[0015] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned firmware upgrade methods are implemented.

[0016] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned firmware upgrade methods when executed by a processor.

[0017] The present application addresses the problem of uploading the entire firmware image file to the management controller's memory during a conventional firmware upgrade and verifying the entire firmware image file during the verification process, which results in a significant amount of memory being occupied by the management controller. This application takes into account the resource-constrained nature of RTOS systems, where access to less memory is limited. Typically, the memory occupied by storing the entire firmware image file is greater than the memory accessible to the RTOS system. Therefore, before uploading the firmware image file to the management controller's memory, a firmware upgrade instruction is received, the first image file to be upgraded is obtained, the first image file is split into at least one data packet, and the data is transmitted to at least one network device buffer on the target link to await incoming instructions. That is, during this transmission process, as long as there is no response to the incoming instruction, the data will not be entered into the management controller's memory, and will remain waiting in the at least one network device buffer. When responding to the incoming instruction, at least one data block of a preset size is intercepted from the at least one waiting data packet, achieving the fluidity of the first image file being readily available in the form of data blocks, rather than receiving the entire image file all at once. This also enables interception and control of the first image file in response to the incoming instruction at the flow control level. At least one data block is intercepted and stored in the memory of the management controller, and the file storage granularity is reduced to the data block granularity. Compared with the conventional storage of the entire firmware image file in the memory of the management controller, at least one data block is intercepted according to the preset size, which reduces the memory space occupied by the management controller under the RTOS system. Secondly, the target data block corresponding to the at least one data block is obtained, and the at least one data block and the target data block are verified to obtain a verification result. Compared with the conventional situation where a large amount of management controller memory is occupied when the entire firmware image file is verified, the present application performs verification in the form of data blocks, and there is no need to verify the entire firmware image file, reducing the granularity of the verification object to save the memory resources of the management controller. Finally, compared with the conventional integrity verification of the entire firmware image file itself, the present application needs to verify and compare the target data block obtained by segmenting the second image file stored in the flash memory. If the verification result is the same, the data block is discarded. If the verification result is different, the data block is written to the flash memory to avoid repeated writing in the flash memory, reducing the memory space occupied by the management controller, and also reducing the storage space occupied by the flash memory, thereby improving the memory space utilization of the management controller. Avoid writing all firmware files to the flash memory, reduce the amount of written data, improve the writing speed to a certain extent, and reduce the write loss of the flash memory.

[0018] Therefore, the technical problem that the firmware image file occupies a large amount of memory space in the management controller can be solved, and the management controller can perform splitting processing when receiving the image file to be upgraded, intercept at least one data block of a preset size from at least one waiting data packet, and store it in the form of data blocks, thereby reducing the storage granularity. In the verification process, the verification process is performed in the form of data blocks, and data blocks where at least one data block is identical to the target data block are discarded. What is actually written to the flash memory is a data block where the data block is different from the target data block. This saves the memory resources of the management controller, reduces the memory space occupied by the management controller, and also avoids the technical effect of repeated writing to the flash memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 A flowchart of a firmware upgrade method provided in an embodiment of the present application;

[0021] Figure 2 A schematic diagram of the structure of a double-ring buffer area provided in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of a local check of a data block based on a first data block size provided in an embodiment of the present application;

[0023] Figure 4 A schematic diagram of a head-to-tail recursive search verification provided in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of a firmware upgrade method based on an RTOS operating system provided in an embodiment of the present application;

[0025] Figure 6 A flowchart of a head-to-tail recursive search method provided in an embodiment of the present application;

[0026] Figure 7 A schematic diagram of the structure of a firmware upgrade device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0028] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0029] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0030] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the firmware upgrade method depends, the specific application environment architecture or specific hardware architecture is described herein.

[0031] Management controllers, such as the Baseboard Management Controller (BMC), are crucial components in servers, responsible for a variety of critical tasks, including hardware status monitoring, system power management, various management services, remote user control, remote fault diagnosis, and maintenance. As a control unit operating independently of the main system, the BMC typically runs an embedded operating system to provide flexible remote management capabilities, such as remote power control, hardware health monitoring, logging, and firmware updates, all through the Intelligent Platform Management Interface (IPMI) protocol.

[0032] During server startup, the BMC boot image is typically stored in the Serial Peripheral Interface (SPI) NOR Flash on the BMC board to ensure system reliability and stability. When the server is powered on, the BMC initializes the SPI controller through the BootROM and uses it to read the boot program from the SPI Flash. Typically, the boot program is U-Boot, which initializes the hardware and loads necessary drivers. U-Boot then initiates the loading of the Linux kernel, which initializes various BMC services, such as network management, system logging, temperature monitoring, and hardware diagnostics, ensuring effective communication and interaction between the BMC and the server host system and remote management platforms.

[0033] In servers with one or more operating systems, various failure scenarios can cause BMC image corruption. Specifically, because BMC firmware is stored in SPI flash memory, which has a lifespan and is subject to accidental wear and tear, the underlying failure mechanisms are similar to those of solid-state drives (SSDs). For example, bad blocks caused by prolonged high-load operation or manufacturing defects can lead to the loss of critical image data. A sudden power outage during a firmware update or image write (such as a power failure in the data center or poor contact caused by vibration) can cause incomplete image writes or verification failures. Software issues can also cause accidental erases or overwrites, leading to image corruption. Environmental issues can also cause image corruption, such as high room temperatures that can cause flash memory malfunction (e.g., increased charge leakage in NAND flash memory at high temperatures), resulting in image data bit flips and verification failures. These situations often require on-site manual operations, such as restoring or upgrading the image via the serial port. This increases maintenance complexity and extends recovery time, impacting system availability and stability.

[0034] In a server's dual-system architecture (System A and System B), System A is responsible for complex applications and services, while System B handles tasks requiring high real-time performance. This ensures real-time system responsiveness and creates a redundant mechanism to prevent system downtime. During the boot process of a management controller (such as a BMC), an image boot is typically performed on System A. A server failure (such as the endurance or damage of the flash memory storing the firmware) can damage the image file of the management controller, preventing it from booting properly. Even if System B takes over and restarts, the damaged image file can paralyze the management controller. The firmware upgrade method provided in this application can address the aforementioned technical issues.

[0035] Figure 1 A flowchart of a firmware upgrade method provided in an embodiment of the present application is shown in FIG. Figure 1As shown, the method includes:

[0036] S11: receiving a firmware upgrade instruction, obtaining a first image file to be upgraded, splitting the first image file into at least one data packet, and transmitting the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction;

[0037] S12: In response to the incoming instruction, intercept at least one data block of a preset size from at least one waiting data packet, and store the at least one data block in a memory of the management controller;

[0038] S13: Obtain a target data block corresponding to the at least one data block, and perform verification processing on the at least one data block and the target data block to obtain a verification result; wherein the target data block is obtained by splitting the second image file, and the second image file is stored in the flash memory;

[0039] S14: Determine whether the verification results are the same. If they are the same, proceed to step S15; if they are different, proceed to step S16;

[0040] S15: discard the data block;

[0041] S16: Writing the data block to the flash memory.

[0042] Specifically, the first image file can be obtained by being directly sent by the user, being sent remotely by the user, or being obtained directly by the user through an IPMI command, etc., which is not limited here. Regarding the method of obtaining the first image file, it can be directly from a file uploaded by the user, or by calling a file pre-stored in a buffer area after the user uploads the file, etc., which is not limited here.

[0043] Taking remote command issuance as an example, multiple interfaces and commands can be used to remotely perform firmware upgrade operations:

[0044] 1) IPMI command: the user initiates a remote upgrade command through IPMI, and the operating system receives and responds;

[0045] 2) After logging in using Secure Shell (SSH), the operating system executes the relevant commands. The operating system receives the instructions and starts the upgrade process.

[0046] 3) Upload the image file via Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS). Users access the web interface provided by the BMC real-time operating system (RTOS) through a browser or management tool, select and submit the image file, and the operating system receives the data through the built-in HTTP / HTTPS server and initiates the upgrade.

[0047] 4) Transfer the image file using the Trivial File Transfer Protocol (TFTP). The user uses the TFTP client to upload the image file to the BMC. The operating system receives the file and starts the upgrade operation.

[0048] There is no limitation on how the user communicates with the operating system, nor is there any limitation on what interface the operating system implements to connect to the remote upgrade.

[0049] Regardless of the acquisition method described above, the firmware upgrade instruction is received, and the first image file is stored in the user device's memory. User device memory is memory resources allocated to user devices (computers, mobile phones, etc.) for storing user data. In response to the firmware upgrade instruction, the first image file to be upgraded is retrieved from the user device's memory. For network transmission, the first image file is split into at least one data packet for subsequent transmission. This at least one data packet is transmitted to at least one network device buffer on the target link. This is because the transmission process requires that the transmission object and the source object reside on the same target link. Within a target link, multiple network devices (such as switches and routers) may be passed through. These devices typically have their own buffers for temporarily storing data packets until they are forwarded to the next node. During forwarding to the next node, incoming instructions are required to transfer the at least one data packet to the memory of the management controller.

[0050] The management controller's memory contains data that requires a firmware upgrade. This data is intercepted from at least one waiting data packet, similar to valve control. The amount of data required for the upgrade is determined by the amount of data intercepted from the network device buffer. This is in contrast to the conventional technical solution of transferring the entire image file to the management controller's memory before performing the firmware upgrade. This application takes into account that the operating system for the firmware upgrade is an RTOS system. If the standard firmware upgrade process of the Linux system is adopted, the image file is stored in the memory after the upload is completed. The verification and writing process also requires a large amount of memory resources. However, the RTOS can only access 256KB of memory resources, which is far less than the 64MB required to store the complete image, not to mention the memory occupied by other operations such as verification. 2) After the transfer is completed, verifying the complete 64MB image takes a long time, increasing user waiting time and actually reducing the user experience. 3) The write speed of SPI Flash is usually slower than the read speed. The overall overwriting of the image can easily become a bottleneck in the entire firmware upgrade process, and the user may have to wait for tens of minutes.

[0051] Conventional BMC firmware upgrades on Linux systems involve users uploading a local BMC firmware image file through remote management tools or other interfaces. This image file is typically 64MB in size, but the specific size may vary depending on feature expansion or customization requirements. The upload process is handled by a network protocol (such as HTTP, File Transfer Protocol (FTP), or a proprietary protocol), and the data is stored in the BMC's memory after completion.

[0052] This application adopts the method of intercepting data blocks at any time. The data block granularity is smaller than the image file granularity. When responding to the incoming instruction, this application will intercept at least one data block of a preset size and store it in the memory of the management controller to facilitate subsequent firmware upgrade operations.

[0053] It should be noted that this application corresponds to intercepting at least one data block of a preset size. The interception here corresponds to intercepting one block at a time, that is, intercepting block by block. For example, this application requires the input of one 4K data block and one 8K data block, and only one data block can be intercepted at the same time during this process. The data block of the preset size can be a conventional fixed-value data block or an unconventional, non-fixed-value data block setting that gradually increases or decreases.

[0054] Regarding the operating system, it can be a single operating system of the server, such as a Linux system, or it can be a dual operating system of the server, such as a Linux system and an RTOS system, etc. There is no limitation here and it can be set according to actual conditions.

[0055] Regarding obtaining the target data block corresponding to at least one data block in step S13, it should be noted that, in this embodiment, if there is only one data block, the data block and the corresponding target data block are verified. If there are multiple data blocks, the multiple data blocks and their respective corresponding target data blocks need to be verified. It should be noted that the image format of the data block and the target data block are the same, that is, the corresponding data block sizes are the same. The target data block is obtained by splitting the second image file, and the second image file is stored in the flash memory. It should be noted that, in this embodiment, the target data block corresponding to the at least one data block mentioned above has the same specifications as the size of the corresponding split data block and the size of the at least one data block.

[0056] The flash memory stores the firmware image, which is usually a non-volatile firmware image memory, so that the data does not change when the firmware is closed or opened each time it is upgraded.

[0057] The verification process in step S13 is different from the conventional BMC firmware upgrade in the Linux system. The conventional firmware upgrade in the Linux system includes the following steps:

[0058] The Linux system on the BMC reads the complete image file from memory and prepares it for subsequent processing. During this stage, the image is temporarily stored in memory, which usually requires a large amount of memory and places certain demands on the BMC's hardware resources.

[0059] Before overwriting the firmware storage device (usually SPI Flash), the Linux system will perform an integrity check on the uploaded image. Common verification methods include checksums and hash checks (such as MD5 and SHA256). The purpose of the verification is to ensure that the uploaded image data has not been tampered with or damaged during transmission. If the verification fails, the system will refuse to continue the upgrade and prompt the user to re-upload the image.

[0060] After verification is complete, the Linux system writes the complete image file to the firmware storage device through the SPI driver. This process requires overwriting the existing firmware content. Due to the relatively slow Flash write speed, the entire operation may take several minutes, depending on the performance of the storage device and the image size.

[0061] When the image is written, the system will update the operation status to indicate that the firmware update was successful. The user can then choose to reboot the system to load the new firmware version.

[0062] The purpose of the verification process in this embodiment is to find out the data of the data blocks that are different from the target data block in at least one data block, for subsequent writing to the mirror flash memory. This embodiment takes into account that the speed of sending data via network transmission is often greater than the writing speed of writing to the mirror flash memory. Therefore, if all at least one data packet is written to the mirror flash memory, it cannot keep up with the speed of sending data via network transmission, and also takes up more memory space. Frequent writing to the mirror flash memory will increase write loss. Here, in this embodiment, the data of the data blocks that are different from the target data block in at least one data block are found and written to the flash memory. Compared with the amount of data in the first mirror file, the amount of data written to the flash memory is reduced, which speeds up the writing speed and reduces the write loss in a certain sense. At the same time, it also speeds up the firmware upgrade speed.

[0063] The verification process here needs to consider the data in at least one data block and the target data block, and two situations: one is data alignment, and the other is data misalignment. In either case, the at least one data block needs to be compared and verified with the corresponding target data block. The verification process of this embodiment is different from the conventional integrity verification process for a mirror file. The integrity verification process takes a longer time and can be a data block-by-data block comparison. Considering the large amount of data and the need for accurate comparison, if the check values ​​of the entire first and second mirror files are determined and compared, the total data corresponding to each mirror file is large, which makes the entire data comparison take up more computing resources. In addition, there may be a situation where some data is different, but the subsequent data is normal, resulting in a normal check value for the entire data. In this way, the data of at least one data block intercepted from the first image file that is different from the corresponding target data block segmented from the second image file is omitted, resulting in an inaccurate comparison. Therefore, the embodiment of the present application uses the data block method to compare the data within each data block. The comparison here can be a data comparison or a check value comparison within each data block, which is not limited here.

[0064] This embodiment performs a verification process based on a cyclic comparison of data blocks between the flash memory and the image file sent by the user. This cyclic comparison can be performed using a circular buffer area. After verifying a data block, the corresponding data block is left blank to accommodate the next data block read from the flash memory. If the verification results are identical, the data block is discarded. If the verification results are different, the data block is written to the flash memory.

[0065] The present application addresses the problem of uploading the entire firmware image file to the management controller's memory during a conventional firmware upgrade and verifying the entire firmware image file during the verification process, which results in a significant amount of memory being occupied by the management controller. This application takes into account the resource-constrained nature of RTOS systems, where access to less memory is limited. Typically, the memory occupied by storing the entire firmware image file is greater than the memory accessible to the RTOS system. Therefore, before uploading the firmware image file to the management controller's memory, a firmware upgrade instruction is received, the first image file to be upgraded is obtained, the first image file is split into at least one data packet, and the data is transmitted to at least one network device buffer on the target link to await incoming instructions. That is, during this transmission process, as long as there is no response to the incoming instruction, the data will not be entered into the management controller's memory, and will remain waiting in the at least one network device buffer. When responding to the incoming instruction, at least one data block of a preset size is intercepted from the at least one waiting data packet, achieving the fluidity of the first image file being readily available in the form of data blocks, rather than receiving the entire image file all at once. This also enables interception and control of the first image file in response to the incoming instruction at the flow control level. At least one data block is intercepted and stored in the memory of the management controller, and the file storage granularity is reduced to the data block granularity. Compared with the conventional storage of the entire firmware image file in the memory of the management controller, at least one data block is intercepted according to the preset size, which reduces the memory space occupied by the management controller under the RTOS system. Secondly, the target data block corresponding to the at least one data block is obtained, and the at least one data block and the target data block are verified to obtain a verification result. Compared with the conventional situation where a large amount of management controller memory is occupied when the entire firmware image file is verified, the present application performs verification in the form of data blocks, and there is no need to verify the entire firmware image file, reducing the granularity of the verification object to save the memory resources of the management controller. Finally, compared with the conventional integrity verification of the entire firmware image file itself, the present application needs to verify and compare the target data block obtained by segmenting the second image file stored in the flash memory. If the verification result is the same, the data block is discarded. If the verification result is different, the data block is written to the flash memory to avoid repeated writing in the flash memory, reducing the memory space occupied by the management controller, and also reducing the storage space occupied by the flash memory, thereby improving the memory space utilization of the management controller. Avoid writing all firmware files to the flash memory, reduce the amount of written data, improve the writing speed to a certain extent, and reduce the write loss of the flash memory.

[0066] Therefore, the technical problem that the firmware image file occupies a large amount of memory space in the management controller can be solved, and the management controller can perform splitting processing when receiving the image file to be upgraded, intercept at least one data block of a preset size from at least one waiting data packet, and store it in the form of data blocks, thereby reducing the storage granularity. In the verification process, the verification process is performed in the form of data blocks, and data blocks where at least one data block is identical to the target data block are discarded. What is actually written to the flash memory is a data block where the data block is different from the target data block. This saves the memory resources of the management controller, reduces the memory space occupied by the management controller, and also avoids the technical effect of repeated writing to the flash memory.

[0067] In some embodiments, performing verification processing on at least one data block and a target data block to obtain a verification result includes:

[0068] forming the at least one data block stored in the memory of the management controller into a data packet to be detected;

[0069] Forming a target data packet with a target data block corresponding to the at least one acquired data block; acquiring a data packet to be detected and a data block to be checked at the same data block position corresponding to each of the data packet to be detected;

[0070] The data blocks to be checked of the data packet to be detected and the target data packet are checked one by one in a preset order to obtain a check result.

[0071] Specifically, when storing in the memory of the management controller, it will be processed in a circular buffer manner. Here, during the first comparison process, the data block positions of the storage structure corresponding to the circular buffer manner need to be filled with data blocks, thus forming a circular buffer area corresponding to a data packet. In this application, two circular buffer areas are required, one circular buffer area stores a data packet to be detected formed by at least one data block intercepted from at least one data packet transmitted from the network device buffer, and the other circular buffer area stores a target data packet formed by a target data block divided by the second mirror file in the flash memory.

[0072] It should be noted that the data packet to be detected and the target data packet in this embodiment are distinguished from at least one data packet stored in the buffer of the network device, and have different sources.

[0073] In the two ring buffers, the data blocks corresponding to the same data block positions are compared. The data blocks to be verified for the target data packet and the target data packet are compared at the same data block positions. After comparing one data block position, the next data block position is compared. Ultimately, the two data packets are comparing the same data block position. The predetermined order can be clockwise or counterclockwise, starting from the first data block position or the last data block position. The verification process is always performed on the data blocks to be verified at the same data block position, one by one, in a cyclical order.

[0074] This embodiment provides a method of performing verification processing on the data blocks to be checked at the same data block position of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, so that the verification is orderly and cyclical, and repeated writing to the flash memory is avoided.

[0075] In some embodiments, before verifying the at least one data block and the target data block to obtain a verification result, the method further includes:

[0076] A first buffer area and a second buffer area are pre-established; wherein the first buffer area and the second buffer area adopt a ring structure;

[0077] storing the to-be-checked data block of the to-be-detected data packet in the first buffer area;

[0078] The data blocks to be checked of the target data packet are stored in the second buffer area.

[0079] Specifically, considering that in other operating systems, such as RTOS systems, the image file is stored in the memory after uploading, the verification and writing process also requires a large amount of memory resources. However, the memory resource size accessible to RTOS is only 256KB, which is far less than the 64MB required to store the complete image, not to mention the memory usage caused by other operations such as verification; after the transmission is completed, verifying the complete 64MB image takes a long time, increasing user waiting and actually reducing the user experience; the write speed of SPI Flash is usually slower than the read speed, and the overall overwriting of the image can easily become a bottleneck in the entire firmware upgrade process, and the user may need to wait for tens of minutes.

[0080] Therefore, before actual writing, a first buffer area and a second buffer area are pre-established. These two buffer areas adopt a ring structure. This ring structure is based on the limited memory resources of the RTOS when processing complete image files. The ring structure is composed of multiple data block positions, each corresponding to a data block. By caching data blocks, the entire image file is avoided from being cached. At the same time, the ring corresponds to the flow. After the data blocks at the corresponding data block positions in the first and second buffer areas are compared, the data block position is vacated to make room for the data block of the next image file, forming a circular use method.

[0081] In this embodiment, taking into account the different ways of obtaining the two image files, the second image file is based on reading from the flash memory, and the first image file is based on transmission from an external device. Therefore, it is necessary to divide it into two different buffer areas. The first buffer area is used for writing and storing at least one data block intercepted from the first image file, and the second buffer area is used for reading and storing the target data block of the second image file segmentation processing.

[0082] The present embodiment provides a method of pre-establishing a first buffer area and a second buffer area, which respectively store at least one data block intercepted from the first image file and a target data block for segmentation processing of the second image file, thereby saving memory resources and computing resources of the operating system and facilitating the management of the verification processing process of the two data blocks.

[0083] In some embodiments, when the data block to be checked of the data packet to be detected is aligned with the data block to be checked of the target data packet, the first buffer area and the second buffer area form a double-ring buffer area.

[0084] Specifically, the comparison performed under a conventional image format ensures that the image file does not experience any offset misalignment. This means that at least one data block is aligned with the target data block, i.e., the to-be-checked data block of the packet to be tested is aligned with the to-be-checked data block of the target packet, thereby avoiding consistency issues caused by data offset. Here, the first buffer area and the second buffer area are grouped together to form a dual-ring buffer area.

[0085] This embodiment provides a dual-ring buffer area, in which the data blocks to be checked of the data packet to be detected are aligned with the data blocks to be checked of the target data packet. This can effectively avoid the situation where a small-scale modification of the firmware image causes the entire larger-scale flash memory to be completely overwritten during an upgrade.

[0086] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result includes:

[0087] Get the first data block position of the double ring buffer area;

[0088] The data blocks to be checked of the data packet to be detected and the target data packet correspondingly stored in the first buffer area and the second buffer area are checked one by one starting from the data at the first data block position to obtain a check result.

[0089] Specifically, the preset sequence in this embodiment starts with the first data block position and verifies each of the data blocks in the target packet and the data block position that are identical, one by one, to obtain a verification result. This operation essentially repeats from the first data block position to the last data block position. In this embodiment, the verification is not specific to the first data block, but rather takes into account the fluidity of data block cyclic verification within the double-shape buffer area, which follows the order of data block positions.

[0090] This embodiment provides a method of verifying the data blocks at the same data block positions of the data packet to be detected and the target data packet one by one starting from the first data block position, so that the verified data blocks are more orderly and fluid.

[0091] In other embodiments, when the data boundary between the data packet to be detected and the target data packet is shifted, the first buffer area and the second buffer area constitute a plurality of dual-ring buffer areas.

[0092] Because the first image file you upgrade is an iterative version of the original image on the image flash memory, the changes to the first image file may cause the data block boundaries to shift, causing the original block verification to fail. For example, if a 100M piece of data is modified or added to a few bytes, a verification based on the 100M size will fail. However, if a verification based on the 1M size is performed, the content before the modification will verify successfully, while the content after the modification will fail verification due to the offset caused by the modification.

[0093] Based on statistics and observations of the image iteration process, BMC images have a detailed hierarchical structure and clear modularity. Changes are generally localized and concentrated, while the majority of the image content remains unchanged. Furthermore, since compiled images may contain some compilation-related information, such as the compilation time, these header contents often change dynamically. Therefore, this data needs to be removed during verification to avoid affecting the consistency comparison results.

[0094] Based on the above situation, a dynamic window or rolling hash algorithm is usually used to find consistency, but the computational complexity and complexity behind it are high, and the resource issues corresponding to some operating systems are also impractical. Therefore, in order to quickly locate the front and back continuous and consistent data blocks of the first image file, the parts that do not need to be transmitted are skipped, and the amount of data transmitted is reduced to improve the upgrade speed. This embodiment constructs multiple circular buffer areas for the first buffer area and the second buffer area, that is, the first buffer area and the second buffer area of ​​a double circular buffer area compare the header data blocks of the data packet to be detected and the target data packet, and the first buffer area and the second buffer area of ​​another double circular buffer area compare the tail data blocks of the data packet to be detected and the target data packet. The first buffer area and the second buffer area of ​​other double circular buffer areas can also be added to compare the data blocks in the middle position of the data packet to be detected and the target data packet, etc., which are not limited here, but at least ensure that the two double circular buffer areas perform head-to-tail recursive searches, speeding up the comparison while improving the verification accuracy.

[0095] The setting of multiple dual-ring buffer areas provided in this embodiment facilitates the subsequent rapid positioning of different areas of the data block, improves the efficiency of the verification process, reduces the amount of data transmitted and also increases the speed of firmware upgrade.

[0096] In some embodiments, the number of the dual ring buffer areas is two, and the check blocks of the to-be-checked data packet and the target data packet are checked one by one in a preset order, including:

[0097] Get the first and last data block positions of the double ring buffer area;

[0098] The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the first double-ring buffer area are checked one by one starting from the data at the first data block position;

[0099] The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the second double-ring buffer area are checked one by one starting from the data at the last data block position.

[0100] Specifically, considering that during the firmware upgrade process of the image file, the changes to the image file are usually local and concentrated, and considering the resource constraints of some operating systems, this embodiment combines the structure of the above-mentioned dual-ring buffer area and adopts a head-to-tail recursive method. Taking into account the characteristics of rapid positioning, two dual-ring buffer areas are adopted. One dual-ring buffer area performs verification processing on the header data blocks of the two image files, and the other dual-ring buffer area performs verification processing on the tail data blocks of the two image files. The head and tail are clamped together and the verification processing is performed synchronously. The data blocks to be checked for the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the first dual-ring buffer area are verified one by one starting from the data at the first data block position; the data blocks to be checked for the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the second dual-ring buffer area are verified one by one starting from the data at the last data block position. The two sets of dual-ring buffer areas are clamped from both sides.

[0101] It should be noted that, in this embodiment, the limitation of the operating system is taken into consideration, so the setting of the buffer area occupies as little memory resources as possible. Therefore, the number of groups of the dual-ring buffer area settings can be set according to actual usage and is not limited here.

[0102] The head-to-tail synchronization verification process provided in this embodiment can quickly locate the target image data, save memory resources of the operating system, and improve the efficiency of the verification process, thereby increasing the firmware upgrade speed.

[0103] In some embodiments, intercepting at least one data block of a preset size from at least one waiting data packet includes:

[0104] Pre-acquire the preset data block sizes of the first buffer area and the second buffer area;

[0105] Using the preset data block size as the preset size of the intercepted data block for interception;

[0106] Obtaining a target data block corresponding to at least one data block includes:

[0107] The second image file is segmented according to a preset data block size to obtain corresponding target data blocks.

[0108] Specifically, the preset data block size is a specification for setting the data block position size based on the ring buffer structure of the first and second buffer areas. This preset data block size can be used as a preset size for intercepting data blocks to intercept at least one data block. Simultaneously, the second image file is segmented according to the preset data block size to obtain corresponding target data blocks.

[0109] It should be noted that the specific value of the preset data block size here can be the same or different, and is not limited here. The data blocks after interception and segmentation are stored in the data block positions of the corresponding ring structure. It is worth noting that in the case where the data of the two mirror files are offset, the same operation is also performed for subsequent storage, which is not repeated here. Finally, the actual verification processing is to compare the data block positions under the ring structure. The comparison here is based on the verification processing of data blocks with the same data block position. The verification here can be the data of the data block or the verification value of the data block, etc., which is not limited here.

[0110] This embodiment provides for intercepting at least one data block according to a preset data block size and segmenting the second image file to store values ​​in data block positions corresponding to the ring buffer area, so as to facilitate verification processing of data blocks at the same data block position, facilitate consistency operations of data verification, and improve verification processing efficiency.

[0111] In some embodiments, the preset data block size is a fixed data block size; intercepting at least one data block of the fixed data block size from the at least one waiting data packet;

[0112] Correspondingly, the second image file is divided according to the fixed data block size to obtain corresponding target data blocks.

[0113] Specifically, the preset data block size is a fixed data block size, and the specifications of the corresponding intercepted and segmented data blocks are the same. Subsequently, data blocks of this specification are compared to ensure consistency comparison of data verification processing.

[0114] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result includes:

[0115] Get the current data block position;

[0116] Comparing the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area;

[0117] If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, the data blocks to be checked at the data block position next to the current data block position corresponding to the first buffer area and the second buffer area are used as the new current data block position, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area;

[0118] If they are different, it is determined that the data blocks to be checked at the current data block position are different, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area until all the data blocks to be checked in the first buffer area and the second buffer area are compared.

[0119] Figure 2 A schematic diagram of the structure of a double-ring buffer area provided in an embodiment of the present application is shown as follows: Figure 2 As shown, the current data block position is obtained, and the data blocks to be verified at the current data block position corresponding to the first buffer area and the second buffer area are compared. If they are the same, the next one is compared. If they are the same at this time, they are directly deleted, indicating that the data of the data block to be verified at the current data block position has been stored in the flash memory. If they are different, the data of the data block to be verified at the current data block position in the first buffer area is retained, indicating that the data of the data block to be verified at the current data block position has not been stored in the flash memory. Continue to perform subsequent data comparison and reading, Figure 2 The ring in the middle can rotate in the same direction, and the data blocks that have been verified can be written with new data until all the first image files to be upgraded provided by the user are compared.

[0120] This embodiment provides a method for comparing multiple data blocks of the same specification in different buffer areas, effectively avoiding the complete overwriting of the entire firmware during the firmware upgrade due to a small-scale modification of the data packet to be detected, and subsequently writing the different data blocks to the flash memory, thereby improving the subsequent firmware upgrade speed and reducing the write loss to the flash memory.

[0121] In some other embodiments, the preset data block size is a non-fixed data block size; the multiple preset data block sizes are increased in stages, and there is an integer multiple relationship between the multiple preset data block sizes; at least one data block is intercepted from the at least one waiting data packet in the order of the multiple non-fixed data block sizes that increase in stages;

[0122] Correspondingly, the second image file is divided in the order of a plurality of non-fixed data block sizes that increase in a step-by-step manner to obtain corresponding target data blocks.

[0123] Specifically, considering that there may be a situation in which the data comparison is different within a certain range during the data comparison process, while the comparisons for the rest of the large range are the same, the specifications of the data blocks corresponding to the annular structure of the buffer area may be different, so as to quickly locate and search. Therefore, in the embodiment of the present application, the length of the preset data block size is set to a non-fixed value, and a step-by-step increasing method is adopted, such as starting from a 4K data block, and using data blocks of different sizes such as 4K, 8K, 16K, 32K, and 64K at a time. At the same time, considering that during the comparison process of data blocks of different specifications, if there is a data block position of 64K specification that corresponds to a different data comparison, in order to reduce the amount of data written subsequently, precise positioning is performed here, and the 64K specification data is re-locally verified, and split into 32K, 16K to the subsequent 4K, and gradually reduced to find the difference in the data corresponding to the smallest specification. Therefore, in the embodiment of the present application, there is an integer multiple relationship between the multiple preset data block sizes, so as to simplify the calculation of subsequent splitting.

[0124] This embodiment provides a method of intercepting at least one data block and dividing the second image file into multiple data blocks in the order of multiple preset data block sizes that increase in a step-by-step manner, thereby saving verification time and improving the firmware upgrade speed.

[0125] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result includes:

[0126] Get the current data block position;

[0127] Comparing the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area;

[0128] If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, the data blocks to be checked at the data block position next to the current data block position corresponding to the first buffer area and the second buffer area are used as the new current data block position, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area;

[0129] If they are different, it is determined that the data block to be checked at the current data block position is different, and the data block to be checked at the current data block position is used as the initial check data block and a first data block size is obtained; wherein the length of the first data block size is a non-fixed value, the sizes of the multiple first data blocks decrease step by step, and there is an integer multiple relationship between the sizes of the multiple first data blocks;

[0130] Splitting the initial check data block in the order of a plurality of non-fixed data block sizes that decrease in order to determine a plurality of current first data blocks;

[0131] Obtaining a current first data block position according to a data block position sequence of the multiple current first data blocks; wherein the current first data block position is compared starting with a first position of the data block positions of the multiple first data blocks;

[0132] Comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area;

[0133] If they are the same, determining that the initial check data blocks at the current first data block position are the same, setting the first data block position next to the current first data block position corresponding to the first buffer area and the second buffer area as the new current first data block position, and returning to the step of comparing the data at the current first data block position corresponding to the first buffer area and the second buffer area;

[0134] If they are different, it is determined that the initial check data blocks of the current first data block position are the same, and the next first data block position of the current first data block position corresponding to the first buffer area and the second buffer area is used as the new current first data block position, and the process returns to the step of comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area until all the data of the first buffer area and the second buffer area are compared.

[0135] The process of determining whether the data blocks to be checked at the current data block position are different or the same in this embodiment is the same as the cyclic comparison process in the above embodiment, which will not be described in detail here. In this embodiment, after the data blocks to be checked at the current data block position are different, the first data block size is directly obtained. The first data block size and the preset data block size here are both non-fixed values ​​and decrease step by step. The step-by-step decrease here has the same span as the step-by-step increase of the preset data block size in the above embodiment, which will not be described in detail here.

[0136] The initial check data block is split in the order of multiple non-fixed data blocks of decreasing size to determine multiple current first data blocks. It should be noted that local verification of the data block to be checked is required at any time until all comparisons are completed. During the local verification process, due to the splitting into multiple first data blocks, the data at the current first data block position may be the same. Since the data block to be checked reflects different situations, it is necessary to continue to find the next current first data block position and continue the comparison until all data are compared.

[0137] It is worth noting that in this embodiment, according to the order of decreasing first data block size, here it can be based on a first data block size, such as dividing the original 64K to obtain 32K data, which is now divided into two data blocks, and these two data blocks are used as the current first data blocks for the next data block comparison, and all data blocks of the current iteration are compared. At the same time, the 32K data is continued to be compared, and this time it is used as the current first data block of another iteration, and the comparison of this iteration is completed until the data block with the smallest unit size is found for positioning. For example, Figure 3 A schematic diagram of local verification of a data block based on a first data block size provided in an embodiment of the present application is shown as follows: Figure 3 As shown in the figure, when comparing 32K data blocks, if the hash values ​​are inconsistent, the system will re-run a local check on the last 16K of the 32K data block, starting from 4K, until a consistent check value is found. The final boundary is an integer multiple of 4K, such as 36K.

[0138] The local verification process based on data block segmentation of the first data block size provided in this embodiment can quickly locate and find the final verification result while saving verification time, thereby improving positioning efficiency.

[0139] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result includes:

[0140] Marking the data block positions with different verification results in the first dual-ring buffer area to obtain a first marking position;

[0141] Marking the data block positions with different verification results in the second dual-ring buffer area to obtain a second marking position;

[0142] In the dual-ring buffer area, data blocks corresponding to the first mark position to the second mark position are written into the flash memory.

[0143] Figure 4 A schematic diagram of a head-to-tail recursive search verification provided in an embodiment of the present application is shown as follows: Figure 4 As shown, the system will attack from both the head and tail of the packet to be detected. Figure 4 The data blocks with the longest continuous consistency at the beginning and the end determined in the above method do not need to be transmitted, and are directly reduced to the data in the local area for subsequent writing to the flash memory.

[0144] Specifically, this embodiment takes into account that multiple different data blocks may appear during the front-end and rear-end clamping process. Here, we do not need to care about the corresponding different data blocks in the middle. We only care about the first position of the data block positions with different verification results in the first dual-ring buffer area, which is marked as the first marked position. The first position of the data block positions with different verification results in the second dual-ring buffer area, which is marked as the second marked position, is written to the flash memory.

[0145] In the head-to-tail recursive search process provided by this embodiment, a local concentrated area is determined corresponding to different data blocks, thereby improving the verification processing efficiency.

[0146] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result includes:

[0147] Acquire first target data of a data block to be checked of a data packet to be detected and second target data of a data block to be checked of a target data packet;

[0148] determining a check value according to the first target data;

[0149] determining a hash value based on the second target data;

[0150] Determine whether the check value and hash value are the same;

[0151] If they are different, it is determined that the verification results are different;

[0152] If they are the same, it is determined that the verification results are the same.

[0153] Specifically, the verification process of this embodiment corresponds to the comparison of the check value within the data block. By calculating the check value of the data block, it can quickly check whether there are errors in the data transmission or storage of the data block. The hash value is used to detect slight changes in the data.

[0154] The process of determining the check value and the hash value in this embodiment may be the same as or different from the conventional processing method, which is not limited here and can be set according to actual conditions.

[0155] The comparison between the check value and the hash value of the data block provided in this embodiment uses a double verification mechanism to effectively ensure the integrity and reliability of the data in the data block.

[0156] Figure 5 A schematic diagram of a firmware upgrade method based on an RTOS operating system provided in an embodiment of the present application is shown in FIG. Figure 5As shown, this embodiment takes into account the fault tolerance of the RTOS operating system, fully considers resource limitations, optimizes the efficiency and reliability of the upgrade process, and the RTOS operating system operates normally and the network protocol stack operates normally. The user establishes communication with the RTOS operating system through the network. Figure 5 Each module, RTOS network stack, and SPI driver are implemented by software design within the RTOS operating system. When a remote user uses remote commands to perform a BMC remote upgrade task on the RTOS operating system, the RTOS operating system is built and initialized in memory.

[0157] The network protocol stack on the RTOS provides streamlined network capabilities for the RTOS, supporting the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), receiving data blocks transmitted by remote users, and controlled by the streaming management module. The remote BMC firmware image upgrade process proposed in this patent uses the TCP protocol.

[0158] exist Figure 5 There are two ways to obtain the data packet to be detected corresponding to at least one data block. One is to send it to the streaming management module through the RTOS network stack for processing and then send it to the verification module for verification processing. The other is to send it to the verification module through the writing module for verification processing.

[0159] Regarding the streaming management module, data is transmitted and processed in the form of a continuous stream. Its streaming allows data to be processed step by step during the transmission process. At the same time, corresponding to applications with high real-time requirements, it can transmit data with lower latency, ensuring smoother and more natural interaction.

[0160] In some embodiments, before storing the at least one data block in the memory of the management controller, the method further includes:

[0161] Creating an index mark for at least one data block;

[0162] determining a first check value based on data of at least one data block;

[0163] The first check value and the index mark are saved and stored together with the at least one data block in a memory of the management controller.

[0164] Specifically, it receives at least one data block (e.g., 4KB in size), creates an index tag (ID) for the data block, and calculates a first checksum for the data block using a hash algorithm. The streaming management module verifies the received network data blocks to improve parallelism and avoid latency caused by centralized computation. The data block is then written to the circular buffer in the write module, and the index tag and first checksum are synchronously sent to the verification module. Based on the buffer status reported by the write module, the module controls the transmission speed at the TCP flow control level.

[0165] This embodiment provides for storing the index mark and the first check value together with the data block in the memory of the management controller. To a certain extent, considering that the memory resources of the RTOS operating system are valid, the content can be used without downloading the complete image file, thereby reducing storage requirements.

[0166] Combine Figure 5 From the perspective of the embodiment, the acquisition method of this embodiment is based on acquisition in the first buffer area, and the specific process of establishing the index mark and the first check value is the same as that of the above embodiment, which will not be repeated here.

[0167] The at least one data packet acquisition method provided in this embodiment saves memory resources of the operating system while improving the accuracy and integrity of subsequent data block verification processing and also improving the data verification processing efficiency.

[0168] like Figure 5 As shown, the write module and the read module are responsible for operating the SPI driver to efficiently write and read mirror data blocks to and from the Flash memory. To achieve parallel data transmission and processing while optimizing system resource utilization, a double ring buffer architecture was designed. Each buffer is 64KB in length. In the write module, received mirror data blocks are first stored in the write buffer, which can hold up to 16 blocks. Based on the buffer's status and capacity, each block is written to the Flash memory one by one. Write operations utilize a block-by-block write strategy to ensure stable system operation under resource-constrained conditions. The read module extracts mirror data blocks from the Flash memory into the ring read buffer and provides support for subsequent verification. Read and write operations operate independently, with the internal control module dynamically controlling the input speed based on the buffer's output speed.

[0169] The checksum module extracts the data blocks stored in Flash from the read buffer, calculates their hash values, and compares the hash values ​​with the checksum values ​​of the remote data blocks received during streaming. This mechanism allows the module to verify that each of the 16 data blocks in the buffer is consistent with the data transmitted from the remote end, thus determining whether to write the received data to Flash storage.

[0170] Furthermore, the present application also provides a dual operating system, the dual operating system including a first operating system and a second operating system; wherein the memory resources accessible by the first operating system are greater than the memory resources accessible by the second operating system;

[0171] In the case that the first operating system fails to start the management controller, the second operating system is started to execute the steps of the above-mentioned firmware upgrade method to complete the firmware upgrade of the management controller.

[0172] Specifically, dual operating systems, such as Linux (the primary operating system) and RTOS (the secondary operating system), are being introduced in BMCs to improve fan control speed, system startup efficiency, and fault handling capabilities after power-on. This architecture runs the Linux and RTOS operating systems on the BMC's two cores, respectively. The RTOS and Linux systems boot simultaneously. Due to the RTOS's high real-time performance and lightweight nature, they typically boot within seconds, controlling server fans and providing basic user management services. Specifically, after system power-on, the BMC first loads the RTOS via U-Boot. The RTOS immediately begins performing key functions such as fan control and temperature monitoring. Simultaneously, the BMC also provides basic remote management functions such as system status monitoring and fault diagnosis. As Linux boots, the RTOS gradually transfers control to the Linux system. At this point, the BMC enters full Linux control mode, providing a richer set of services, such as log management, network configuration, firmware updates, and more complex remote management operations. Simultaneously, the RTOS enters status monitoring mode, continuously monitoring Linux's health and resuming system control when necessary. Through the dual-system architecture, BMC can provide comprehensive and flexible management functions while ensuring rapid response and efficient regulation, significantly improving the overall performance, reliability and maintainability of the server.

[0173] However, due to the increasing complexity of current BMCs and the influence of various uncertainties, Linux systems are at risk of crashing, potentially causing downtime, freezing, and other problems. In this case, the RTOS promptly detects Linux crashes through real-time monitoring and takes over system control, continuing to provide network services and basic management functions such as fan control, temperature monitoring, hardware status detection, and remote user management. This allows the RTOS or remote users to remotely restart the BMC through the RTOS even when the Linux system crashes, avoiding complete loss of control due to a Linux crash. This overcomes the challenge of limited RTOS memory resources during firmware upgrades, significantly improves the speed of remote image upgrades, and resolves the current issue of the BMC failing to boot properly due to a damaged boot image, thereby improving system reliability and fault tolerance and reducing operation and maintenance costs.

[0174] The management controller's RTOS operating system enables remote upgrades, leveraging the RTOS's real-time and stability. Even if both the Linux system and the firmware image are damaged, the RTOS can still be used to remotely restore and upgrade the firmware, enhancing the management controller's fault tolerance. Remote firmware upgrades can be performed even in the event of a BMC crash or image corruption, effectively reducing system downtime and significantly improving system maintainability and user experience. Furthermore, by reducing the amount of data written, the design extends the Flash memory's lifespan and reduces equipment maintenance costs.

[0175] Furthermore, the present application also provides a server, including the above-mentioned operating system.

[0176] For descriptions of features in the embodiment corresponding to the server, please refer to the relevant descriptions of the embodiment corresponding to the firmware upgrade method, which will not be repeated here.

[0177] Figure 6 A flowchart of a head-to-tail recursive search method provided in an embodiment of the present application is shown in FIG. Figure 6 Shown, including:

[0178] S21: Both parties establish communication;

[0179] S22: The firmware image of the second operating system in the current calculation image flash memory The hash value of each data block;

[0180] S23: Send to remote end for synchronous comparison of hash values;

[0181] S24: Determine whether the hash values ​​are consistent; if so, return to step S22 to obtain the next data block; if not, proceed to step S25;

[0182] S25: From arrive Recursion within the scope;

[0183] S26: Determine whether the check values ​​are the same; if they are the same, return to step S25; if they are different, proceed to step S27;

[0184] S27: Repeat from the end;

[0185] S28: Create an index for the data block in units of 4K, and send the data blocks with different verification results to the flash memory.

[0186] The embodiment of the present application also provides a firmware upgrade device, Figure 7 A schematic diagram of the structure of a firmware upgrade device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the device includes:

[0187] The receiving module 11 is configured to receive a firmware upgrade instruction, obtain a first image file to be upgraded, split the first image file into at least one data packet, and transmit the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction;

[0188] a response module 12, configured to respond to an incoming instruction, intercept at least one data block of a preset size from at least one waiting data packet, and store the at least one data block in a memory of the management controller;

[0189] a verification processing module 13, configured to obtain a target data block corresponding to at least one data block, and perform verification processing on the at least one data block and the target data block to obtain a verification result; wherein the target data block is obtained by segmenting the second image file, and the second image file is stored in the flash memory;

[0190] A discarding module 14 is configured to discard the data block when the verification results are the same;

[0191] The writing module 15 is configured to write the data block into the flash memory if the verification result is different.

[0192] For the description of the features in the embodiment corresponding to the firmware upgrade device, please refer to the relevant description of the embodiment corresponding to the firmware upgrade method, and no further details will be given here.

[0193] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned firmware upgrade method embodiments.

[0194] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned firmware upgrade method embodiments when running.

[0195] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0196] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned firmware upgrade method embodiments are implemented.

[0197] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned firmware upgrade method embodiments are implemented.

[0198] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0199] The above is a detailed introduction to a firmware upgrade method, system, server, device, medium and product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A firmware upgrade method, characterized in that: A second operating system applied to a dual operating system, wherein the dual operating system includes a first operating system and a second operating system, and memory resources accessible to the first operating system are greater than memory resources accessible to the second operating system; and if the first operating system fails to start a management controller, starting the second operating system comprises: receiving a firmware upgrade instruction, obtaining a first image file to be upgraded, splitting the first image file into at least one data packet, and transmitting the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction; In response to an incoming instruction, intercepting at least one data block of a preset size from at least one waiting data packet at any time, and storing the at least one data block in a memory of the management controller to reduce memory space occupied by the management controller; wherein one data block is intercepted at a time; Obtaining a target data block corresponding to at least one data block, and performing a verification process on the at least one data block and the target data block to obtain a verification result; wherein the target data block is obtained by segmenting a second image file, and the second image file is stored in a flash memory; performing alignment or misalignment verification on the at least one data block and the data blocks to be verified corresponding to the target data block; in the case of misalignment, setting multiple dual-ring buffer areas for verification processing, and performing comparison in a head-to-tail recursive manner; If the verification results are the same, the data block is discarded; When the verification result is different, the data block is written to the flash memory.

2. The firmware upgrade method according to claim 1, wherein: Performing verification processing on at least one data block and a target data block to obtain a verification result includes: forming the at least one data block stored in the memory of the management controller into a data packet to be detected; forming a target data packet from a target data block corresponding to the at least one acquired data block; Obtaining the data blocks to be checked at the same data block positions corresponding to the data packet to be detected and the target data packet; The data blocks to be checked of the data packet to be detected and the target data packet are checked one by one in a preset order to obtain a check result.

3. The firmware upgrade method according to claim 2, wherein: Before verifying the at least one data block and the target data block to obtain a verification result, the method further includes: A first buffer area and a second buffer area are pre-established; wherein the first buffer area and the second buffer area adopt an annular structure; storing the to-be-checked data block of the to-be-detected data packet in the first buffer area; The data block to be checked of the target data packet is stored in the second buffer area.

4. The firmware upgrade method according to claim 3, wherein: When the data block to be checked of the data packet to be detected is aligned with the data block to be checked of the target data packet, the first buffer area and the second buffer area form a double-ring buffer area.

5. The firmware upgrade method according to claim 4, wherein: Verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain verification results, including: Get the first data block position of the double ring buffer area; The data blocks to be checked of the data packet to be detected and the target data packet correspondingly stored in the first buffer area and the second buffer area are checked one by one starting from the data at the first data block position to obtain the check result.

6. The firmware upgrade method according to claim 3, wherein: When the data boundaries of the data packet to be detected and the target data packet are displaced, the first buffer area and the second buffer area form a plurality of dual-ring buffer areas.

7. The firmware upgrade method according to claim 6, wherein: The number of the dual-ring buffer areas is two, and the to-be-checked data blocks of the to-be-detected data packet and the target data packet are checked one by one in a preset order, including: Get the first and last data block positions of the double ring buffer area; The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the first double-ring buffer area are checked one by one starting from the data at the first data block position; The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the second double-ring buffer area are checked one by one starting from the data at the last data block position.

8. The firmware upgrade method according to claim 5, wherein: The method includes intercepting at least one data block of a preset size from at least one waiting data packet, comprising: Pre-acquiring preset data block sizes of the first buffer area and the second buffer area; Using the preset data block size as the preset size of the intercepted data block for interception; Obtaining a target data block corresponding to at least one data block includes: The second image file is segmented according to the preset data block size to obtain corresponding target data blocks.

9. The firmware upgrade method according to claim 8, wherein: The preset data block size is a fixed data block size; intercepting at least one data block of the fixed data block size from at least one waiting data packet; Correspondingly, the second image file is divided according to the fixed data block size to obtain corresponding target data blocks.

10. The firmware upgrade method according to claim 9, wherein: Verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain verification results, including: Get the current data block position; Comparing the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, and the data blocks to be checked at the data block position next to the current data block position corresponding to the first buffer area and the second buffer area are used as new current data block positions, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data blocks to be checked at the current data block position are different, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area, until all the data blocks to be checked in the first buffer area and the second buffer area are compared.

11. The firmware upgrade method according to claim 8, wherein: The preset data block size is a non-fixed data block size; the multiple preset data block sizes increase step by step, and there is an integer multiple relationship between the multiple preset data block sizes; at least one data block is intercepted from the at least one waiting data packet in the order of the multiple non-fixed data block sizes that increase step by step to obtain; Correspondingly, the second image file is divided in the order of a plurality of non-fixed data block sizes that increase in a step-by-step manner to obtain corresponding target data blocks.

12. The firmware upgrade method according to claim 11, wherein: Verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain verification results, including: Get the current data block position; Comparing the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, and the data blocks to be checked at the data block position next to the current data block position corresponding to the first buffer area and the second buffer area are used as new current data block positions, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data block to be checked at the current data block position is different, and the data block to be checked at the current data block position is used as the initial check data block and a first data block size is obtained; wherein the length of the first data block size is a non-fixed value, the sizes of the multiple first data blocks decrease step by step, and there is an integer multiple relationship between the sizes of the multiple first data blocks; Splitting the initial check data block in the order of a plurality of non-fixed data block sizes that decrease in order to determine a plurality of current first data blocks; Obtaining a current first data block position according to a data block position sequence of the multiple current first data blocks; wherein the current first data block position is compared starting with a first position of the data block positions of the multiple first data blocks; Comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area; If they are the same, determining that the initial check data blocks at the current first data block position are the same, setting the first data block position next to the current first data block position corresponding to the first buffer area and the second buffer area as the new current first data block position, and returning to the step of comparing the data at the current first data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the initial check data blocks of the current first data block position are the same, and the next first data block position of the current first data block position corresponding to the first buffer area and the second buffer area is used as the new current first data block position, and the process returns to the step of comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area until all the data of the first buffer area and the second buffer area are compared.

13. The firmware upgrade method according to claim 7, wherein: Verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain verification results, including: Marking the data block positions with different verification results in the first dual-ring buffer area to obtain a first marking position; Marking the data block positions with different verification results in the second dual-ring buffer area to obtain a second marking position; In the dual-ring buffer area, data blocks corresponding to the first mark position to the second mark position are written into the flash memory.

14. The firmware upgrade method according to claim 2, wherein: Verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain verification results, including: Acquire first target data of the data block to be checked of the data packet to be detected and second target data of the data block to be checked of the target data packet; determining a check value according to the first target data; determining a hash value according to the second target data; Determining whether the check value and the hash value are the same; If they are different, it is determined that the verification results are different; If they are the same, it is determined that the verification results are the same.

15. The firmware upgrade method according to claim 1, wherein: Before storing the at least one data block in the memory of the management controller, the method further includes: Creating an index mark for at least one data block; determining a first check value based on data of at least one data block; The first check value and the index mark are saved and stored together with the at least one data block in a memory of the management controller.

16. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the firmware upgrade method according to any one of claims 1 to 15 when executing the computer program.

17. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the firmware upgrade method according to any one of claims 1 to 15.

18. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the firmware upgrade method according to any one of claims 1 to 15 are implemented.

Images